ESIM operator and card writing data management method based on decoupling framework

Abstract

The invention discloses an eSIM operator and card writing data management method based on a decoupling framework, and relates to the field of communication, and the method comprises the steps: receiving an eSIM configuration task request sent by an operator, analyzing the eSIM configuration task request into an intermediate protocol data model through an intermediate protocol conversion module, and transmitting the intermediate protocol data model to an eSIM server; controlling the scheduling engine to select a matched target card writing platform adapter from a platform adapter management module according to a predefined scheduling strategy; calling the target card writing platform adapter, converting the intermediate protocol data model into protocol data required by a target platform, and sending the protocol data to the target card writing platform; and receiving a response result returned by the target card writing platform, converting the response result into an intermediate response format by the adapter plug-in, and returning the intermediate response format to the operator. The method has remarkable technical advantages in the aspects of framework flexibility, platform adaptability, scheduling intelligence, safety controllability, deployment expandability and the like.

Description

Technical Field

[0001] This specification relates to the field of communications. More specifically, this application relates to an eSIM operator and card writing data management method based on a decoupled architecture. Background Art

[0002] With the wide application of eSIM (Embedded SIM card) technology, more and more mobile terminal devices use the eSIM method to achieve remote configuration and activation, and the traditional physical SIM card writing process has gradually been replaced by virtualization and digitization. Operators usually implement the distribution and activation of eSIM configuration files through a card writing platform (such as an SM-DP+ server, a local LPA platform, a third-party card writing manufacturer system). However, the current mainstream eSIM operator and card writing platform data docking control systems generally have the following problems: 1. Strong coupling docking mode: In most systems, the operator system needs to adapt the interface, configuration format, and scheduling logic for each card writing platform separately, resulting in a large amount of development and maintenance work; 2. Lack of intermediate protocol abstraction: The protocols of different platforms vary greatly (such as JSON, ASN.1, etc.), and the field structures, naming methods, and process constraints are inconsistent, making it impossible to achieve generalization management; 3. Difficulty in reusing the adapter module: The platform adaptation logic is embedded in the main process code and does not have the ability to be pluggable or hot-updated; 4. Simple scheduling strategy: Lack of a unified scheduling control module, unable to achieve intelligent distribution according to the platform load and performance status.

[0003] Therefore, there is an urgent need for an eSIM operator and card writing platform data docking management method that is scalable, decouplable, and has the ability of intermediate protocol abstraction to meet the requirements of high-availability and high-flexibility card writing task management in a multi-platform and multi-operator access environment. Summary of the Invention

[0004] A series of simplified concepts are introduced in the Summary of the Invention section, which will be further described in detail in the Detailed Implementation section. The Summary of the Invention section of this application does not mean to attempt to define the key features and essential technical features of the claimed technical solution, nor does it mean to attempt to determine the protection scope of the claimed technical solution.

[0005] In a first aspect, this application proposes an eSIM operator and card writing data management method based on a decoupled architecture, and the above method includes: Receiving, through the above unified access interface module, an eSIM configuration task request sent by an operator, where the above configuration task request includes an ICCID, an EID, a configuration type, and a target card writing platform prompt message; The above eSIM configuration task request is parsed into a middle protocol data model by the above middle protocol conversion module, where the above middle protocol data model is a platform-neutral data structure; Control the above scheduling engine to select a matching target card writing platform adapter from the platform adapter management module according to a predefined scheduling policy; Call the above target card writing platform adapter to convert the above middle protocol data model into protocol data required by the target platform and send it to the target card writing platform; Receive the response result returned by the above target card writing platform and convert it into a middle response format by the adapter plugin and return it to the operator.

[0006] In a feasible implementation manner, the parsing process of the above middle protocol conversion module includes a pre-parsing stage, a semantic abstraction stage, and a structure assembly stage. The above middle protocol conversion module parses the above eSIM configuration task request into a middle protocol data model and constructs a platform-neutral data structure, including: In the above pre-parsing stage, format normalization processing is performed on the original parameters in the above eSIM configuration task request to obtain normalized parameters; In the above semantic abstraction stage, a predefined data semantic abstraction template is called to map the above normalized parameters to standardized fields with platform-independent semantic labels; In the above structure assembly stage, a middle protocol structure template is called based on the task type, and semantic fields are filled in the above standardized fields to generate the above platform-neutral data structure.

[0007] In a feasible implementation manner, the above predefined data semantic abstraction template supports online incremental update operations, and the above online incremental update operations specifically include: In the case of receiving an incremental template change request, compare the fields to be updated with the field identifiers in the existing semantic template to determine whether there are duplicate field names; If there are duplicate fields, further determine whether their semantic labels and data types are consistent, and mark the fields and issue a first prompt message in case of a conflict; Detect the field mapping relationship between each semantic field in the updated template and the existing template on the same card writing platform to determine whether there is a situation where the same platform field is mapped by multiple semantic labels; If there is a situation where multiple semantic labels are mapped, issue a second prompt message; Based on the above first prompt message and the above second prompt message, correct the above incremental template change request to form an updated data semantic abstraction template.

