eSIM operator and card writing data management method based on decoupling architecture

Abstract

The present application discloses a method for managing eSIM operators and card writing data based on a decoupled architecture, which relates to the field of communications. The method includes: receiving an eSIM configuration task request sent by an operator, parsing the eSIM configuration task request into an intermediate protocol data model by the intermediate protocol conversion module, 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; calling the target card writing platform adapter, converting the intermediate protocol data model into the protocol data required by the target platform, and sending it to the target card writing platform; receiving the response result returned by the target card writing platform, and converting it into an intermediate response format by the adapter plug-in, and returning it to the operator. The present invention has significant technical advantages in terms of architectural flexibility, platform adaptability, scheduling intelligence, security controllability, and deployment scalability.

Description

Technical Field

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

[0002] With the widespread adoption of eSIM (embedded SIM) technology, more and more mobile devices are adopting eSIM for remote configuration and activation. The traditional physical SIM card writing process is gradually being replaced by virtualization and digitization. Operators typically implement the distribution and activation of eSIM configuration files through card writing platforms (such as SM-DP+ servers, local LPA platforms, and third-party card writing vendor systems). However, the data connection control systems between mainstream eSIM operators and card writing platforms currently suffer from the following issues:

[0003] 1. Strongly coupled docking mode: In most systems, the operator system needs to adapt the interface, configuration format, and scheduling logic for each card writing platform, which requires a lot of development and maintenance work.

[0004] 2. Lack of intermediate protocol abstraction: Protocols on different platforms vary significantly (such as JSON and ASN.1), resulting in inconsistent field structures, naming methods, and process constraints, making universal management impossible.

[0005] 3. Adapter modules are difficult to reuse: Platform adaptation logic is embedded in the main process code and lacks pluggable or hot-updating capabilities.

[0006] 4. Simple scheduling strategy: Lack of a unified scheduling control module makes it impossible to achieve intelligent distribution based on platform load and performance status.

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

[0008] The Summary of the Invention introduces a series of simplified concepts that will be further described in the Detailed Description of the Invention. The Summary of the Invention of this application is not intended to limit the key features and essential technical features of the claimed technical solution, nor is it intended to determine the scope of protection of the claimed technical solution.

[0009] In a first aspect, the present application proposes an eSIM operator and card writing data management method based on a decoupled architecture, the method comprising:

[0010] Receive an eSIM configuration task request from the operator through the unified access interface module, wherein the configuration task request includes ICCID, EID, configuration type, and target card writing platform prompt information;

[0011] The intermediate protocol conversion module parses the eSIM configuration task request into an intermediate protocol data model, wherein the intermediate protocol data model is a platform-neutral data structure;

[0012] Control the scheduling engine to select a matching target card writing platform adapter from the platform adapter management module according to a predefined scheduling policy;

[0013] Call the target card writing platform adapter, convert the intermediate protocol data model into the protocol data required by the target platform, and send it to the target card writing platform;

[0014] The response result returned by the target card writing platform is received and converted into an intermediate response format by the adapter plug-in and returned to the operator.

[0015] In a feasible implementation, the parsing process of the intermediate protocol conversion module includes a pre-parsing stage, a semantic abstraction stage, and a structure assembly stage.

[0016] 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:

[0017] In the pre-parsing stage, the original parameters in the eSIM configuration task request are normalized to obtain normalized parameters.

[0018] In the semantic abstraction stage, a predefined data semantic abstraction template is called to map the normalized parameters into standardized fields with platform-independent semantic labels.

[0019] In the above structure assembly phase, the intermediate protocol structure template is called based on the task type, and the semantic fields are filled in the above standardized fields to generate the above platform-neutral data structure.

[0020] In a feasible implementation, the predefined data semantic abstract template supports an online incremental update operation, which specifically includes:

[0021] When receiving an incremental template change request, compare the field to be updated with the field identifiers in the existing semantic template to determine whether there is a duplication of field names;

[0022] If there are fields with duplicate names, the system further determines whether their semantic labels and data types are consistent. If there is a conflict, the field is marked and the first prompt message is issued.

[0023] Check the mapping relationship between each semantic field in the updated template and the field of the existing template on the same card writing platform to determine whether the same platform field is mapped by multiple semantic tags;

[0024] If there are multiple semantic label mappings, a second prompt message is issued;

[0025] The incremental template change request is modified based on the first prompt information and the second prompt information to form an updated data semantic abstract template.

[0026] In a feasible implementation, the modification of the incremental template change request based on the first prompt information and the second prompt information to form an updated data semantic abstract template includes:

[0027] Constructing a semantic field graph, wherein the semantic field graph includes field name, semantic label, field type, platform mapping relationship, and field historical usage information. The semantic field graph is used to represent semantic similarity, conflict paths, and platform relationships between fields.

[0028] Based on the field name duplication, semantic label, and data type conflicts identified in the first prompt information, combined with the semantic field graph, a first candidate correction solution is generated, including field renaming, semantic label merging, or field structure adjustment.

[0029] Based on the situation identified in the second prompt information above where the same card writing platform field is mapped to multiple semantic labels, the field mapping path is mined from the semantic field graph in combination with the platform field priority and conflict severity, and a second candidate correction solution is generated, including primary label setting, field alias assignment, or platform template splitting.

[0030] All candidate correction solutions are subjected to rule reasoning and confidence scoring based on field semantic consistency, historical usage frequency, and platform conflict level, and a recommendation list is output based on the ranking of scores.

[0031] Receive the correction plan 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 abstract template.

[0032] In a feasible implementation, it further includes:

[0033] When the task type is a Profile download task, a preset download protocol structure template is called. The download protocol structure template includes ICCID, EID, Profile type, and configuration URL fields.

[0034] When the task type is a Profile deletion task, the preset deletion protocol structure template is called. The deletion protocol structure template includes ICCID and EID fields.

[0035] When the task type is a Profile activation task, a preset activation protocol structure template is called, and the activation protocol structure template includes ICCID and target device identification fields;

[0036] When the task type is a status query task, a preset status query structure template is called, and the status query structure template includes an ICCID field.

[0037] In a feasible implementation manner, the above-mentioned control of the above-mentioned scheduling engine to select a matching target card writing platform adapter from the platform adapter management module according to a predefined scheduling policy includes:

[0038] Query the adapter metadata registered in the above platform adapter management module;

[0039] Score and rank all candidate adapters according to the predefined scheduling policy;

[0040] Select the target adapter with the highest score as the binding platform for the card writing task and record the task adaptation path;

[0041] If the selected adapter is unavailable, it will automatically switch to the backup adapter in descending order of scores to continue scheduling the task.

[0042] In a feasible implementation, the above-mentioned scheduling strategy includes a priority strategy, a task type adaptation strategy, a geographical adaptation strategy, a performance-driven strategy, and a disaster recovery strategy.

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

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

[0045] In summary, the present invention achieves full-process logical decoupling between the operator system and various card writing platforms by introducing an intermediate protocol mechanism and a plug-in adaptation architecture. Operators only need to submit standardized configuration task requests to the system without having to understand the protocol details and call interface of the target platform, thereby significantly reducing the complexity of platform access and upgrades. Secondly, the control and scheduling engine set up within the system has intelligent decision-making capabilities and supports multi-dimensional scheduling strategies based on task type, platform operating status, load conditions, regional attributes, etc., dynamically selecting the most suitable card writing platform to execute configuration tasks, significantly improving platform resource utilization and task success rate. In terms of protocol processing, the present invention supports 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 format according to the needs of the target platform. It has good versatility and protocol adaptability, and meets the technical challenges brought by interface differences between different platforms. The overall system operation process is highly transparent to operators. Operators only need to submit the core parameters of the task, and the system will automatically complete platform selection, protocol packaging, and result feedback, realizing a "one-stop access, multi-platform execution" service experience. In addition, the system provides a variety of access methods and is compatible with the three mainstream communication protocols of REST, WebSocket and MQTT. It is not only suitable for access to traditional enterprise information systems, but also for the lightweight access needs of IoT terminals, mobile terminals and edge platforms. From the perspective of operation and maintenance and security, the system records full-link log data including task parameters, adaptation paths, platform responses and execution results throughout the entire process, supports task traceability, anomaly location and security auditing, and further enhances the governability of the system. Finally, the system has good scalability and maintainability. A new card writing platform only needs to register a new adapter plug-in to go online without changing the core system logic, which effectively reduces the platform expansion and maintenance costs. The present invention has significant technical advantages in terms of architectural flexibility, platform adaptability, scheduling intelligence, security controllability and deployment scalability. It is suitable for eSIM configuration management scenarios in multi-operator and multi-platform environments, and has broad application prospects and engineering value.

[0046] The eSIM operator and card writing data management method based on the decoupled architecture proposed in this application, and other advantages, objectives and features of this application will be reflected in part through the following description, and in part will be understood by technical personnel in this field through research and practice of this application. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] Various other advantages and benefits will become apparent to those skilled in the art upon reading the detailed description of the preferred embodiment below. The accompanying drawings are for illustration purposes only and are not to be considered as limiting the present description. The same reference symbols are used throughout the drawings to represent the same components. In the drawings:

[0048] Figure 1 A schematic diagram of the process of managing eSIM operators and card writing data based on a decoupled architecture provided in an embodiment of the present application. DETAILED DESCRIPTION

[0049] The terms "first", "second", "third", "fourth", etc. (if any) in the specification and claims of this application and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that the numbers used in this way can be interchanged where appropriate so that the embodiments described herein can be implemented in an order other than that illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices. The technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the embodiments described are only some embodiments of the present application, not all embodiments.

[0050] See also Figure 1 , which is a process diagram of the eSIM operator and card writing data management method based on the decoupled architecture, which may specifically include:

[0051] S110. Receive, through the unified access interface module, an eSIM configuration task request sent by an operator, wherein the configuration task request includes ICCID, EID, configuration type, and target card writing platform prompt information;

[0052] For example, the unified access interface module receives the eSIM configuration task request initiated by the operator. The module supports multiple communication protocols such as RESTful API, WebSocket or MQTT, and has identity authentication and interface permission verification functions.

[0053] The above configuration task request includes but is not limited to the following fields:

[0054] ICCID: configured eSIM card identifier;

[0055] EID: unique identifier of the terminal device;

[0056] Configuration type: including Profile download, deletion, activation, etc.;

[0057] Target card writing platform prompt information: an optional field used to guide scheduling policy preferences.

[0058] S120: The intermediate protocol conversion module parses the eSIM configuration task request into an intermediate protocol data model, wherein the intermediate protocol data model is a platform-neutral data structure;

[0059] Exemplarily, the intermediate protocol conversion module performs a multi-stage conversion on the request to generate a platform-neutral intermediate protocol data model. The conversion process is divided into:

[0060] Pre-parsing stage: unify the format of input parameters and verify the field type;

[0061] Semantic abstraction stage: calling semantic templates to map fields to standard semantic labels (such as SIM_IDENTIFIER and DEVICE_IDENTIFIER).

[0062] Structure assembly phase: Based on the task type (such as Download), the corresponding intermediate protocol template is called, the semantic fields are filled, and the standard intermediate protocol data structure (JSON or ASN.1) is generated.

[0063] S130, 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;

[0064] Exemplarily, the control and scheduling engine selects a target card writing platform adapter from the platform adapter management module based on predefined policies. These policies may include matching task type with platform capabilities, current platform load and availability, historical platform success rate, platform priority and geographic location, and disaster recovery mechanisms. The system ranks all candidate platforms by score and selects the highest-scoring platform as the execution platform.

[0065] S140: Call the target card writing platform adapter to convert the intermediate protocol data model into protocol data required by the target platform and send the data to the target card writing platform.

[0066] For example, the adapter receives the intermediate protocol data model delivered by the scheduling engine and converts it into a platform-specific format based on the protocol requirements of the target platform. This format can be structured JSON, ASN.1 encoding, XML structure, or Base64-encapsulated instruction fragments. During the conversion process, the adapter can invoke built-in protocol templates and field mapping rules to ensure that the generated data structure conforms to the platform interface specifications.

[0067] After completing the protocol conversion, the adapter constructs specific call parameters, including but not limited to task instructions, authentication credentials, platform identification, device identification, etc., and sends 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).

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

[0069] S150: Receive the response result returned by the target card writing platform, convert it into an intermediate response format by the adapter plug-in, and return it to the operator.

[0070] Exemplarily, the adapter then waits for the platform to respond, which may be provided via asynchronous push, synchronous postback, or status polling. Upon receiving the platform response, the adapter parses it into a uniformly formatted intermediate response structure, which indicates the task execution status (e.g., success, failure, queued), an optional error code, and platform feedback information.

[0071] The system returns the intermediate response from the adapter to the operator along the original call channel, for example, via HTTP synchronous response, WebSocket message push, or MQTT topic message publishing, accurately delivering the task execution results to the initiator. Simultaneously, the system records the complete task processing trajectory in the platform log module for subsequent auditing, status query, and performance analysis.