[0008] In a feasible implementation manner, amending the incremental template change request based on the first prompt information and the second prompt information to form an updated data semantic abstraction template includes: Construct a semantic field graph, where the semantic field graph includes field names, semantic labels, field types, platform mapping relationships, and field historical usage information, and the semantic field graph is used to represent semantic similarities, conflict paths, and platform relationships between fields; Based on the conflicts between the field names identified in the first prompt information and the semantic labels and data types, and combining the semantic field graph, generate a first candidate correction plan including field renaming, semantic label merging, or field structure adjustment; Based on the situation that the same card writing platform field is mapped by multiple semantic labels identified in the second prompt information, and combining the platform field priority and conflict severity, mine the field mapping path from the semantic field graph, and generate a second candidate correction plan including main label setting, field alias designation, or platform template splitting; Perform rule reasoning and confidence scoring on all candidate correction plans according to field semantic consistency, historical usage frequency, and platform conflict level, and output a recommendation list sorted by score; Receive the correction plan confirmed by the administrator or selected by the automatic policy, and apply it to the incremental template change request to generate the updated data semantic abstraction template.

[0009] In a feasible implementation manner, it further includes: When the task type is a Profile download task, call a preset download protocol structure template, and the download protocol structure template includes fields such as ICCID, EID, Profile type, and configuration URL; When the task type is a Profile deletion task, call a preset deletion protocol structure template, and the deletion protocol structure template includes fields such as ICCID and EID; When the task type is a Profile enabling task, call a preset enabling protocol structure template, and the enabling protocol structure template includes fields such as ICCID and target device identifier; When the task type is a status query task, call a preset status query structure template, and the status query structure template includes the ICCID field.

[0010] In a feasible implementation manner, controlling the scheduling engine to select a matching target card writing platform adapter from the platform adapter management module according to a predefined scheduling policy includes: Query the adapter metadata registered in the platform adapter management module; Score and sort all candidate adapters according to a predefined scheduling policy; Select the target adapter with the highest score as the binding platform for the card writing task and record the task adaptation path; If the selected adapter is unavailable, automatically switch to the standby adapter in descending order of scores to continue scheduling the task.

[0011] In a feasible implementation manner, the above scheduling policy includes a priority policy, a task type adaptation policy, a geographical adaptation policy, a performance-driven policy, and a disaster tolerance policy.

[0012] In a feasible implementation manner, the above unified access interface module supports RESTful interfaces, WebSocket interfaces, and MQTT protocol interfaces.

[0013] In a feasible implementation manner, the above intermediate protocol data model is in a structured JSON format or an ASN.1 abstract syntax structure.

[0014] In summary, by introducing an intermediate protocol mechanism and a plug-in adaptation architecture, the present invention realizes the full-process logical decoupling between the operator system and various card writing platforms. The operator only needs to submit a standardized configuration task request to the system without being aware of the protocol details and call interfaces of the target platform, thus greatly reducing the complexity of platform access and upgrade. Secondly, the control and scheduling engine set inside the system has intelligent decision-making capabilities and supports multi-dimensional scheduling strategies combining task types, platform running states, load conditions, geographical attributes, etc., dynamically selecting the most suitable card writing platform to execute the configuration task, significantly improving the platform resource utilization rate and task success rate. In terms of protocol processing, the present invention supports the compatible processing of multiple data encodings and protocol formats. The platform adapter module can convert the intermediate protocol data model into JSON, ASN.1 or XML formats according to the needs of the target platform, with good generality and protocol adaptability, meeting the technical challenges brought by interface differences between different platforms. The overall operation process of the system is highly transparent to the operator. The operator only needs to submit the core parameters of the task, and the system can automatically complete platform selection, protocol encapsulation and result feedback, realizing the service experience of "one-point access and multi-platform execution". In addition, the system provides multiple access methods, compatible with three mainstream communication protocols of REST, WebSocket and MQTT, which is not only applicable to the access of traditional enterprise information systems, but also applicable to the lightweight access requirements of Internet of Things terminals, mobile terminals and edge platforms. From the perspective of operation and maintenance and security, the system records all-link log data including task parameters, adaptation paths, platform responses and execution results throughout the process, supporting task traceability, exception location and security auditing, further enhancing the governability of the system. Finally, the present system has good scalability and maintainability. To add a new card writing platform, only a new adapter plug-in needs to be registered and put on the line without changing the core system logic, effectively reducing the platform expansion and maintenance costs. The present invention has significant technical advantages in terms of architecture flexibility, platform adaptability, scheduling intelligence, security and controllability, and deployment scalability, and is applicable to the eSIM configuration management scenario in a multi-operator and multi-platform environment, with broad application prospects and engineering value.

[0015] The eSIM operator and card writing data management method based on a decoupled architecture proposed in this application. Other advantages, objectives and features of this application will be partially reflected by the following description and partially understood by those skilled in the art through the research and practice of this application. Brief Description of the Drawings

[0016] By reading the following detailed description of the preferred embodiments, various other advantages and benefits will become clear to those of ordinary skill in the art. The drawings are only for the purpose of showing the preferred embodiments and are not considered to limit this specification. Moreover, throughout the drawings, the same reference numerals are used to represent the same components. In the drawings: Figure 1 A schematic flow chart of an eSIM operator and card writing data management method based on a decoupled architecture provided by an embodiment of the present application. Specific implementation manners

[0017] Terms such as "first", "second", "third", "fourth", etc. (if any) in the specification, claims and the above-mentioned drawings of the present application are used to distinguish similar objects, and do not necessarily describe a specific order or sequence. It should be understood that the data used in this way can be interchanged under appropriate circumstances so that the embodiments described here can be implemented in an order other than those illustrated or described here. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, product or device including a series of steps or units does not necessarily limit to those clearly listed steps or units, but may include other steps or units not clearly listed or inherent to these processes, methods, products or devices. Next, the technical solutions in the embodiments of the present application will be clearly and completely described in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments.

[0018] Please refer to Figure 1 , which is a schematic flow chart of an eSIM operator and card writing data management method based on a decoupled architecture, and specifically may include: S110. Receive an eSIM configuration task request sent by an operator through the above unified access interface module, where the configuration task request includes an ICCID, an EID, a configuration type, and target card writing platform prompt information; Exemplarily, receive an eSIM configuration task request initiated from the operator side through the unified access interface module. This module supports multiple communication protocols such as RESTful API, WebSocket or MQTT, and has functions of identity authentication and interface permission verification.

[0019] The above configuration task request includes but is not limited to the following fields: ICCID: The identifier of the configured eSIM card; EID: The unique identifier of the terminal device; Configuration type: including Profile download, deletion, activation, etc.; Target card writing platform prompt information: an optional field for guiding scheduling policy preferences.

[0020] S120. Parse the above eSIM configuration task request into an intermediate protocol data model by the above intermediate protocol conversion module, where the intermediate protocol data model is a platform-neutral data structure; Exemplarily, the intermediate protocol conversion module performs multi-stage conversion on the above request to generate a platform-neutral intermediate protocol data model. The conversion process is divided into: Pre-parse stage: Unify the format of the input parameters and verify the field types. Semantic abstraction stage: Invoke the semantic template to map the fields to standard semantic tags (such as SIM_IDENTIFIER, DEVICE_IDENTIFIER). Structure assembly stage: According to the task type (such as Download), invoke the corresponding intermediate protocol template, fill in the semantic fields, and generate a standard intermediate protocol data structure (JSON or ASN.1).

[0021] S130. Control the above scheduling engine to select a matching target card writing platform adapter from the platform adapter management module according to the predefined scheduling policy. Exemplarily, the control scheduling engine selects a target card writing platform adapter from the platform adapter management module according to the predefined policy. The policy may include: matching of task type and platform capabilities, platform current load and availability, platform historical success rate, platform priority and geographical attribution, and disaster recovery backup mechanism. The system scores and ranks all candidate platforms and selects the one with the highest score as the execution platform.

[0022] S140. Invoke the above target card writing platform adapter to convert the above intermediate protocol data model into the protocol data required by the target platform and send it to the target card writing platform. Exemplarily, the adapter receives the intermediate protocol data model passed by the scheduling engine and converts it into a platform-specific format according to the protocol requirements of the target platform. This format can be structured JSON, ASN.1 encoding, XML structure, or an instruction segment encapsulated by Base64. The adapter can invoke the built-in protocol template and field mapping rules during the conversion process to ensure that the generated data structure conforms to the platform interface specification.

[0023] After completing the protocol conversion, the adapter constructs specific call parameters, including but not limited to task instructions, authentication credentials, platform identifier, device identifier, etc., and issues the task request to the target card writing platform through a preset communication path (such as HTTP interface, HTTPS encrypted channel, or dedicated line API).

[0024] During the task issuance process, the adapter will synchronously record the request log, call timestamp, sending status, and platform response timeout policy, and prepare an automatic retry or failover mechanism for abnormal situations.

[0025] S150. Receive the response result returned by the above target card writing platform and convert it into an intermediate response format by the adapter plugin and return it to the operator.

[0026] Exemplarily, subsequently, the adapter waits for the platform to return response data, which may be provided in the form of asynchronous push, synchronous callback, or status polling. When the platform response is received, the adapter parses it into an intermediate response structure in a unified format, which indicates the task execution status (e.g., success, failure, queuing) and optional error codes and platform feedback information.

[0027] The system returns the intermediate response result returned by the adapter to the operator side along the original call channel. For example, through HTTP synchronous response, WebSocket message push, or MQTT topic message publishing, the task execution result is accurately passed to the initiator. At the same time, the system records the complete task processing track in the platform log module for subsequent auditing, status query, and performance analysis.