[0072] In summary, the present invention achieves full-process logical decoupling between the operator system and various card writing platforms by introducing an intermediate protocol mechanism and a plug-in adaptation architecture. Operators only need to submit standardized configuration task requests to the system without having to understand the protocol details and call interface of the target platform, thereby significantly reducing the complexity of platform access and upgrades. Secondly, the control and scheduling engine set up within the system has intelligent decision-making capabilities and supports multi-dimensional scheduling strategies based on task type, platform operating status, load conditions, regional attributes, etc., dynamically selecting the most suitable card writing platform to execute configuration tasks, significantly improving platform resource utilization and task success rate. In terms of protocol processing, the present invention supports 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 format according to the needs of the target platform. It has good versatility and protocol adaptability, and meets the technical challenges brought by interface differences between different platforms. The overall system operation process is highly transparent to operators. Operators only need to submit the core parameters of the task, and the system will automatically complete platform selection, protocol packaging, and result feedback, realizing a "one-stop access, multi-platform execution" service experience. In addition, the system provides a variety of access methods and is compatible with the three mainstream communication protocols of REST, WebSocket and MQTT. It is not only suitable for access to traditional enterprise information systems, but also for the lightweight access needs of IoT terminals, mobile terminals and edge platforms. From the perspective of operation and maintenance and security, the system records full-link log data including task parameters, adaptation paths, platform responses and execution results throughout the entire process, supports task traceability, anomaly location and security auditing, and further enhances the governability of the system. Finally, the system has good scalability and maintainability. A new card writing platform only needs to register a new adapter plug-in to go online without changing the core system logic, which effectively reduces the platform expansion and maintenance costs. The present invention has significant technical advantages in terms of architectural flexibility, platform adaptability, scheduling intelligence, security controllability and deployment scalability. It is suitable for eSIM configuration management scenarios in multi-operator and multi-platform environments, and has broad application prospects and engineering value.

[0073] In a feasible implementation, the parsing process of the intermediate protocol conversion module includes a pre-parsing stage, a semantic abstraction stage, and a structure assembly stage.

[0074] 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:

[0075] In the pre-parsing stage, the original parameters in the eSIM configuration task request are normalized to obtain normalized parameters.

[0076] In the semantic abstraction stage, a predefined data semantic abstraction template is called to map the normalized parameters into standardized fields with platform-independent semantic labels.

[0077] In the above structure assembly phase, the intermediate protocol structure template is called based on the task type, and the semantic fields are filled in the above standardized fields to generate the above platform-neutral data structure.

[0078] For example, first, during the pre-parsing phase, the system receives the original eSIM configuration task request from the unified access interface module. This request may come from different operators, and there may be certain differences in their field naming, format type, or transmission encoding. To ensure the consistency of system processing, all original parameters are uniformly processed in this phase, including field name standardization, data type normalization, default value filling, and structure flattening, thereby generating 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, the system normalizes and maps them to the standard internal field iccid.

[0079] Next, the semantic abstraction phase begins. During this phase, the system calls upon a predefined library of data semantic abstraction templates to semantically annotate and label normalized parameters. Each field is assigned a platform-independent semantic label (such as SIM_IDENTIFIER, DEVICE_IDENTIFIER, PROFILE_TYPE), along with its data type, constraints, and platform-specific mapping. This abstraction not only imparts unified semantics to the fields but also lays the foundation for subsequent cross-platform mapping and protocol generation. For example, the profileType field, regardless of whether its source data is "Primary," "P," or "01," can be converted to the unified semantic label PROFILE_TYPE through the template and standardized to "Primary."

[0080] After completing field abstraction, the system enters the structure assembly phase. The core task of this phase is to call the corresponding intermediate protocol structure template from the structure template library based on the task type (such as profile download, deletion, activation, or status query). The template defines the field structure, field order, nesting level, and necessary constraints. The system populates the semantically abstracted fields one by one into the structure according to the template requirements, ultimately constructing a data structure model that meets the system's internal standards. This structure, typically in formats such as JSON or ASN.1, can be directly called by subsequent adapter modules for protocol conversion and task delivery.

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

[0082] In a feasible implementation, the predefined data semantic abstract template supports an online incremental update operation, which specifically includes:

[0083] When receiving an incremental template change request, compare the field to be updated with the field identifiers in the existing semantic template to determine whether there is a duplication of field names;

[0084] If there are fields with duplicate names, the system further determines whether their semantic labels and data types are consistent. If there is a conflict, the field is marked and the first prompt message is issued.

[0085] Check the mapping relationship between each semantic field in the updated template and the field of the existing template on the same card writing platform to determine whether the same platform field is mapped by multiple semantic tags;

[0086] If there are multiple semantic label mappings, a second prompt message is issued;

[0087] The incremental template change request is modified based on the first prompt information and the second prompt information to form an updated data semantic abstract template.

[0088] For example, to adapt to the evolving interface specifications of multiple carriers and card writing platforms within the eSIM carrier-card writing platform data connection control system, the predefined data semantic abstract templates used in the system support online incremental updates. This mechanism allows for dynamic adjustments to field semantic mappings, data structure standards, and platform field adaptation logic without interrupting the main system, ensuring the system's maintainability and scalability.