[0028] In summary, by introducing an intermediate protocol mechanism and a plug-in adaptation architecture, the present invention realizes the full-process logical decoupling between the operator system and various card writing platforms. The operator only needs to submit a standardized configuration task request to the system without being aware of the protocol details and call interfaces of the target platform, thus greatly reducing the complexity of platform access and upgrade. Secondly, the control scheduling engine set inside the system has intelligent decision-making capabilities and supports multi-dimensional scheduling strategies combining task types, platform running status, load conditions, geographical attributes, etc., dynamically selecting the most suitable card writing platform to execute the configuration task, significantly improving the platform resource utilization rate and task success rate. In terms of protocol processing, the present invention supports the compatible processing of multiple data encodings and protocol formats. The platform adapter module can convert the intermediate protocol data model into JSON, ASN.1 or XML formats according to the needs of the target platform, with good generality and protocol adaptability, meeting the technical challenges brought by interface differences between different platforms. The overall operation process of the system is highly transparent to the operator. The operator only needs to submit the core parameters of the task, and the system can automatically complete platform selection, protocol encapsulation and result feedback, realizing the service experience of "one-point access, multi-platform execution". In addition, the system provides multiple access methods, compatible with three mainstream communication protocols of REST, WebSocket and MQTT, which is not only applicable to the access of traditional enterprise information systems, but also applicable to the lightweight access requirements of Internet of Things terminals, mobile terminals and edge platforms. From the perspective of operation and maintenance and security, the system records all-link log data including task parameters, adaptation paths, platform responses and execution results throughout the process, supporting task traceability, exception location and security auditing, further enhancing the governability of the system. Finally, the present system has good scalability and maintainability. To add a new card writing platform, only a new adapter plug-in needs to be registered and put on the line without modifying the core system logic, effectively reducing the platform expansion and maintenance costs. The present invention has significant technical advantages in terms of architecture flexibility, platform adaptability, scheduling intelligence, security controllability and deployment scalability, and is applicable to the eSIM configuration management scenario in a multi-operator and multi-platform environment, with broad application prospects and engineering value.

[0029] In a feasible implementation manner, the parsing process of the above intermediate protocol conversion module includes a pre-parsing stage, a semantic abstraction stage and a structure assembly stage. The above intermediate protocol conversion module parses the above eSIM configuration task request into an intermediate protocol data model and constructs a platform-neutral data structure, including: In the above pre-parsing stage, format normalization processing is performed on the original parameters in the above eSIM configuration task request to obtain normalized parameters. In the above semantic abstraction stage, a predefined data semantic abstraction template is called to map the above normalized parameters into standardized fields with platform-independent semantic labels. In the above-mentioned structure assembly stage, the intermediate protocol structure template is called based on the task type, and semantic fields are filled in the above-mentioned standardized fields to generate the above-mentioned platform-neutral data structure.

[0030] Exemplarily, first, in the pre-parse stage, the system receives the original eSIM configuration task request from the unified access interface module. This request may come from different operators, and there are certain differences in its field naming, format type, or transmission encoding. To ensure the consistency of system processing, all original parameters are uniformly processed in this stage, including operations such as field name standardization, data type normalization, default value filling, and structure flattening, so as to generate a set of normalized parameter sets in a unified format. For example, for the fields sim_id, iccid_num, and iccid submitted by different operators respectively, the system uniformly maps them to the standard internal field iccid.

[0031] Next, it enters the semantic abstraction stage. In this stage, the system calls the predefined data semantic abstraction template library to perform semantic annotation and label mapping on the normalized parameters. Each field is assigned a platform-independent semantic label (such as SIM_IDENTIFIER, DEVICE_IDENTIFIER, PROFILE_TYPE, etc.), and its data type, constraint conditions, and adaptation platform mapping relationship are recorded. This abstraction process not only gives the fields a unified semantics but also lays a foundation for subsequent cross-platform mapping and protocol generation. Taking the field profileType as an example, whether its source data is "Primary", "P", or "01", it can be converted into the unified semantic label PROFILE_TYPE and standardized to "Primary" through the template.

[0032] After completing the field abstraction, the system enters the structure assembly stage. The core task of this stage is to call the corresponding intermediate protocol structure template from the structure template library according to the task type (such as Profile download, deletion, activation, or status query). The template defines the field structure, field order, nesting level, and necessity constraints. The system fills the semantically abstracted fields into the structure one by one according to the template requirements, and finally constructs a data structure model that meets the internal standards of the system. This structure usually adopts formats such as JSON or ASN.1 and can be directly called by the subsequent adapter module for protocol conversion and task distribution.

[0033] Through the continuous processing of the above three stages, the system converts complex and non-standard operator requests into clear, unified, and structured intermediate protocol data models, which have a high degree of platform independence and provide a stable data foundation for subsequent task scheduling and platform adaptation.

[0034] In a feasible implementation, the above-mentioned predefined data semantic abstraction template supports online incremental update operations. The above-mentioned online incremental update operations specifically include: When receiving an incremental template change request, compare the fields to be updated with the field identifiers in the existing semantic template to determine whether there are duplicate field names; If there are duplicate fields, further determine whether their semantic tags and data types are consistent, and mark the fields and send a first prompt message in case of conflicts; Detect the field mapping relationship between each semantic field in the updated template and the existing template on the same card writing platform, and determine whether there is a situation where the same platform field is mapped by multiple semantic tags; If there is a situation where multiple semantic tags are mapped, send a second prompt message; Based on the above first prompt message and the above second prompt message, make corrections to the above incremental template change request to form an updated data semantic abstraction template.

[0035] Exemplarily, to meet the requirements of the continuous evolution of the interface specifications between multiple operators and the card writing platform in the eSIM operator and card writing platform data docking control system, the predefined data semantic abstraction template used in the system supports online incremental update operations. This mechanism allows for the dynamic adjustment of field semantic mapping relationships, data structure standards, and platform field adaptation logic without interrupting the operation of the main system, thereby ensuring that the system has good maintainability and extensibility.

[0036] First, when the system receives an incremental template change request, the system loads the request content into the semantic sandbox environment and performs a comparative analysis with the currently activated semantic abstraction template. The change request usually includes one or more field definition updates, such as adding fields, field aliases, modifying data types, or adjusting platform mapping relationships, etc.

[0037] After the preliminary comparison, the system first determines whether there are duplicate field names. That is, whether the field names defined in the template to be updated have already appeared in the current template. If there are duplicate fields, the system will further determine whether the semantic tags (semanticTag) of the field in the new and old templates are consistent and whether the data types are compatible. If a semantic tag conflict (such as originally DEVICE_IDENTIFIER, now ORDER_CODE) or data type inconsistency (such as originally string, now integer) is identified, the field will be marked as a conflicting field, and a first prompt message will be automatically generated to prompt the management staff that there is a problem with inconsistent field definitions.

[0038] Subsequently, the system continues to verify the field mapping relationship between the fields involved in the updated template and the fields of the card writing platform. Specifically, the system will traverse the registered field mapping tables in all platform adapters to determine whether there is a situation where the same platform field name is mapped by multiple semantic tags simultaneously. For example, if the field sim_id in the PLAT_A platform is mapped to both SIM_IDENTIFIER and DEVICE_IDENTIFIER at the same time, the system will identify it as a potential semantic conflict and automatically generate a second prompt message, indicating that there is an overlap in the cross-semantic tag field mapping.

[0039] After the above first prompt message and second prompt message are generated, the system will enter the template correction stage. Based on the field conflict situations identified in the prompt messages, the system provides several correction suggestions, including but not limited to: field renaming (such as renaming the new field to profileTypeV2); setting the semantic main tag and affiliated aliases; splitting the platform field mapping scope; clarifying the binding relationship between the field effective scope and the task type.

[0040] Finally, the corrected template content will be verified again through the semantic sandbox. If it passes the consistency check, it will be written into the formal template library as the updated data semantic abstraction template, and the corresponding version number will be updated. After the update takes effect, the system can construct the intermediate protocol and map the field semantics based on the new template to ensure compatibility with old tasks and support for new tasks.

[0041] In a feasible implementation manner, correcting the above incremental template change request based on the above first prompt message and the above second prompt message to form an updated data semantic abstraction template includes: Construct a semantic field graph, where the semantic field graph includes field names, semantic tags, field types, platform mapping relationships, and field historical usage information. The semantic field graph is used to represent the semantic similarity, conflict paths, and platform relationships between fields; Based on the field name duplication and semantic tag and data type conflicts identified in the above first prompt message, combined with the above semantic field graph, generate a first candidate correction plan including field renaming, semantic tag merging, or field structure adjustment; Based on the situation where the same card writing platform field is mapped by multiple semantic tags identified in the above second prompt message, combined with the platform field priority and conflict severity, mine the field mapping path from the semantic field graph, and generate a second candidate correction plan including main tag setting, field alias designation, or platform template splitting; Perform rule reasoning and confidence scoring on all candidate correction plans according to field semantic consistency, historical usage frequency, and platform conflict level, and output a recommendation list sorted by score; Receive the revised solution confirmed by the administrator or selected by the automatic policy, and apply it to the above incremental template change request to generate the above updated data semantic abstraction template.

[0042] Exemplarily, to enhance the intelligence and controllability of the template update process, when processing the incremental template change request, the system introduces a semantic graph-assisted correction mechanism based on the first prompt information and the second prompt information to identify conflicts, forming a structured decision-making support process to achieve high-quality evolution and automated governance of the incremental template.

[0043] First, the system constructs and maintains a semantic field graph for graph-structured modeling of the historical and current states of all fields in the template. This semantic field graph contains the core attribute information of each field, including: field name (such as profileType), semantic label (such as PROFILE_TYPE), field data type (such as enum, string), platform mapping relationship (recording the mapping path of the field on different platforms, such as PLAT_A→config_type), and field historical usage information (such as usage frequency, task context, change records, etc.).

[0044] This graph establishes the semantic similarity, field conflict paths, and platform usage relationships between fields through the relationships of nodes and edges, providing context basis for subsequent reasoning.

[0045] Next, the system processes the problem of duplicate field names identified in the first prompt information. Specifically, the system generates a set of first candidate correction solutions based on the semantic label similarity and data type compatibility between fields in the semantic graph. Its correction strategies include: field renaming: rename the conflicting field (such as profileTypeV2) to retain historical compatibility; semantic label merging: if the semantic labels of the old and new fields are similar or have mergeable logic (such as DEVICE_ID and HARDWARE_ID), it is recommended to unify the labels; field structure adjustment: for example, split complex fields into multiple sub-fields, or expand enumeration fields into structure fields.

[0046] Subsequently, the system further processes the second prompt information, which is used to identify the conflict situation where the same card-writing platform field is mapped by multiple semantic labels. The system dynamically analyzes the many-to-many mapping relationship between fields and platforms from the semantic graph in combination with the priority rules of platform fields (for example, the main platform field cannot be remapped) and historical conflict records, and generates the second candidate correction solution, including but not limited to: main label setting: establish a unique semantic main label for the platform field, and the rest are aliases or used in restricted contexts; field alias specification: solve the multi-label conflict by setting the semantic alias mapping relationship; platform template splitting: when the conflict cannot be resolved, split the conflicting field into multiple platform-specific sub-templates for isolation.