[0089] First, when the system receives an incremental template change request, it loads the request into the semantic sandbox environment and compares and analyzes it against the currently active semantic abstract template. A change request typically includes one or more field definition updates, such as adding a new field, a field alias, modifying a data type, or adjusting platform mappings.

[0090] After a preliminary comparison, the system first determines whether there are any duplicate field names. Specifically, it determines whether the field name defined in the template to be updated already appears in the current template. If a field with the same name exists, the system further determines whether the semantic tag for the field in the old and new templates is consistent and whether the data type is compatible. If a semantic tag conflict is detected (e.g., the original DEVICE_IDENTIFIER is now ORDER_CODE) or a data type inconsistency (e.g., the original string is now integer), the field is marked as a conflicting field and a first prompt is automatically generated to alert administrators to the inconsistent field definition.

[0091] Subsequently, the system continues to verify the mapping relationship between the fields involved in the update 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 the same platform field name is mapped by multiple semantic tags at the same time. For example, if the field sim_id in the PLAT_A platform is mapped to 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 problem in the mapping of fields across semantic tags.

[0092] After the first and second prompts are generated, the system will enter the template modification phase. Based on the field conflicts identified in the prompts, the system will provide several correction suggestions, including but not limited to: renaming fields (such as renaming a new field to profileTypeV2); setting semantic primary labels and secondary aliases; splitting the platform field mapping scope; and clarifying the binding relationship between the field scope and task type.

[0093] Finally, the revised template content is revalidated in the semantic sandbox. If it passes the consistency check, it is written into the official template library as the updated data semantic abstract template, and the corresponding version number is updated. Once the update takes effect, the system can then perform intermediate protocol construction and field semantic mapping based on the new template, ensuring compatibility with old tasks and support for new tasks.

[0094] In a feasible implementation, the modification of the incremental template change request based on the first prompt information and the second prompt information to form an updated data semantic abstract template includes:

[0095] Constructing a semantic field graph, wherein the semantic field graph includes field name, semantic label, field type, platform mapping relationship, and field historical usage information. The semantic field graph is used to represent semantic similarity, conflict paths, and platform relationships between fields.

[0096] Based on the field name duplication, semantic label, and data type conflicts identified in the first prompt information, combined with the semantic field graph, a first candidate correction solution is generated, including field renaming, semantic label merging, or field structure adjustment.

[0097] Based on the situation identified in the second prompt information above where the same card writing platform field is mapped to multiple semantic labels, the field mapping path is mined from the semantic field graph in combination with the platform field priority and conflict severity, and a second candidate correction solution is generated, including primary label setting, field alias assignment, or platform template splitting.

[0098] All candidate correction solutions are subjected to rule reasoning and confidence scoring based on field semantic consistency, historical usage frequency, and platform conflict level, and a recommendation list is output based on the ranking of scores.

[0099] Receive the correction plan 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 abstract template.

[0100] For example, in order to improve the intelligence and controllability of the template update process, when processing incremental template change requests, the system introduces a semantic graph-assisted correction mechanism after conflict identification based on the first prompt information and the second prompt information, forming a structured decision support process to achieve high-quality evolution and automated governance of incremental templates.

[0101] First, the system builds and maintains a semantic field graph, which is used to model the history and current state 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 (recording the mapping path of the field on different platforms, such as PLAT_A→config_type), and historical field usage information (such as usage frequency, task context, change history, etc.).

[0102] The graph establishes semantic similarities between fields, field conflict paths, and platform usage relationships through the relationships between nodes and edges, providing contextual basis for subsequent reasoning.

[0103] Next, the system processes the duplication of field names identified in the first prompt message. Specifically, based on the semantic label similarity and data type compatibility between fields in the semantic graph, the system generates a set of first candidate correction solutions. Its correction strategies include: field renaming: renaming conflicting fields (such as profileTypeV2) to preserve historical compatibility; semantic label merging: if the semantic labels of the new and old fields have similarities or can be merged logically (such as DEVICE_ID and HARDWARE_ID), it is recommended to unify the labels; field structure adjustment: such as splitting complex fields into multiple subfields, or expanding enumeration fields into structure fields.

[0104] Subsequently, the system further processes the second prompt information, which is used to identify conflicting situations where the same card writing platform field is mapped by multiple semantic labels. The system combines the priority rules of the platform fields (for example, the main platform field cannot be remapped) with historical conflict records, and dynamically analyzes the many-to-many mapping relationship between the field and the platform from the semantic graph to generate a second candidate correction plan, including but not limited to: Main label setting: Establish a unique semantic main label for the platform field, and the rest are aliases or restricted contexts; Field alias assignment: Resolve multi-label conflicts by setting semantic alias mapping relationships; Platform template splitting: When the conflict cannot be resolved, split the conflicting field into multiple platform-specific sub-templates for isolation.