[0047] After generating candidate correction solutions, the system introduces a rule reasoning mechanism and a confidence scoring system to comprehensively evaluate each solution. The scoring dimensions include factors such as the degree of field semantic consistency, the historical usage frequency of fields (fields with more usage are recommended to be retained), and the severity of platform conflicts, and a sorted scoring list is formed based on the weighted results.

[0048] Finally, the system outputs several correction solutions with the highest scores in a recommended form for the template administrator to confirm. The administrator can choose to accept the recommended solutions or fine-tune the merging strategy in the visual interface; in low-risk change scenarios, the system can also automatically select the optimal correction solution and execute it according to the preset strategy.

[0049] The confirmed correction solutions will be officially applied to the original incremental template change request to generate an updated data semantic abstraction template, which is assigned a new version number, source identifier, and application scope and written into the template version control system. This updated template will be used as the field mapping basis when constructing the intermediate protocol data structure for subsequent configuration tasks, ensuring the stability and consistency of system processing.

[0050] In a feasible implementation manner, it further includes: When the above task type is a Profile download task, a preset download protocol structure template is called, and the above download protocol structure template includes fields such as ICCID, EID, Profile type, and configuration URL; When the above task type is a Profile deletion task, a preset deletion protocol structure template is called, and the above deletion protocol structure template includes fields such as ICCID and EID; When the above task type is a Profile enable task, a preset enable protocol structure template is called, and the above enable protocol structure template includes fields such as ICCID and target device identifier; When the above task type is a status query task, a preset status query structure template is called, and the above status query structure template includes the ICCID field.

[0051] Exemplarily, when the intermediate protocol conversion module is in the structure assembly stage, to ensure that different types of eSIM configuration tasks can correctly generate data structures that meet business semantics and platform requirements, the system predefines multiple types of intermediate protocol structure templates and automatically calls the corresponding templates for structure filling according to different task types to generate a platform-neutral data model. This process realizes a task type-driven structure template selection mechanism, ensuring the structural integrity and adaptation accuracy of the issued requests.

[0052] Specifically, this mechanism supports the structure templates for the following typical eSIM task types: First, when the task type is a Profile download task (i.e., Download Profile), the system automatically invokes a preset download protocol structure template. This template is used to carry the complete configuration data required for performing the card writing operation, and its structure includes, but is not limited to, the following fields: ICCID (eSIM card identifier); EID (unique identifier of the terminal device); Profile type (such as Primary, Secondary); configuration URL (pointing to the download address of the configuration file). The system fills the corresponding semantic fields (such as SIM_IDENTIFIER, DEVICE_IDENTIFIER) into the above template fields during the structure assembly stage to form a standard download request structure.

[0053] Second, when the task type is a Profile deletion task, the system invokes a deletion protocol structure template. This template is relatively simple and only contains: ICCID; EID. This structure is used to send an instruction for the "cancellation / unbinding" operation to the card writing platform, and the template design ensures the uniqueness and security of the deletion operation target.

[0054] Third, when the task type is a Profile activation task, the system invokes an activation protocol structure template. This template is used to specify activating and binding a certain eSIM configuration to a specific device, and the main fields include: ICCID; target device identifier (usually EID or a partial binding identifier, such as deviceId). The structure of such a task template is used to guide the platform to initiate the Profile activation process inside the eUICC to ensure the effective state of the Profile on the device.

[0055] Finally, when the task type is a status query task, the system invokes a status query structure template. The structure of this template is the most concise and usually only contains: ICCID. It is used to send a query request to the target platform for the current status of a certain eSIM card (such as whether the card writing is successful, whether it is activated, whether it is available).

[0056] During the actual system operation, the invocation of the structure template is automatically completed by the template manager inside the intermediate protocol conversion module. After the system receives the normalized and semantically abstracted parameters, it matches the corresponding template according to the task type identifier and fills the standardized fields into the corresponding structure positions of the template, thereby generating an intermediate protocol data model that conforms to the task semantics, has complete fields, and unified formats. Through the application of this mechanism, while supporting multiple service task types, this system ensures the consistency of field definitions and structure specifications, effectively improving the cross-platform adaptation ability and the accuracy of configuration distribution.

[0057] In a feasible implementation manner, the above-mentioned controlling the scheduling engine to select a matching target card writing platform adapter from the platform adapter management module according to a predefined scheduling strategy includes: Query the adapter metadata registered in the above platform adapter management module; Score and sort all candidate adapters according to predefined scheduling policies; Select the target adapter with the highest score as the bound platform for the card writing task, and record the task adaptation path; If the selected adapter is unavailable, automatically switch to the standby adapter in descending order of scores to continue scheduling the task.

[0058] In a feasible implementation manner, the above scheduling policies include a priority policy, a task type adaptation policy, a geographical adaptation policy, a performance-driven policy, and a disaster tolerance policy.

[0059] Exemplarily, the process of the control scheduling engine selecting a matching target card writing platform adapter from the platform adapter management module according to the predefined scheduling policy adopts a score-driven intelligent selection mechanism to achieve the optimal matching between the task and the card writing platform, so as to improve the task success rate and platform resource utilization efficiency. This process mainly includes four consecutive steps: adapter metadata acquisition, scoring and sorting, task binding, and disaster tolerance fallback.