[0105] After candidate fixes are generated, the system uses a rule-based reasoning mechanism and a confidence scoring system to comprehensively evaluate each solution. Scoring criteria include factors such as the degree of semantic consistency of fields, the frequency of historical field usage (frequently used fields are recommended to be retained), and the severity of platform conflicts. A weighted ranking is then generated based on the results.

[0106] The system ultimately outputs the highest-scoring revisions as recommendations and presents them to the template administrator for approval. The administrator can choose to accept the recommendations or fine-tune the merge strategy within the visual interface. In low-risk change scenarios, the system can also automatically select and execute the optimal revision based on pre-set strategies.

[0107] The confirmed revision plan will be formally applied to the original incremental template change request, generating an updated data semantic abstract template with a new version number, source identifier, and scope of application, which will then be written to the template version control system. This updated template will serve as the basis for field mapping when constructing the intermediate protocol data structure in subsequent configuration tasks, ensuring the stability and consistency of system processing.

[0108] In a feasible implementation, it further includes:

[0109] When the task type is a Profile download task, a preset download protocol structure template is called. The download protocol structure template includes ICCID, EID, Profile type, and configuration URL fields.

[0110] When the task type is a Profile deletion task, the preset deletion protocol structure template is called. The deletion protocol structure template includes ICCID and EID fields.

[0111] When the task type is a Profile activation task, a preset activation protocol structure template is called, and the activation protocol structure template includes ICCID and target device identification fields;

[0112] When the task type is a status query task, a preset status query structure template is called, and the status query structure template includes an ICCID field.

[0113] For example, during the structure assembly phase, the intermediate protocol conversion module predefines various intermediate protocol structure templates to ensure that different types of eSIM configuration tasks correctly generate data structures that conform to business semantics and platform requirements. Based on the task type, the system automatically calls the corresponding template to populate the structure and generate a platform-neutral data model. This process implements a task-type-driven structure template selection mechanism, ensuring the structural integrity and adaptation accuracy of the issued request.

[0114] Specifically, the mechanism supports the following structural templates for typical eSIM task types:

[0115] First, when the task type is a Profile download task (i.e., Download Profile), the system automatically invokes a pre-set download protocol structure template. This template carries the complete configuration data required to perform the card write operation. Its structure includes, but is not limited to, the following fields: ICCID (eSIM card identifier); EID (device unique identifier); Profile type (e.g., Primary, Secondary); and configuration URL (the download address for the configuration file). During the structure assembly phase, the system populates the corresponding semantic fields (e.g., SIM_IDENTIFIER, DEVICE_IDENTIFIER) into these template fields, forming a standard download request structure.

[0116] Secondly, when the task type is a profile deletion task, the system calls the deletion protocol structure template. This template is relatively simple, containing only the ICCID and EID. This structure is used to issue the "deregistration / unbinding" operation instruction to the card writing platform. The template design ensures the uniqueness and security of the deletion operation target.

[0117] Next, when the task type is a Profile Activation task, the system invokes the Activation Protocol structure template. This template specifies the binding of an eSIM configuration activation to a specific device. Key fields include: ICCID; target device identifier (typically an EID or a local binding identifier, such as deviceId). The structure of this task template guides the platform in initiating the eUICC internal profile activation process, ensuring the profile is active on the device.

[0118] Finally, when the task type is a status query task, the system calls the status query structure template. This template structure is the most concise, typically containing only the ICCID. It is used to query the target platform about the current status of an eSIM card (such as whether the card was successfully written, whether it is activated, and whether it is available).

[0119] In actual system operation, the invocation of structural templates is automatically completed by the template manager within the intermediate protocol conversion module. After receiving the normalized and semantically abstracted parameters, the system matches the corresponding template based on the task type identifier and populates the standardized fields into the corresponding structural positions in the template, thereby generating an intermediate protocol data model that conforms to the task semantics, has complete fields, and a unified format. Through the application of this mechanism, the system supports a variety of business task types while ensuring the consistency of field definitions and structural specifications, effectively improving cross-platform adaptability and configuration delivery accuracy.

[0120] In a feasible implementation manner, the above-mentioned control of the above-mentioned scheduling engine to select a matching target card writing platform adapter from the platform adapter management module according to a predefined scheduling policy includes:

[0121] Query the adapter metadata registered in the above platform adapter management module;

[0122] Score and rank all candidate adapters according to the predefined scheduling policy;