[0060] First, after receiving the complete intermediate protocol data model, the scheduling engine immediately queries all currently registered adapter metadata information from the platform adapter management module. The adapter metadata includes, but is not limited to: the task types supported by the adapter (such as whether it supports Download, Enable, Delete, etc.); the platform identification and regional coverage information; the interface protocol type (such as HTTP, HTTPS, dedicated line); the current running status (Active / Inactive); the historical task success rate and exception statistics; the real-time performance metrics (such as response latency, queue length, and the most recent available time); and the matching degree with the policy preferences of the operator's tasks.

[0061] Based on the above metadata and task context, the scheduling engine executes a predefined scheduling policy evaluation model for all candidate adapters. This evaluation process forms a multi-dimensional adaptation score (adaptability Score) by weighting and scoring each adapter, specifically considering the following typical policy factors: Task type adaptation policy: If the adapter is clearly marked as supporting the current task type, points are added; Platform health policy: If the platform has no current fault mark, short response time, and high recent success rate, points are added; Regional priority policy: If the platform adapter is located in the geographical domain consistent with the task-specified area, points are added; Operator preference policy: If the target platform prompt is specified in the operator interface and the platform matches, points are added; Load balancing policy: If the current load of the platform is moderate, the scheduling engine tends to give priority to distribution.

[0062] Each adapter will output a comprehensive score value (e.g., Score = 0.92), and sort the adapter list in descending order according to the scoring results.

[0063] After the scoring is completed, the scheduling engine selects the adapter with the highest score from the sorted results as the target platform adapter, and binds the current task to this adapter to form an adaptation path mapping record of "Task ID → Adapter ID → Platform ID". This path information will be recorded by the system in the task scheduling log for subsequent traceability and status tracking.

[0064] If, during the adapter call process, it is found that the preferred adapter is unavailable due to network anomalies, platform failures, response timeouts, etc., the system will immediately trigger the disaster recovery policy and automatically try the backup adapters in descending order of scores until an available platform is selected or the maximum retry threshold is exceeded. This disaster recovery mechanism ensures that the system has high-availability scheduling capabilities in the face of single-point platform failures, avoiding task failures or long-term blockages.

[0065] Through the above-mentioned scoring and selection and disaster recovery fallback mechanisms of the scheduling engine, the system realizes the dynamic optimal adaptation between tasks and platforms, adapting to the platform performance fluctuations in complex environments and the differentiated scheduling requirements of multi-operator scenarios.

[0066] In a feasible implementation, the above unified access interface module supports RESTful interfaces, WebSocket interfaces, and MQTT protocol interfaces.

[0067] Exemplarily, the unified access interface module has multi-protocol access capabilities to adapt to the system integration environments of different types of operators. The above module supports RESTful interfaces, WebSocket interfaces, and MQTT protocol interfaces to achieve flexible access, status feedback, and task event notifications.

[0068] The RESTful interface is mainly used for synchronous calls of configuration tasks initiated by traditional IT systems or operation platforms, and supports submitting eSIM configuration tasks (e.g., ordering Profile, deleting Profile) through the HTTPS POST method. The system returns standard HTTP status codes and JSON structure responses.

[0069] The WebSocket interface is suitable for scenarios that require two-way communication, such as real-time feedback of configuration status, task queue pushing, etc. After the operator system establishes a long connection, it can receive task execution status (Pending, Success, Failure, etc.).

[0070] The MQTT protocol interface is targeted at Internet of Things device operators and adopts a lightweight message publishing / subscribing model, which is suitable for low-bandwidth, high-concurrency scenarios; operators receive task result pushes by subscribing to topics, improving the data transfer efficiency.

[0071] The above multi - protocol support mechanism not only improves the system compatibility, but also supports multi - tenant and multi - service concurrent processing, and can configure access permissions, rate limits, and task signature verification mechanisms according to access types to ensure security and stability.

[0072] In a feasible implementation manner, the above - mentioned intermediate protocol data model is in a structured JSON format or an ASN.1 abstract syntax structure.

[0073] Exemplarily, the intermediate protocol data model adopts a platform - neutral data structure, and specifically can be a structured JSON format or an ASN.1 abstract syntax structure to meet the differentiated requirements of docking protocols for different platforms.

[0074] When the target card - writing platform supports the standard HTTP / JSON interface, the intermediate protocol data model adopts the JSON format, with clear field structure and strong extensibility, which is suitable for dynamic generation and debugging. For example: When the target platform requires strict structure definition or security encapsulation (such as using the SM - DP+ protocol), the intermediate protocol data model can adopt the ASN.1 structure, which supports binary encapsulation, BER / DER encoding, and signature verification. This structure can be encoded and converted in the adapter through a predefined template to automatically generate the ASN.1 representation form from semantic fields.

[0075] By providing dual - format support, the intermediate protocol model realizes a high - level protocol abstraction ability. The system uniformly processes the JSON structure internally, and the format switching is completed by the adapter module before sending to different platforms, ensuring the adaptability flexibility and extensibility of the system.

[0076] In summary, in the method proposed by the present invention, through the combination of the multi - protocol access interface and the multi - format intermediate protocol model, it not only meets the access requirements of multi - type operators and platforms, but also constructs a platform - neutral and highly - compatible data transfer mechanism, providing a technical basis for system expansion, international deployment, and the integration of card - writing platform capabilities.

[0077] The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit it; although the present application has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that: they can still modify the technical solutions recorded in the foregoing embodiments, or perform equivalent replacements for some of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the present application in each embodiment.

Claims

1. A method for eSIM operator and card writing data management based on a decoupled architecture, characterized in that Including: Receiving an eSIM configuration task request sent by an operator through a unified access interface module, where the configuration task request includes an ICCID, an EID, a configuration type, and target write card platform prompt information; Parsing the eSIM configuration task request into an intermediate protocol data model by an intermediate protocol conversion module, where the intermediate protocol data model is a platform-neutral data structure; The control scheduling engine selects a matching target write card platform adapter from the platform adapter management module according to a predefined scheduling policy; Invoking the target write card platform adapter to convert the intermediate protocol data model into protocol data required by the target platform and sending it to the target write card platform; Receiving a response result returned by the target write card platform and converting it into an intermediate response format by an adapter plugin and returning it to the operator.

2. The eSIM operator and card writing data management method based on a decoupled architecture according to claim 1, wherein The parsing process of the intermediate protocol conversion module includes a pre-parsing stage, a semantic abstraction stage, and a structure assembly stage. The intermediate protocol conversion module parses the eSIM configuration task request into an intermediate protocol data model and constructs a platform-neutral data structure, including: In the pre-parsing stage, performing format normalization processing on the original parameters in the eSIM configuration task request to obtain normalized parameters; In the semantic abstraction stage, invoking a predefined data semantic abstraction template to map the normalized parameters to standardized fields with platform-independent semantic tags; In the structure assembly stage, invoking an intermediate protocol structure template based on the task type and filling semantic fields in the standardized fields to generate the platform-neutral data structure.

3. The eSIM operator and card writing data management method based on a decoupled architecture according to claim 2, wherein The predefined data semantic abstraction template supports online incremental update operations. The online incremental update operation specifically includes: When receiving an incremental template change request, comparing the fields to be updated with the field identifiers in the existing semantic template to determine whether there are duplicate field names; If there are duplicate fields, further determining whether their semantic tags and data types are consistent, and marking the fields and sending a first prompt message in case of conflicts; Detecting the field mapping relationship between each semantic field in the updated template and the existing template on the same write card platform to determine whether there is a situation where the same platform field is mapped by multiple semantic tags; If there is a situation where multiple semantic tags are mapped, sending a second prompt message; Making corrections to the incremental template change request based on the first prompt message and the second prompt message to form an updated data semantic abstraction template.

4. The eSIM operator and card writing data management method based on a decoupled architecture according to claim 3, wherein Making corrections to the incremental template change request based on the first prompt message and the second prompt message to form an updated data semantic abstraction template, including: Constructing a semantic field graph, where the semantic field graph includes field names, semantic tags, field types, platform mapping relationships, and field historical usage information, and the semantic field graph is used to represent semantic similarities, conflict paths, and platform relationships between fields. Based on the repetition of field names identified in the first prompt information and the conflicts with semantic tags and data types, combined with the semantic field graph, generate a first candidate correction plan including field renaming, semantic tag merging, or field structure adjustment; Based on the situation where the same card writing platform field is mapped by multiple semantic tags identified in the second prompt information, combined with the platform field priority and conflict severity, mine the field mapping path from the semantic field graph, and generate a second candidate correction plan including main tag setting, field alias designation, or platform template splitting; Perform rule reasoning and confidence scoring on all candidate correction plans according to field semantic consistency, historical usage frequency, and platform conflict level, and output a recommendation list sorted by score; Receive the correction plan confirmed by the administrator or selected by the automatic policy, and apply it to the incremental template change request to generate the updated data semantic abstraction template.

5. The method for eSIM operator and card writing data management based on a decoupled architecture according to claim 2, wherein, It also includes: When the task type is a Profile download task, call a preset download protocol structure template, and the download protocol structure template includes fields such as ICCID, EID, Profile type, and configuration URL; When the task type is a Profile deletion task, call a preset deletion protocol structure template, and the deletion protocol structure template includes fields such as ICCID and EID; When the task type is a Profile enable task, call a preset enable protocol structure template, and the enable protocol structure template includes fields such as ICCID and target device identifier; When the task type is a status query task, call a preset status query structure template, and the status query structure template includes the ICCID field.

6. The method for eSIM operator and card writing data management based on a decoupled architecture according to claim 1, characterized in that Controlling the scheduling engine to select a matching target card writing platform adapter from the platform adapter management module according to a predefined scheduling policy includes: Query the adapter metadata registered in the platform adapter management module; Score and sort all candidate adapters according to the predefined scheduling policy; Select the target adapter with the highest score as the binding platform for the card writing task, and record the task adaptation path; If the selected adapter is unavailable, automatically switch to the standby adapter in descending order of score to continue scheduling the task.

7. The eSIM operator and card writing data management method based on a decoupled architecture according to claim 6, wherein The scheduling policy includes a priority policy, a task type adaptation policy, a geographical adaptation policy, a performance-driven policy, and a disaster tolerance policy.

8. The eSIM operator and card writing data management method based on a decoupled architecture according to claim 1, characterized in that, The unified access interface module supports RESTful interfaces, WebSocket interfaces, and MQTT protocol interfaces.

9. The eSIM operator and card writing data management method based on a decoupled architecture according to claim 1, wherein The intermediate protocol data model is in a structured JSON format or an ASN.1 abstract syntax structure.

Images