[0123] Select the target adapter with the highest score as the binding platform for the card writing task and record the task adaptation path;

[0124] If the selected adapter is unavailable, it will automatically switch to the backup adapter in descending order of scores to continue scheduling the task.

[0125] In a feasible implementation, the above-mentioned scheduling strategy includes a priority strategy, a task type adaptation strategy, a geographical adaptation strategy, a performance-driven strategy, and a disaster recovery strategy.

[0126] For example, the control scheduling engine selects matching target card writing platform adapters from the platform adapter management module based on predefined scheduling policies. This process uses a scoring-driven intelligent selection mechanism to achieve the optimal match between tasks and card writing platforms, thereby improving task success rates and platform resource utilization efficiency. This process primarily includes four consecutive steps: adapter metadata acquisition, scoring and ranking, task binding, and disaster recovery fallback.

[0127] First, after receiving a complete intermediate protocol data model, the scheduling engine immediately queries the platform adapter management module for metadata information about all currently registered adapters. This metadata includes, but is not limited to: the task types supported by the adapter (e.g., whether it supports Download, Enable, Delete, etc.); the platform identifier and regional coverage information; the interface protocol type (e.g., HTTP, HTTPS, dedicated line); the current operating status (Active / Inactive); historical task success rates and exception statistics; real-time performance metrics (e.g., response latency, queue length, last available time); and the degree of match with the operator's task policy preferences.

[0128] Based on the metadata and task context, the scheduling engine executes a predefined scheduling policy evaluation model on all candidate adapters. This evaluation process assigns a weighted score to each adapter, forming a multi-dimensional suitability score (fitness score). Specifically, it considers the following typical policy factors: Task type adaptation strategy: Adapters explicitly marked as supporting the current task type receive additional points; Platform health strategy: Platforms with no fault markers, short response times, and a high recent success rate receive additional points; Regional priority strategy: Platform adapters located in the same geographic region as the task's designated region receive additional points; Operator preference strategy: Target platform notifications specified in the operator interface receive additional points if the platform matches the target platform; Load balancing strategy: The scheduling engine prioritizes dispatching if the platform's current load is moderate.

[0129] Each adapter will output a comprehensive score value (for example, Score=0.92), and the adapter list will be sorted in descending order based on the score results.

[0130] After completing the scoring, the scheduling engine selects the adapter with the highest score from the sorting results as the target platform adapter, and binds the current task to the adapter to form an adaptation path mapping record of "task ID→adapter ID→platform ID". The path information will be recorded by the system in the task scheduling log for subsequent traceability and status tracking.

[0131] If, during the adapter invocation process, the preferred adapter is found to be unavailable due to network anomalies, platform failures, or response timeouts, the system immediately triggers a disaster recovery strategy, automatically trying backup adapters in descending order of score until an available platform is selected or the maximum retry threshold is exceeded. This disaster recovery mechanism ensures high-availability scheduling in the face of single-point platform failures, preventing task failures or prolonged blockages.

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

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

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

[0135] The RESTful interface is primarily used for synchronous invocation of configuration tasks initiated by traditional IT systems or operation platforms. It supports submitting eSIM configuration tasks (for example, subscribing to a profile or deleting a profile) via HTTPS POST. The system returns a standard HTTP status code and a JSON structured response.

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

[0137] The MQTT protocol interface is designed for IoT device operators and adopts a lightweight message publish / subscribe model, suitable for low-bandwidth, high-concurrency scenarios. Operators receive task result push notifications by subscribing to topics, improving data flow efficiency.

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

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

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

[0141] When the target card writing platform supports the standard HTTP / JSON interface, the intermediate protocol data model uses the JSON format, which has a clear field structure and strong scalability, making it suitable for dynamic generation and debugging. For example:

[0142] When the target platform requires strict structure definition or secure encapsulation (such as when using the SM-DP+ protocol), the intermediate protocol data model can adopt an ASN.1 structure, supporting binary encapsulation, BER / DER encoding, and signature verification. This structure can be encoded and converted in the adapter using predefined templates, automatically generating an ASN.1 representation from the semantic fields.

[0143] By providing dual-format support, the intermediate protocol model achieves a high level of protocol abstraction. The system uniformly processes JSON structures internally, with adapter modules completing format switching before sending to different platforms, ensuring the system's adaptability and scalability.

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

[0145] The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A method for managing eSIM operators and card writing data based on a decoupled architecture, characterized in that: include: Receive an eSIM configuration task request from the operator through the unified access interface module, where the configuration task request includes the ICCID, EID, configuration type, and target card writing platform prompt information. The configuration type includes profile download, deletion, and activation. The target card writing platform prompt information is used to guide scheduling policy preferences; The intermediate protocol conversion module parses the eSIM configuration task request into an intermediate protocol data model, wherein the intermediate protocol data model is a platform-neutral data structure; The control scheduling engine selects a matching target card writing platform adapter from the platform adapter management module according to a predefined scheduling policy; Calling the target card writing platform adapter, converting the intermediate protocol data model into the protocol data required by the target platform, and sending it to the target card writing platform; Receive the response result returned by the target card writing platform, convert it into an intermediate response format by the target card writing platform adapter, and return it to the operator; The 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: Querying the adapter metadata registered in the platform adapter management module, wherein the adapter metadata includes the task types supported by the adapter, the platform identification and regional coverage information, the interface protocol type, the current operating status, the historical task success rate and exception statistics, the real-time performance indicators, and the degree of matching with the operator's task policy preferences; Score and rank all candidate adapters according to the predefined scheduling policy; The target adapter with the highest score is selected as the target platform adapter, and the current task is bound to the adapter to form an adaptation path mapping record of the task ID, adapter ID and platform ID; If the selected adapter is unavailable, it will automatically switch to the backup adapter according to the descending score to continue scheduling the task; The scheduling strategies include priority strategy, task type adaptation strategy, geographic adaptation strategy, performance driven strategy and disaster recovery strategy.

2. The eSIM operator and card writing data management method based on the decoupling architecture according to claim 1 is characterized in that: 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, format normalization is performed on the original parameters in the eSIM configuration task request to obtain normalized parameters; In the semantic abstraction stage, a predefined data semantic abstraction template is called to map the normalized parameters into standardized fields with platform-independent semantic labels; In the structure assembly phase, the intermediate protocol structure template is called based on the task type, and the semantic fields are filled in the standardized fields to generate the platform-neutral data structure.

3. The eSIM operator and card writing data management method based on the decoupling architecture according to claim 2 is characterized in that: The predefined data semantic abstract template supports online incremental update operations, which specifically include: When receiving an incremental template change request, compare the field to be updated with the field identifiers in the existing semantic template to determine whether there is a duplication of field names; If there are fields with duplicate names, the system further determines whether their semantic labels and data types are consistent. If there is a conflict, the field is marked and the first prompt message is issued. Check the mapping relationship between each semantic field in the updated template and the field of the existing template on the same card writing platform to determine whether the same platform field is mapped by multiple semantic tags; If there are multiple semantic label mappings, a second prompt message is issued; The incremental template change request is modified based on the first prompt information and the second prompt information to form an updated data semantic abstract template.

4. The eSIM operator and card writing data management method based on the decoupling architecture according to claim 3 is characterized in that: The step of modifying the incremental template change request based on the first prompt information and the second prompt information to form an updated data semantic abstract template includes: Constructing a semantic field graph, wherein the semantic field graph includes field name, semantic label, field type, platform mapping relationship, and field historical usage information. The semantic field graph is used to represent semantic similarity, conflict path, and platform relationship between fields; Based on the conflict between the field name duplication, semantic label, and data type identified in the first prompt information, and in combination with the semantic field graph, a first candidate correction solution is generated, including field renaming, semantic label merging, or field structure adjustment; Based on the situation where the same card writing platform field identified in the second prompt information is mapped to multiple semantic labels, the field mapping path is mined from the semantic field map in combination with the platform field priority and conflict severity, and a second candidate correction solution is generated, including primary label setting, field alias assignment, or platform template splitting. All candidate correction solutions are subjected to rule reasoning and confidence scoring based on field semantic consistency, historical usage frequency, and platform conflict level, and a recommendation list is output based on the ranking of scores. A correction scheme confirmed by an administrator or selected by an automatic policy is received, and the correction scheme is applied to the incremental template change request to generate the updated data semantic abstract template.

5. The eSIM operator and card writing data management method based on the decoupling architecture according to claim 2, characterized in that: Also includes: When the task type is a Profile download task, a preset download protocol structure template is called, and the download protocol structure template includes ICCID, EID, Profile type and configuration URL fields; When the task type is a Profile deletion task, a preset deletion protocol structure template is called, and the deletion protocol structure template includes ICCID and EID fields; When the task type is a Profile activation task, calling a preset activation protocol structure template, the activation protocol structure template includes ICCID and target device identification fields; When the task type is a status query task, a preset status query structure template is called, and the status query structure template includes an ICCID field.

6. The eSIM operator and card writing data management method based on the decoupling architecture according to claim 1, characterized in that: The unified access interface module supports RESTful interface, WebSocket interface and MQTT protocol interface.

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

Images