Systems, methods, and apparatus for improved connectivity distribution

Abstract

A system, process, and apparatus comprising an orchestration agent and an orchestration center are disclosed. The orchestration agent is operatively connected to the eUICC and memory at a mobile computing device. The orchestration center includes a processor and a database comprising centralized network subscription information. The orchestration center can receive updated network subscription information from a device management and network connectivity management platform. The orchestration center can compare the updated network subscription information with multiple subscription records in the centralized network subscription information. The orchestration center generates a new subscription record based on the updated network subscription information, including the current network subscription information. The orchestration agent can replace one or more information fields of the subscription edge record at the eUICC and memory with corresponding information fields from the new subscription record.

Description

[0001] Cross-reference to related applications This application claims the benefit and priority of U.S. Provisional Patent Application No. 63 / 553,402, filed February 14, 2024, entitled “SYSTEMS, METHODS, AND APPARATUSESFOR IMPROVED CONNECTIVITY DISTRIBUTION”, the disclosure of which is incorporated herein by reference in its entirety as if it were fully set forth herein. Technical Field

[0002] This system, process, and apparatus generally relates to digital telecommunications, and more specifically to systems, methods, and apparatus for improved connectivity distribution.

[0003] background Remote SIM Provisioning (RSP) involves the process of downloading and managing eSIM profiles on mobile devices to connect to cellular networks. Over the years, RSP for consumer devices, such as mobile phones, has improved thanks to advancements in standards and specifications, including SGP.02, SGP.22, and SGP.32, by organizations such as the GSMA. However, RSP faces numerous challenges when applied to Internet of Things (IoT) devices, particularly unattended ones. While RSP can offer substantial benefits for IoT system management, none of SGP.02, SGP.22, and SGP.32 provides each of the following capabilities to overcome the drawbacks of using RSP for IoT system management: synchronizing RSP operation with device operation and availability; including subscription context information with the downloaded eSIM profile; providing access to an RSP server when the internet is unavailable; enabling downloads over non-cellular connectivity; and enabling local profile management. Therefore, there is a long-standing but unmet need for systems, methods, and apparatuses for improving connectivity distribution by deploying mobile network subscriber identities to IoT devices.

[0004] Brief Overview Briefly described and according to one embodiment, aspects of this disclosure generally relate to systems, methods, and apparatus for improved cellular device connectivity distribution.

[0005] In particular, aspects of this disclosure relate to Remote SIM Configuration (RSP) in Internet of Things (IoT) environments. For example, consider scenarios where hundreds, thousands, or even hundreds of thousands of cellular IoT devices require information related to accessing one or more cellular networks for receiving and transmitting data. According to various aspects of this disclosure, the systems described herein include an orchestration hub for synchronously transmitting cellular network subscription information to IoT devices from a centralized location, based on device availability. In at least one example, the orchestration hub may be operatively connected to one or more device management systems (device managers). The orchestration hub may also be operatively connected to one or more connectivity management systems (connectivity managers). According to various aspects of this disclosure, the orchestration hub can install, configure, update, and delete subscriptions (including subscriber identity and subscription context) on remote IoT devices. Aspects of this disclosure also support profile content management and eSIM profiles with multiple IMSIs.

[0006] In at least one example, the orchestration center can be operatively configured to receive subscription source lines from one or more device managers, connectivity managers, and other management platforms. The orchestration center can determine whether the subscription source line includes updated subscription configuration information, and can merge the updated subscription configuration information into a record of subscription information stored within the orchestration center. Merging the updated subscription configuration information into the record of subscription information stored within the orchestration center can include generating new subscription information record entries (subscription information "lines"), replacing or overwriting existing subscription information stored within the orchestration center, and so on. In some examples, the orchestration center can generate and transmit Remote SIM Configuration (RSP) Application Protocol Data Unit (APDU) messages to IoT devices in response to them becoming available (e.g., waking from an idle state, completing a separate processing task, connecting to a network, etc.). The RSP APDU can include updated subscription configuration information, which can replace pre-existing subscription information at the IoT device.

[0007] Furthermore, this disclosure allows device operations (e.g., queries transmitted to devices to initiate specific actions) to be organized as campaigns. In one example, a campaign can be a set of sequentially ordered operations applied to one or more devices. While the operations can be sequential and ordered for each device in a campaign, the devices themselves can be processed in parallel. For example, a campaign may include two installation operations followed by a deletion operation, each performed on multiple devices. For example, for a campaign applying to 500 devices, the orchestration center can initiate 500 installation operations simultaneously. In at least one example, when an installation operation is completed, the orchestration center can begin subsequent operations device by device. Campaigns can provide a favorable management structure where RSP operations may incur costs, and the costs of RSP operations can be controlled and accounted for differently from other aspects of device management.

[0008] According to the first aspect or any other aspect, this disclosure discusses a system comprising: an orchestration agent including software configuration installed at a mobile computing device, wherein the orchestration agent is operatively connected to an embedded universal integrated circuit card (eUICC) and memory at the mobile computing device; and an orchestration center operatively connected to the orchestration agent, wherein the orchestration center includes a processor and a database including centralized network subscription information from one or more management platforms, wherein the processor is operatively configured to: receive a first updated network subscription information from a device management platform among the one or more management platforms; and receive a second updated network subscription information from a network connectivity management platform among the one or more management platforms. The process involves: reading information; comparing the first and second updated network subscription information with multiple subscription records in the centralized network subscription information; in response to determining a specific subscription record among the multiple subscription records, a common identifier between the first and second updated network subscription information, generating a new subscription record including the current network subscription information based on the first and second updated network subscription information; and transmitting a copy of the new subscription record to an orchestration agent at the mobile computing device, wherein the orchestration agent is operatively configured to replace one or more information fields of the subscription edge record at eUICC and memory with corresponding information fields from the copy of the new subscription record.

[0009] According to the second aspect or any other aspect, the public identifier is the Integrated Circuit Card Identifier (ICCID) value.

[0010] According to a third or any other aspect, transmitting a copy of the new subscription record to the orchestration agent includes transmitting a copy of the new subscription record to the orchestration agent via a network tunnel.

[0011] According to the fourth aspect or any other aspect, the orchestration center can be operatively configured to transmit a copy of the new subscription record in response to receiving an indication of device availability.

[0012] According to the fifth aspect or any other aspect, the orchestration center can be operatively connected to the Subscription Manager Data Preparation Enhanced Edition (SM-DP+) server.

[0013] According to the sixth aspect or any other aspect, the subscription edge record includes an eSIM profile received from the SM-DP+ server and stored in the eUICC, and the subscription edge record also includes subscription context information received from the network connectivity management platform and stored in memory.

[0014] According to the seventh aspect or any other aspect, the orchestration center can be operatively configured to update the eSIM profile via one or more APDU scripts.

[0015] According to the eighth aspect or any other aspect, this disclosure describes a method comprising: receiving first updated network subscription information from a device management platform in one or more management platforms; receiving second updated network subscription information from a network connectivity management platform in one or more management platforms; comparing the first updated network subscription information and the second updated network subscription information with a plurality of subscription records in a centralized network subscription information stored in an orchestration center; in response to determining a common identifier between a specific subscription record in the plurality of subscription records, the first updated network subscription information, and the second updated network subscription information, generating a new subscription record including current network subscription information based on the first updated network subscription information and the second updated network subscription information; and transmitting a copy of the new subscription record to an orchestration agent at a mobile computing device, wherein the orchestration agent is operatively configured to replace one or more information fields of the eUICC at the mobile computing device and the subscription edge record at storage with corresponding information fields from the copy of the new subscription record.

[0016] According to the ninth aspect or any other aspect, the public identifier is the Integrated Circuit Card Identifier (ICCID) value.

[0017] According to the tenth aspect or any other aspect, transmitting a copy of the new subscription record to the orchestration agent includes transmitting a copy of the new subscription record to the orchestration agent via a network tunnel.

[0018] According to the eleventh aspect or any other aspect, the orchestration center may be operatively configured to transmit a copy of a new subscription record in response to receiving an indication of device availability.

[0019] According to the twelfth aspect or any other aspect, the orchestration center is operatively connected to the Subscription Manager Data Preparation Enhanced Edition (SM-DP+) server.

[0020] According to aspect thirteen or any other aspect, the subscription edge record includes an eSIM profile received from the SM-DP+ server and stored in the eUICC, and the subscription edge record also includes subscription context information received from the network connectivity management platform and stored in memory.

[0021] According to the fourteenth aspect or any other aspect, the orchestration center can be operatively configured to update the eSIM profile via one or more APDU scripts.

[0022] According to the fifteenth aspect, this disclosure describes a non-transitory computer-readable medium comprising instructions that, when read by a processor, cause a processor to execute: receiving first updated network subscription information from a device management platform among one or more management platforms; receiving second updated network subscription information from a network connectivity management platform among one or more management platforms; comparing the first updated network subscription information and the second updated network subscription information with a plurality of subscription records in a centralized network subscription information stored in an orchestration center; in response to determining a common identifier between a specific subscription record among the plurality of subscription records, the first updated network subscription information, and the second updated network subscription information, generating a new subscription record including current network subscription information based on the first updated network subscription information and the second updated network subscription information; and transmitting a copy of the new subscription record to an orchestration agent at a mobile computing device, wherein the orchestration agent is operatively configured to replace one or more information fields of the eUICC at the mobile computing device and the subscription edge record at memory with corresponding information fields from the copy of the new subscription record.

[0023] According to the sixteenth aspect or any other aspect, the public identifier is the Integrated Circuit Card Identifier (ICCID) value.

[0024] According to the seventeenth aspect or any other aspect, transmitting a copy of the new subscription record to the orchestration agent includes transmitting a copy of the new subscription record to the orchestration agent via a network tunnel.

[0025] According to the eighteenth aspect or any other aspect, the non-transitory computer-readable medium discussed herein also includes instructions that, when read by a processor, cause the orchestration center to transmit a copy of the new subscription record in response to receiving an indication of device availability.

[0026] According to the nineteenth aspect or any other aspect, the orchestration center is operatively connected to the Subscription Manager Data Preparation Enhanced Edition (SM-DP+) server.

[0027] According to aspect 20 or any other aspect, the subscription edge record includes an eSIM profile received from an SM-DP+ server and stored within the eUICC, and the subscription edge record also includes subscription context information received from a network connectivity management platform and stored in memory, wherein the orchestration center is operatively configured to update the eSIM profile via one or more APDU scripts.

[0028] These and other aspects, features, and benefits of the claimed invention will become apparent from the detailed written description of the preferred embodiments and aspects taken in conjunction with the following drawings, although changes and modifications may be made to the embodiments without departing from the spirit and scope of the novel concept of this disclosure. Brief description of the attached diagram The accompanying drawings illustrate one or more embodiments and / or aspects of this disclosure, and, in conjunction with the written description, explain the principles of this disclosure. Where possible, the same reference numerals are used to refer to the same or similar elements throughout the drawings, and wherein: Figure 1 It is a diagram of an example system environment based on the disclosed technology; Figure 2 These are illustrations of example devices among a variety of devices based on the disclosed technology; Figure 3 This is a diagram illustrating an example interface environment for orchestrating proxies based on the disclosed technology; Figure 4 This is an illustration showing subscription edge recordings based on the disclosed technology; Figure 5 This is a diagram illustrating the subscription line copying process according to the disclosed technology; Figure 6 This is a flowchart illustrating the process of subscribing to source line updates based on examples of the disclosed technology; Figure 7 This is a flowchart illustrating an example edge row update process based on the disclosed technology; Figure 8 This is a flowchart illustrating an example edge row update process based on the disclosed technology; Figure 9 It is based on the state graph of the edge record subscribed to according to the publicly disclosed technical examples; Figure 10 This is an illustration showing an example subscription installation based on the disclosed technology; Figure 11 This is an illustration showing an example subscription installation based on the disclosed technology; Figure 12 This is an illustration showing an example subscription installation based on the disclosed technology; Figure 13This is a sequence diagram illustrating an example agent-center docking process based on the disclosed technology; Figure 14 It is a diagram of an example data structure based on the disclosed technology; Figure 15 This is a sequence diagram illustrating the first AHI forward operation call for an initially unavailable device according to the disclosed technology; Figure 16 This is a sequence diagram illustrating the second AHI forward operation call for an initially available device according to the disclosed technology; Figure 17 This is a sequence diagram illustrating the AHI reverse operation call according to the disclosed technology; Figure 18 This is a sequence diagram illustrating the first installation operation according to the disclosed technology; Figure 19 This is a sequence diagram illustrating the second installation operation using a configuration file to install the script according to the disclosed technology; Figure 20 This is a sequence diagram illustrating the first update operation without configuration file content management according to the disclosed technology; Figure 21 This is a sequence diagram illustrating a second update operation with configuration file content management according to the disclosed technology; Figure 22 It is a sequence diagram illustrating the deletion operation according to the disclosed technology; Figures 23A to 23C It is a sequence diagram of querying, reading, and updating device subscription information based on the disclosed technology; Figure 24 It is a lifecycle state machine based on the activities of the disclosed technology; Figure 25 It is a sequence diagram of the installation operations based on the disclosed technology; Figure 26 It is a sequence diagram of activities for updating operations based on the disclosed technology; and Figure 27 It is a sequence diagram of the deletion operation activities based on the disclosed technology.

[0030] Detailed description The disclosed technology generally relates to systems, methods, and apparatuses for improved cellular device connectivity distribution. Some examples of the disclosed technology will be described more fully with reference to the accompanying drawings. However, the disclosed technology can be embodied in many different forms and should not be construed as limited to the implementations set forth herein. Components described below as various elements constituting the disclosed technology are intended to be illustrative rather than limiting. In fact, it should be understood that other examples are contemplated. Many suitable components that will perform the same or similar functions as the components described herein are intended to be included within the scope of the disclosed electronic devices and methods. Such other components not described herein may include, for example, components developed after the development of the disclosed technology.

[0031] Throughout this disclosure, various aspects of the disclosed technology may be presented as ranges in a format (e.g., ranges of values). It should be understood that such descriptions are merely for convenience and brevity and should not be construed as a rigid limitation on the scope of the disclosed technology. Therefore, a description of a range should be considered to have all possible subranges of the specific disclosure and the individual rational values ​​within that range. For example, a range described as “from 1 to 6” or “from approximately 1 to approximately 6” includes the values ​​1, 6, and all values ​​in between. Similarly, a range described as “between 1 and 6” or “between approximately 1 and approximately 6” includes the values ​​1, 6, and all values ​​in between. The same premise applies to any other language used to describe ranges of values. That is, unless otherwise stated, the ranges disclosed herein include the corresponding endpoints.

[0032] In this document, the use of terms such as “having,” “comprising,” “including,” or “includes” is open-ended and intended to have the same meaning as terms such as “comprising” or “comprises,” without excluding the presence of other structures, materials, or actions. Similarly, while the use of terms such as “can” or “may” is intended to be open-ended and reflect that a structure, material, or action is not essential, the omission of such terms is not intended to reflect that a structure, material, or action is essential. Where a structure, material, or action is currently considered essential, it will be so identified.

[0033] In the following description, numerous specific details are set forth. However, it should be understood that embodiments of the disclosed techniques can be practiced without these specific details. In other instances, well-known methods, structures, and techniques have not been shown in detail so as not to obscure the understanding of this description. References to “an embodiment,” “an embodiment,” “an example embodiment,” “some embodiments,” “certain embodiments,” “various embodiments,” etc., indicate that embodiments (or multiple embodiments) of the disclosed techniques thus described may include a particular feature, structure, or characteristic, but not every embodiment must include that particular feature, structure, or characteristic. Furthermore, the repeated use of the phrase “in one embodiment” does not necessarily refer to the same embodiment, although it may refer to the same embodiment.

[0034] Throughout the specification and claims, unless the context clearly specifies otherwise, the following terms have at least the meaning explicitly associated herein. The term “or” is intended to mean an inclusive “or”. Furthermore, unless otherwise stated or clearly addressed to the singular form by the context, the terms “a”, “an”, and “the” are intended to mean one or more.

[0035] Unless otherwise stated, the use of ordinal adjectives such as “first,” “second,” “third,” etc., to describe common objects indicates only different instances of the similar objects referred to, and is not intended to imply that the objects described should be in a given order in time, space, hierarchy, or any other way.

[0036] Whether a term is capitalized or not should not be considered an authoritative or restrictive meaning of the term. As used in this document, capitalized terms should have the same meaning as non-capitalized terms, unless the context specifically indicates that a more restrictive meaning is expected. However, capitalization in the remainder of this document is not intended to be restrictive unless the context explicitly indicates that such restriction is expected.

[0037] To enhance understanding of the principles of this disclosure, reference will now be made to the illustrative examples provided in the accompanying drawings, which will be described using specialized language. However, it should be understood that the scope of this disclosure is not limited thereto; any modifications and further alterations to the described or illustrated embodiments, and any further application of the principles of this disclosure, are expected to occur to those skilled in the art to which this disclosure pertains. All limitations of the scope should be determined and defined according to the claims.

[0038] To enhance understanding of the principles of this disclosure, embodiments illustrated in the accompanying drawings will now be referenced, and specialized language will be used to describe these embodiments. However, it should be understood that the scope of this disclosure is not limited thereto; any modifications and further alterations to the described or illustrated embodiments, and any further application of the principles of this disclosure, are expected to occur to those skilled in the art to which this disclosure pertains. All limitations of the scope should be determined and described in the claims.

[0039] Overview Briefly described and according to one embodiment, aspects of this disclosure generally relate to systems, methods, and apparatus for improved cellular device connectivity distribution.

[0040] In particular, aspects of this disclosure relate to Remote SIM Configuration (RSP) in Internet of Things (IoT) environments. For example, consider scenarios where hundreds, thousands, or even hundreds of thousands of cellular IoT devices require information related to accessing one or more cellular networks for receiving and transmitting data. According to various aspects of this disclosure, the systems described herein include an orchestration center for synchronously sending cellular network subscription information to IoT devices from a centralized location, based on device availability. In at least one example, the orchestration center may be operatively connected to one or more device management systems (device managers). The orchestration center may also be operatively connected to one or more connectivity management systems (connectivity managers). According to various aspects of this disclosure, the orchestration center can install, configure, update, and delete subscriptions (including subscriber identity and subscription context) on remote IoT devices. Aspects of this disclosure also support profile content management and eSIM profiles with multiple IMSIs.

[0041] In at least one example, the orchestration center can be operatively configured to receive subscription source lines from one or more device managers, connectivity managers, and other management platforms. The orchestration center can determine whether the subscription source line includes updated subscription configuration information, and can merge the updated subscription configuration information into a stored record of subscription information within the orchestration center. Merging the updated subscription configuration information into the stored record of subscription information within the orchestration center can include generating new subscription information record entries (subscription information "lines"), replacing or overwriting existing subscription information stored within the orchestration center, and so on. In some examples, the orchestration center can generate and send Remote SIM Configuration (RSP) Application Protocol Data Unit (APDU) messages to IoT devices in response to them becoming available (e.g., waking from an idle state, completing a separate processing task, connecting to a network, etc.). The RSP APDU can include updated subscription configuration information, which can replace pre-existing subscription information at the IoT device.

[0042] Furthermore, this disclosure allows device operations (e.g., queries sent to devices to initiate specific actions) to be organized as campaigns. In one example, a campaign can be a set of sequentially ordered operations applied to one or more devices. While the operations can be sequential and ordered for each device in a campaign, the devices themselves can be processed in parallel. For example, a campaign may include two installation operations followed by a deletion operation, each performed on multiple devices. For example, for a campaign applying to 500 devices, the orchestration center can initiate 500 installation operations simultaneously. In at least one example, when an installation operation is completed, the orchestration center can begin subsequent operations device by device. Campaigns can provide a favorable management structure where RSP operations may incur costs, and the costs of RSP operations can be controlled and accounted for differently from other aspects of device management.

[0043] Example Implementation Now referring to the accompanying drawings, for the purpose of illustrating and explaining the basic processes and components of the disclosed systems, methods, and apparatus, see below. Figure 1 This illustrates an example system environment 100. As will be understood and recognized, Figure 1 The example system environment 100 shown is only representative of one method or embodiment of the system, and other aspects are used according to various embodiments of the system.

[0044] like Figure 1As shown, the example system environment 100 may include one or more connectivity managers 102, one or more orchestration centers 104, and one or more device managers 106. According to various aspects of this disclosure, the orchestration center 104 may be operatively connected to one or more of the plurality of devices 108. In one example, the device manager 106 may be operatively connected to one or more of the plurality of devices 108.

[0045] In at least one example, the connectivity manager 102 may be a software and hardware service platform. The connectivity manager 102 may be operatively configured to enable users to acquire and manage subscriptions, such as connectivity subscriptions to wireless networks. In one example, a subscription may allow devices to send and receive data (typically according to a defined protocol). The subscription, along with subscription information or subscription context, may include data such as subscriber identity (in the form of an International Mobile Subscriber Identity (IMSI) or multiple IMSIs) and key values ​​shared between the subscriber identity module (“SIM” or “eSIM profile”) and the network (Home Subscriber Server (HSS), AuC, 5GC, etc.). In some examples, the subscription may also include additional configuration information stored in one or more partner networks, information corresponding to protocols between networks, etc.

[0046] Connectivity Manager 102 can be operated by mobile network operators, mobile virtual network operators, connectivity resellers, private system operators, satellite system operators, and other enterprises. However, in one example, Connectivity Manager 102 can be operated and / or controlled internally (via an administrator of System 100). Connectivity Manager 102 may include a subscription database 110. In one example, subscription database 110 may include data ranging from HSS or 5GC (which may be implemented by a mobile network operator) to one or more subscription tables (which may be implemented for resale platforms).

[0047] Connectivity manager 102 may include a user interface (UI) 112 and an application programming interface (API) 114. In one example, UI 112 and API 114 may be operatively configured to allow users and software clients to acquire and manage subscriptions. In at least one example, connectivity manager 102 may also include a connectivity manager interface (CMI) 116. According to various aspects of this disclosure, CMI 116 may be operatively configured to provide one or more services to orchestration center 104. In various embodiments, CMI 116 may be implemented using a remote procedure call (RPC) framework such as gRPC. In this example, connectivity manager 102 may be a server, and orchestration center 104 may be a client. In some examples, the server streaming capabilities of gRPC may be utilized to implement additional client-to-server notification channels. In other examples, CMI 116 may be implemented using REST, GraphQL, WebSockets, event / streaming infrastructure such as Apache Kafka, or other similar means.

[0048] In one example, orchestration center 104 may be a software and hardware service platform operably configured to provide advanced services corresponding to Remote SIM Configuration (RSP) and eSIM orchestration. Orchestration center 104 includes an Orchestration Center Interface (OHI) 118, which can provide defined services to one or more device managers 106. In an illustrative embodiment, OHI 118 may be implemented using gRPC, where orchestration center 104 acts as a server and device managers (or multiple device managers) 106 act as clients, with an additional client-to-server notification channel utilizing gRPC's server streaming capabilities. In other embodiments, OHI 118 may be implemented using REST, GraphQL, WebSockets, an event / streaming infrastructure such as Apache Kafka, or other similar means.

[0049] Orchestration center 104 can be operatively configured to interface with CMI 116 and other connectivity manager 102 services. In one example, for connectivity manager 102 that does not support CMI 116, depending on the capabilities of connectivity manager 102, a proxy or adapter service can be built to translate the connectivity manager's native API 132 into an equivalent CMI 116 service or a subset thereof. Orchestration center 104 may include database 120 to store information such as subscription information related to connectivity manager 102, device information related to device manager 106, etc.

[0050] In one example, orchestration center 104 may be operatively connected to one or more Subscription Manager-Data Preparation Enhanced (SM-DP+) servers 122. Therefore, orchestration center 104 may be configured to perform ES9+ operations 124 as needed using SM-DP+ servers 122 to assist device 108 in downloading (eSIM profile download) and reporting notifications (eSIM profile update notifications). Those skilled in the art will understand that orchestration center 104 may also support ES11 connections to SM-DS servers to allow the example embodiment to utilize GSMA discovery services and other similar services.

[0051] In one example, device manager 106 may be a management platform. Specifically, the device manager may be a software platform operatively configured to provide the ability to configure, operate, and manage device 108. Example device manager 106 includes a system for managing payment terminals, asset trackers, cellular routers, LTE gateways, utility meters, fleet management equipment, sensors, PLCs, and other types of mobile and fixed-connection hardware nodes. Device manager 106 may include device management database 126. Device management database 126 may include tables of device-related rows, as well as other supporting tables and data structures. Device manager 106 may implement one or more device management protocols 128. Device management protocols 128 may allow device manager 106 to communicate with and manage device 108. Device management protocols 128 may be implemented using standards such as MQTT or LwM2M. In at least one example, device management protocols 128 may be built on top of lower-level IP standards such as TLS, TCP, UDP, CoAP, and DTLS. In some examples, device management protocol 128 may be built entirely on top of other physical layers, such as mesh, multi-address systems, point-to-multipoint systems, serial links, or other schemes. Device manager 106 may include UI 130 and API 132. UI 130 and API 132 enable users and software clients to manage device 108. Device manager 106 may also include client software for orchestration center interface (OHI) service 118, which accesses the services of orchestration center 104.

[0052] As will be described in more detail below, the Agent Center Interface (AHI) 134 can be configured to tunnel over other system interfaces and protocols. In one example, AHI 134 can enable bidirectional communication between the orchestration center 104 and the device 108.

[0053] For illustrative purposes and ease of understanding, connectivity manager 102, orchestration center 104, and device manager 106 are shown as integral elements in example system environment 100. It should be understood from the discussion herein that connectivity manager 102, orchestration center 104, and device manager 106 can be implemented as a distributed system or as subcomponents of a larger distributed system. In one example, connectivity manager 102, orchestration center 104, and device manager 106 can be configured to include overlapping aspects (such as combined connectivity manager 102 and orchestration center 104, combined orchestration center 104 and device manager 106, or other combinations). Although example system environment 100 shows a single orchestration center 104, the systems disclosed herein can support multiple orchestration centers 104 and multi-tenant orchestration centers 104, connectivity manager 102, and device manager 106 interconnected in various arrangements (e.g., many-to-many type arrangements).

[0054] Figure 2 This is an architecture diagram 200 of an example device 202 among multiple devices 108. In one example, device 202 may be a processing node. Device 202 may include hardware and software components. Device 202 may include computing resources such as a central processing unit (CPU) and / or a microcontroller, as well as memory, power supply, I / O, and other computing resources. In one example, device 202 may be various types of devices, such as routers, gateways, vehicle tracking units, utility meters, and other device types.

[0055] In one example, device 202 may include components such as device application 204, orchestration agent 206, modem 208, sensors and data input / output (I / O) 210, and other components. Device application 204 may be a software application. In at least one example, device application 204 may include software written in C and C++ languages. Device application 204 may include both an embedded operating system (OS) and application code. Device 202 may be implemented using different OSes, and it may host multiple device applications 204 developed in various computer languages ​​and frameworks.

[0056] Device application 204 can be operatively connected to sensors and I / O 210. Device application 204 can control sensors and I / O 210. In one example, sensors and I / O 210 may include various sensors, I / O ports and interfaces, such as temperature sensors, Ethernet ports, RS-485 ports, MDB interfaces, PID loops, analog ports, GPIOs, etc.

[0057] Device application 204 can be operatively connected to a non-volatile local database (or data storage device) 212. Database 212 can store information such as configuration, operating status, queued sensor measurements, and other data. Device application 204 can connect to modem 208 using interface 214 (such as TS 127 007, PPP, QMI, MBIM, Android RIL, or other interfaces).

[0058] Although example device 202 shows a single modem 208, it should be understood from the discussion herein that device 202 may include one or more modems 208. In one example, modem 208 may be a cellular modem. Modem 208 and / or sensors and I / O 210 may allow device application 204 to communicate with device manager 106. In one example, device application 204 communicates with device manager 106 via device management protocol 128.

[0059] In one example, orchestration agent 206 may be operably configured to interface with device application 204 using orchestration agent interface (OAI) 216. In an illustrative embodiment, orchestration agent 206 may be implemented as a C library of procedures (methods) directly linked to device application 204. In other embodiments, orchestration agent 206 may be implemented as a separate task, process, or hardware module, interfacing with device application 204 (or multiple applications 204) using shared memory, pipes, or other inter-process communication mechanisms. In one example, orchestration agent 206 may be implemented as a kernel module, interfacing with device application 204 using IOCTL, read, write, or other driver calls.

[0060] Orchestration agent 206 may provide several functionalities within the illustrative embodiments, including a role similar to that of a local agent described in the global platform SE RAM protocol, a role similar to that of a local profile assistant described in the SGP.22 specification, and a role as a local subscription server. Orchestration agent 206 may be operatively connected to local repository 218. Orchestration agent 206 may use local repository 218 to store and retrieve configuration and state data. Orchestration agent local repository 218 may reside within the same physical device as device application database 212. For example, orchestration agent local repository 218 and device application database 212 may be arbitrated via a file system or other means. In one example, orchestration agent local repository 218 and device application database 212 may be separate physical hardware.

[0061] Orchestration agent 206 may include modem interface 220. Modem interface 220 may be (logically and / or physically) connected to modem 208. Modem interface 220 may be the same physical interface as device application interface 214, which is arbitrated between device application 204 and orchestration agent 206, or it may be a separate physical interface. Orchestration agent 206 may also include interface 222 to eUICC 224.

[0062] In one example, eUICC 224 can be software running on secure hardware, such as an ISO / IEC 7816 compliant smart card, a trusted execution environment, a secure enclave, a secure microcontroller, or other similar environment. eUICC interface 222 can be an ISO / IEC 7816 compliant hardware interface, accessible directly via GPIO pins, indirectly via modem 208 through the +CSIM command described in ETSI TS 127 007, or by other means. eUICC 224 can also be operatively configured to interface with modem 208 using physical interface 226.

[0063] In addition to providing OAI 216 to device application 204, orchestration agent 206 can also receive local services from device 202.

[0064] Now go to Figure 3 The illustration shows an example interface environment 300 illustrating orchestration agent 206. Specifically, interface environment 300 illustrates orchestration agent 206 operatively connected to device application 204 via OAI 216, along with multiple supporting services and interfaces. In at least one example, the multiple supporting services and interfaces may be referred to as Support and Abstraction Layer (SAL) 302.

[0065] In one example, SAL 302 may be a library that directly links to C programming language procedures (methods) in orchestration agent 206. In other embodiments, SAL 302 may be implemented as a separate task, process, or hardware module that interfaces with device application (or multiple device applications) 204 via shared memory, pipes, or other inter-process communication mechanisms. In one example, SAL 302 may be implemented as a kernel module that interfaces with device application 204 using IOCTL, read or write, or other driver calls.

[0066] SAL 302 may include multiple support services. For example, SAL 302 may include modem service 304, eUICC service 306, time base service 308, local repository service 310, and lock service 312.

[0067] In at least one example, modem service 304 can provide access to modem 208 and modem interface 220. Modem access can be serialized and arbitrated among orchestration agent 206, device application 204, and other software and hardware components. eUICC service 306 can provide access to eUICC 224 and eUICC interface 222. In one example, eUICC 224 access can be serialized and arbitrated among orchestration agent 206, device application 204, modem 208, and other software and hardware components. In embodiments where orchestration agent 206 accesses eUICC 224 via modem 208 (e.g., using the +CSIM command described in ETSI TS127 007), modem service 304 and eUICC service 306 can share a common mutex and data structure.

[0068] In a specific example, time base service 308 can provide access to UTC, GPS, or other time sources to allow orchestration agent 206 to set software timers. Local repository service 310, responding to the basic model of open, close, read, write, and other routines seen in the C standard library, provides arbitrated access to the orchestration agent's local repository 218.

[0069] In one example, lock service 312 enables orchestration agent 206 to acquire several device-scoped resource locks. Table 1 below lists the various resource locks. Table 1. Example resource lock Referring to Table 1, a WAKE lock can prevent a device (e.g., device 202) from powering off, suspending, or shutting down. A WAKE lock can functionally resemble the "WakeLock" power manager object provided by the Android operating system environment. A HUB lock can provide similar protection to a WAKE lock; however, a HUB lock can additionally protect ongoing communication with the orchestration center 104, for example, by ensuring the modem remains powered and connected, disabling PSM and eDRX, enabling Ethernet or BLE, or by taking other appropriate steps. For example, orchestration agent 206 can acquire a HUB lock when it expects a response from an AHI 134 method call. An EUICC lock can provide the same protection as a WAKE lock, but it additionally protects ongoing communication with the eUICC, for example, by keeping the eUICC powered on. For example, when orchestration agent 206 is using the ES10 interface or running APDU scripts using eUICC, or when orchestration agent 206 needs to retain open logical channels inside eUICC, orchestration agent 206 can acquire an EUICC lock.

[0070] In at least one example, an EUICC lock may include implicit restrictions imposed on the modem hosting the EUICC. For example, an EUICC lock may require PSM to be disabled to prevent the modem from suspending or powering down the EUICC as part of a power-saving strategy. In cases where a single eUICC serves multiple modems, such as when multiple enabled profiles ("MEP", SGP.22 v3.1 2.12) are implemented, an EUICC lock may also protect the physical resources interfaced to eUICC port 0.

[0071] Locks can be acquired through a single library method that has parameters describing which lock(s) were requested. An asynchronous callback hook can be used to communicate the success or failure of an operation, along with the lock ID, which can be used later to release the lock. Acquired locks are explicitly released through subsequent lock acquisitions, or implicitly released in response to device power loss or a reset.

[0072] Now go to Figure 4 The illustration shows a subscription edge record 400 according to one aspect of this disclosure. In one example, a subscription may be a collection of related data structures distributed across a network or across multiple devices (such as multiple devices 108), all of which are interconnected by a common IMSI value.

[0073] In at least one example, subscription information and / or subscription-related information may be stored on a separate device (such as device 202). The subscription-related information at device 202 may be referred to as a subscription edge row. In this embodiment, a specific subscription edge row 402 is shown for illustrative purposes. Subscription-related information stored in orchestration center 104 may be referred to as a subscription center row. In this embodiment, a specific subscription center row 404 is shown for illustrative purposes. In some examples, subscription rows from connectivity manager 102 and device manager 106 may be referred to as subscription source rows. During normal operation, the subscription center row can be updated asynchronously using information from the subscription source row. The updated subscription center row can be asynchronously copied to the subscription edge row.

[0074] In one example, network 406 may include one or more subscription lines, which may include subscription information such as phone numbers, locations, service entitlements, encryption keys, and other data. In this embodiment, a specific subscription line 408 is shown for illustrative purposes. Subscription line 408 may be stored in the network's authorization center 410 (e.g., 5GC, Home Subscriber Server (HSS), etc.). Subscription information may also be stored in subscription edge lines 402 in device 202 and subscription center lines 404 stored in orchestration center 104. Subscription edge line 402 includes subscriber identity 412 (e.g., an eSIM profile installed in eUICC 224) and subscription context 414 (stored in a local repository 218). Subscriber identity 412 and subscription context 414 are linked by two shared values: the AID of the eSIM profile's ISD-P (which is unique to eUICC) and the profile's ICCID (which is universally unique). Subscription edge line 402 is associated with subscription information in the Home Location Register (HLR) of network 406 via a common IMSI value. This common IMSI value is stored in subscriber identity 412 and network authorization center 410, and may also be distributed to other parts of the cellular network 406. Subscription edge line 402 is associated with subscription center line 404 in subscription center table 416 via a common sub_uid integer value, as well as line revision (sub_rev) and synchronization state value (sync_state). Example synchronization state values ​​are listed in Table 2 below. Table 2. Example synchronization status Referring to Table 2, the synchronization state (sync_state) values ​​are shown, which describe the state of the replication process between subscription center line 404 and its corresponding subscription edge line 402. The CONFIRMED state can mean that subscription center line 404 has been written to its corresponding subscription edge line 402 and acknowledged by device 202. The WORKING state can mean that subscription center line 404 is in the process of being written to its corresponding subscription edge line 402, but has not yet been acknowledged. The LEADING state can mean that there are changes in subscription center line 404 that have not yet been sent to device 202.

[0075] Figure 5 This is an illustration of a two-stage asynchronous subscription line replication process 500. As discussed throughout this disclosure, orchestration center 104 is operatively configured to merge (combine) subscription information from one or more connectivity managers 102 and one or more device managers 106 for updating corresponding subscription information at edge devices, such as device 202. As shown in subscription line replication process 500, connectivity manager 102 asynchronously forwards one or more subscription source lines 502 from multiple subscription source lines 504 to orchestration center 104 as needed. In one example, device manager 106 may asynchronously forward one or more subscription source lines 506 from multiple subscription source lines 508 to orchestration center 104 as needed. When a subscription source line update is received, orchestration center 104 may merge subscription source lines 502 and 506 into subscription center line 510 in subscription center table 416. When this process modifies subscription center line 510, orchestration center 104 sends updated subscription information 512 to the corresponding subscription edge line 514. In one example, the corresponding subscription edge line 514 can be stored in device 202, or in any of the multiple devices 108.

[0076] Figure 6 This is a flowchart of an example subscription source row update process 600. Process 600 illustrates the procedure performed by an orchestration center (e.g., orchestration center 104) when it receives one or more updated subscription source rows (e.g., updated subscription source rows 502 and 506). Process 600 may begin at step 602, where the system receives one or more updated source rows. At step 604, the orchestration center queries the subscription center table for rows that match the received updated source rows. In one example, step 604 may include querying the subscription center table for source row subscription information that matches the received updated source rows.

[0077] At step 606, the system determines whether the query result is empty. If the query result is not empty, process 600 proceeds to step 608. At step 608, the system determines whether the query result contains a LEADING row. If the query result contains a LEADING row, process 600 proceeds to step 610, where the orchestration center updates the LEADING row with information / fields from the source row.

[0078] If the system determines at step 608 that the query results do not include the LEADING row, then process 600 can proceed to step 612. At step 612, the orchestration center creates a new LEADING row by combining (a) the row with the highest sub_rev value in the query results, (b) that highest sub_rev value incremented by 1, and (c) the fields from the source row.

[0079] Returning to step 606, if the system determines the query result is empty, process 600 proceeds to step 614 to determine if the updated source row comes from the connectivity manager. Typically, at step 614, if the system determines the query result is empty, it can be determined that the source row represents a new subscription to the orchestration center, which should only arrive from the connectivity manager. At step 614, if it is determined that the update is not from the connectivity manager, process 600 can proceed to step 616, where the exception is handled and process 600 ends. However, at step 614, if it is determined that the updated source row is from the connectivity manager, process 600 can proceed to step 618, where the orchestration center creates a new subscription center row with sync_state=LEADING, sub_rev=0, and a unique sub_uid. In various examples, the orchestration center may accept a new subscription row from the device manager as a placeholder subscription row for later completion, population, or updating by the corresponding source row from the connectivity manager.

[0080] In response to steps 618, 612, and / or step 610, process 600 may proceed to step 620. At step 620, the orchestration center may determine whether the query results contain a WORKING row. If a WORKING row exists, process 600 may proceed to step 616 to handle the exception and terminate the process. If no WORKING row exists, process 600 may proceed to step 622, where the orchestration center notifies the device manager that the APDU may be ready for the affected device. At this point, the source row has been merged into the subscription center table.

[0081] Figure 7This is a flowchart of an example edge row update process 700. In one example, and in response to a notification from the device manager regarding the updated source row, the device manager can call the OHI GetApdu() method to generate and return an APDU for the affected device. The orchestration center handles the GetApdu() method call in part by efficiently iterating through the subscription center rows associated with the device and initiating process 700, where each subscription ID is passed as an argument. In one example, process 700 may begin at step 702, where the orchestration center receives the subscription ID passed as an argument.

[0082] At step 704, the orchestration center queries the subscription center table for the row that matches the subscription ID parameter received at step 702.

[0083] At step 706, the orchestration center determines whether the query results include WORKING rows. If the query results include WORKING rows at step 706, process 700 proceeds to step 708, where the process returns a NULL APDU value and process 700 terminates. If it is determined at step 706 that the query does not include WORKING rows, process 700 proceeds to step 710, where the orchestration center determines whether the query results include LEADING rows. If the query results do not include LEADING rows, the process returns a NULL APDU value at step 708. If it is determined at step 710 that the query includes LEADING rows, process 700 proceeds to step 712.

[0084] At step 712, the orchestration center determines whether the query results include CONFIRMED rows. If the query results include CONFIRMED rows, the orchestration center generates an update() AHI request APDU from the increment between the LEADING and CONFIRMED result rows at step 714. Otherwise, process 700 proceeds to step 716, where the orchestration center generates an install() AHI request APDU from the LEADING rows.

[0085] In response to steps 714 and 716, process 700 proceeds to step 718, where the orchestration center changes the sync_state of the LEADING line to WORKING. Furthermore, at step 720, the orchestration center returns the constructed APDU to the caller, which exits the iteration loop and passes the APDU as part of the return value of GetApdu() to the device manager. The device manager can then forward the APDU to the device as a call to the AHI update() or AHI install() method.

[0086] Figure 8 This is a flowchart of the example edge row update process 800. In at least one example, when the AHI install() or update() method completes (as combined above)... Figure 7 (As discussed in process 700), the Device Manager uses the response APDU to call the OHI PutApdu() method. The Orchestration Center partially handles the PutApdu() method call via startup process 800, where the subscription ID is used as a parameter.

[0087] In one example, process 800 can begin at step 802, where the orchestration center queries the subscription center table for rows that match the subscription parameters. At step 804, the orchestration center determines whether the query results include CONFIRMED rows. If the orchestration center determines at step 804 that the query results include CONFIRMED rows, process 800 proceeds to step 806, where the orchestration center deletes the CONFIRMED rows. If the orchestration center determines at step 804 that the query results do not include CONFIRMED rows, the process proceeds to step 808.

[0088] At step 808, and in response to steps 804 or 806, the orchestration center changes the `sync_state` field of the `WORKING` row to `CONFIRMED`. At step 810, if it is determined that the query results do not include the `LEADING` row, process 800 can end. At step 810, if the query results include the `LEADING` row, process 800 proceeds to step 812, where the orchestration center notifies the device manager that the APDU may be ready for the affected devices. At this point, the response to the `AHIinstall()` or `update()` method call has been processed, and the process ends.

[0089] Throughout this disclosure, subscription rows (such as subscription center rows) are described based on their constituent fields. Table 3 shown below includes several subscription center row fields and their corresponding sources according to various aspects of this disclosure. Table 3. Example subscription center row fields and source Referring to Table 3 above, the subscription center row is described based on its constituent fields. In Table 3, " Fields "Columns include field names," describe "Columns include field descriptions, and" source "The column indicates which element can provide data. Possible..." source The column values ​​include OH (Orchestration Center), OA (Orchestration Agent), CM (Connectivity Manager), DM (Device Manager), and DP (SM-DP+). The sub_uid field contains the integer ID of the subscription, which is unique within the Orchestration Center, and the sub_rev field contains the current revision of the subscription center row. The state field describes the subscription state as detailed in Table 4. The edge_state field describes the subscription edge row state. The sync_state field describes the synchronization state between the subscription center row and its corresponding subscription edge row 402, as summarized in Table 2 and explained above. The cm_base_rank field contains the base rank value for subscriptions from the Connectivity Manager, and the dm_base_rank field contains the base rank value for subscriptions from the Device Manager. Lower rank values ​​are assigned to preferred subscriptions, while higher rank values ​​are assigned to less preferred subscriptions. The cm field identifies the Connectivity Manager providing the subscription, and the cm_sub_id identifies the subscription within the Connectivity Manager. The iccid field identifies the eSIM profile associated with the subscription. The dp_address contains the information to be used for eSIM profile download (SGP.22 v2.4). 4.1) The URL of the SM-DP+ server. The ac_token and cc fields describe the activation token (SGP.22 v2.4 4.1) and confirmation code (SGP.22 v2.4 4.7) during the SM-DP+ profile download, respectively. ins_script identifies the script to be used to install the subscriber identity. If this value is included, it means an in-factory profile provisioning (IFPP) type installation process, and the dp_address, ac_token, and cc fields should be ignored. upd_script describes the latest update script required for profile content management. The ppr2_consent and ppr2_consent fields indicate whether consent to PPR1 and PPR2 is granted (SGP.22 v2.4 2.4.1). The pdp field specifies the PDP context value used with the subscription, which is presented as a list of structures, each structure including a context ID, APN value, IP type, and ETSITS 127. Additional information required by the +CGDCONT command described in 007, including the maximum MTU size and other parameters. The band_list field describes a list of frequency bands that may be needed for the subscription, which is included as a list of band numbers from LTE bands, NR bands 1, 2, NT1, NT2, and other possible bands. The cm_plmn_rank and dm_plmn_rank fields each contain a list of entries, each entry including MCC, MNC, and optional imsi_ordinal and rank values.Together, MCC and MNC describe the mobile network, as can be seen via the +COPS=? command described in ETSI TS 127 007. If an imsi_ordinal value exists, it describes the IMSI that can be used with the network. If imsi_ordinal does not exist, any IMSI from the subscription can be used, or the eSIM profile can automatically select an IMSI. If a rank value exists, it overrides the base_rank value as the ranking value for the subscription / IMSI / MCC / MNU combination. Generally, it is recommended to use the MCC / MNU combination present in the cm_plmn_rank field with the subscription, and values ​​present in dm_plmn_rank override matching rank values ​​present in cm_plmn_rank. The geo field includes a list of geographic regions, such as MCC values ​​or circles or trapezoids mapped to the Earth's surface, as well as imsi_ordinal and an internal Boolean value determining whether the region is inclusive or exclusive. When the device's location meets geographic requirements, imsi_ordinal (if present) describes the IMSI that can be used with the subscription. If imsi_ordinal does not exist, any IMSI can be used with the subscription, or the eSIM profile can automatically select an IMSI.

[0090] The `cm_attribues` field describes a list of integer attributes that can be used to conceptually connect a subscription to an external data structure provided by the connectivity manager. These values ​​can be globally coordinated values ​​or scoped values ​​specific to the connectivity manager. The `dm_attributes` field contains a list of integer attributes that can be used to conceptually connect a subscription to an external data structure provided by the device manager. Like the `cm_attributes` field, `dm_attributes` values ​​can be globally coordinated values ​​or scoped values ​​specific to the device manager. Examples of uses for `cm_attributes` may include identifying the device-side APDU API model used for eSIM profiles, identifying alternative cost models involving system access fees or prepaid plans, or identifying other characteristics. Examples of uses for `dm_attribues` may include identifying device-specific ranking algorithms, tags used to ensure that device or modem firmware revisions reach a certain level before using the subscription, tags used to ensure certain randomization intervals of inbound data, or other information. The cm_extdata field can contain raw data provided by the connectivity manager and specific to the connectivity manager, and the dm_extdata field can contain raw data provided by the device manager and specific to the device manager, the former using a globally coordinated format or a format specific to the connectivity manager or device manager, respectively.

[0091] As shown in Table 4 below, the possible status field values ​​are: STOCK status indicates that the subscription is configured in the network but is not yet available. READY status indicates that the subscription is available but no usage fees have been incurred. ACTIVE status means that the subscription is available and usage fees are incurred. SUSPEND means that the subscription is temporarily unavailable, and TERMINATED means that the subscription has been deconfigured. Table 4. Example status field value As shown below, Table 5 illustrates the possible subscription context and subscription edge row field values. Table 5. Example subscription context and subscription edge row field values As shown in Table 5, Fields "Columns include field names," describe "Columns contain field descriptions, and" source "The column indicates which element can provide data. Possible..." source The column values ​​include OH (Orchestration Center), OA (Orchestration Agent), CM (Connectivity Manager), DM (Device Manager), DP (SM-DP+122), and EU (eUICC 224). As described in Table 3 for the Subscription Center row, the sub_uid and sub_rev fields include the subscription's integer ID and revision. The base rank field includes the value of dm_base_rank from Table 3, or, if dm_base_rank does not exist, the value of cm_base_rank from Table 3. The iccid and aid fields both match the subscription context with the subscription identity in the eUICC identified by the eid field. ins_blob and upd_blob use the same as AHI. The `get_blob()` method-compatible blob identifier is used to reference the `ins_script` and `upd_script` fields in Table 2. Binary large objects, or "BLOBs," will be discussed in more detail below. The `plmn_rank` field comprises an aggregation of `cm_plmn_rank` and `dm_plmn_rank`, ensuring that all `cm_plmn_rank` entries exist, with the rank value overridden by the corresponding MCC / MNC / imsi_ordinal entry in the `dm_plmn_rank` field. The other fields in Table 5 match the fields with the same names in Table 3.

[0092] Figure 9 This is example subscription edge record state diagram 900. In one example, a subscription can have two possible initial states: Installing (902) when the subscription edge record is initially created via an AHI install() method call (described in more detail below), and Unmanaged (904) when the subscription is installed locally using the device LPA or preloaded by EUM. When the subscription is in the Installing (902) state, the orchestration agent securely installs the subscriber identity. If the installation process completes successfully, the edge state transitions to Installed (906). If the installation process fails, the edge state transitions to Failed (908). The orchestration agent can retry the failed download, returning the state to Installing (902). The SEVERED state (910) means that the subscription context is populated, but the corresponding subscriber identity is missing. After removing the eUICC from the device, the state can transition from Installed (906) to SEVERED (910). For example, a technician removing an eUICC from device A and inserting it into device B can result in a cut-off 910 subscription edge record in device A and an unmanaged 904 subscription edge record in device B. If the AHI delete() method is called, the state can move from installed 906 or cut-off 910 to unlinked 912. When the state is unlinked 912, the orchestration agent can delete the subscription edge line from eUICC 224 and repository 218 if other local conditions permit.

[0093] When a subscription edge record begins or transitions to an unmanaged state 904, the orchestration center and orchestration agent may be able to transition it to an installed state 906. For example, if the device and subscription exist in the same orchestration center account, and if an AHI path exists between the orchestration center and the device agent, the orchestration center can determine the location of the subscription and invoke the AHI update() method to restore its subscription context information at the device. Those skilled in the art will recognize that this mechanism can leverage UICCs and eUICCs to manage subscription contexts. A UICC inserted into a device will appear as an unmanaged 904 subscription, which the center can locate and download the appropriate subscription context.

[0094] Subscription templates have been discussed throughout this disclosure. In one example, a subscription template (“template”) describes the category or type of subscription, such as a specific MNO or MVNO, data plan, coverage area, and other attributes. Subscription templates can be provided by the Connectivity Manager and can be enhanced by the Device Manager. Subscription templates can be used as parameters when acquiring new subscriptions via OHI and CMI. Example subscription template fields are shown in Table 6 below. Table 6. Example subscription template fields In one example, a subscription template can be described based on its constituent fields. As shown in Table 6, Fields "Columns include field names," describe "Columns include field descriptions, and" source "The column indicates which element can provide data. Possible..." Come source "Column values ​​include OH (Orchestration Center), CM (Connectivity Manager), and DM (Device Manager). The cm field includes the identifier of the connectivity manager that provided the template. The cm_id field includes the connectivity manager's ID for the template, the cm_name field includes the unique name assigned to the template by the connectivity manager, and the cm_desc field includes a description of the template from the connectivity manager. When the subscription center row is created (e.g., after the CMI AcquireSubscription and ReadSubscription method calls, as explained in more detail below), the remaining fields are copied from the template to the subscription center row, where the fields from the template are copied to fields with the same names in Table 3."

[0095] Furthermore, aspects of this disclosure include the use of secure elements, trusted execution environments, secure enclaves, and other security structures. Specifically, a subscriber's identity can be matched with a specific eUICC within a secure element. Additionally, in some cases, the underlying subscription may be eligible for use by a specific modem (rather than other modems). This interdependence between the subscription, modem, and eUICC can begin during the Common Mutual Authentication Procedure (SGP.22 v2.4 3.1.2, SGP.22 v3.1 3.0.1, and SGP.32 v3.2 3.2.2), and can begin even earlier, such as when the API call used to retrieve the activation code requires IMEI and EID parameters, or before the EUM preloads the eSIM profile into the eUICC.

[0096] The device may include multiple modems to enable the use of different, incompatible radio technologies, different radio bands, or for other reasons. For component-level redundancy or other reasons, the device may include multiple eUICCs. In the example where a subscription edge record is to be installed into a device with multiple modems or multiple eUICCs, the installation instructions must describe the destination device, modems, and eUICCs.

[0097] In an example where a subscription is installed into a device group with multiple modems and / or multiple eUICCs, illustrative embodiments may utilize a group-wide identifier to identify multiple destination eUICCs. This group-wide identifier includes a list of device identifiers, a single "modem_ordinal" parameter for identifying the modems on each device, and a single "modem_slot" parameter for identifying the eUICCs on each device. In at least one example, this group abstraction allows for the separation of concerns between the orchestration center and the device manager, enabling the device manager to describe activity at the device level without identifying individual eUICC EIDs.

[0098] Figure 10This is illustration 1000, showing an example subscription installation. As shown in illustration 1000, an example device 1002 with device_id "2607066" and type A, captured during the installation of subscription 8910390000062531280F 1004, is depicted. Device 1002 includes a single modem 1006 with a single SIM slot connected to an eUICC 1008. The destination of subscription 8910390000062531280F 1004 is described as having a "Modem_Serial Number" value of 0 and a "Modem_Slot" value of 0. It can be noted that subscription 89883070000012965073 1010 may also have been previously installed with a "Modem_Serial Number" value of 0 and a "Modem_Slot" value of 0.

[0099] Figure 11 This is illustration 1100, showing an example subscription installation. As shown in illustration 1100, an example device 1102 with device_id "2607067" and type B, captured during the installation of subscription 89883070000012965073 1104, is depicted. Device 1102 includes two modems, namely modem 0 1106 and modem 1 1108. Modem 0 1106 has two SIM slots, namely slot 0 connected to eUICC 0 1110 and slot 1 connected to eUICC 1 1112. Modem 1 1108 also has two SIM slots, namely slot 0 connected to eUICC 3 1114 and slot 1 connected to eUICC 4 1116. The destination of subscription 1104 is described as having a "modem_serial number" value of 0 and a "modem_slot" value of 0. It can be noted that subscription 8910390000062531280F 1118 may have been previously installed with a "Modem_Serial Number" value of 0 and a "Modem_Slot" value of 0, while subscription 8910390000062531314F 1120 may have been previously installed with a "Modem_Serial Number" value of 1 and a "Modem_Slot" value of 1.

[0100] Figure 12Figure 1200 illustrates an example subscription installation. As shown in Figure 1200, an example device 1202 with device_id "2607068" and type C, captured during the installation of subscription 8910390000062531306F 1204, is depicted. Device 1202 includes two modems, namely modem 0 1206 and modem 1 1208. Modem 0 1206 has two SIM slots, namely slot 0 connected to eUICC 0 1210 and slot 1 connected to eUICC 1 1212. Modem 1 1208 also has two SIM slots, namely slot 0 also connected to eUICC 0 1210 and slot 1 connected to eUICC 2 1214. Because eUICC 0 has MEP capability, the destination of subscription 1204 can be described using a "Modem_Serial Number" value of 0 and a "Modem_Slot" value of 0, or a "Modem_Serial Number" value of 1 and a "Modem_Slot" value of 0. It can be noted that subscription 898830700000129651231216 may have been previously installed using a "Modem_Serial Number" value of 0 or 1 and a "Modem_Slot" value of 0, while subscription 89883070000012965073 1218 may have been previously installed using a "Modem_Serial Number" value of 0 and a "Modem_Slot" value of 0.

[0101] In at least one example, the system disclosed herein may include scripts during the installation or update of subscription edge lines. The script may be a set of command APDUs (C-APDUs) configured to be sent directly to the eUICC by an orchestration agent, resulting in a set of corresponding response APDUs (R-APDUs) from the eUICC and changes within the eUICC. In one example, the script may be used to install a configuration file (“in-plant configuration file provisioning”) or modify a previously installed configuration file (“configuration file content management”). For example, an update operation may include changes in the PLMN list and corresponding changes to the eSIM configuration file, such as adding, replacing, or removing an IMSI. When the script is run, the orchestration agent may assume a role similar to that described in the global platform SERAM protocol.

[0102] Furthermore, aspects of the invention may include binary large objects, or "BLOBs." In one example, a BLOB is used to move data between an orchestration agent and an orchestration center when the data is too large to be fully contained within an AHI APDU. In some examples, a BLOB may be used to contain bound configuration file packages, scripts, fields required for public mutual authentication processes, or other information.

[0103] Figure 13 This is a sequence diagram illustrating the example agent-center docking process 1300. As shown in the example agent-center docking process 1300, forward and reverse method calls are illustrated between the orchestration center 104 and the orchestration agent 206. A forward method call is initiated by a forward request APDU 1302 sent from the orchestration center to the orchestration agent, and it is completed by a forward response APDU 1304 sent from the orchestration agent to the orchestration center. A reverse method call is initiated by a reverse request APDU 1306 sent from the orchestration agent to the orchestration center, and it is completed by a reverse response APDU 1308 sent from the orchestration center to the orchestration agent.

[0104] In one example, AHI is based on bidirectional remote procedure calls (RPC) between the orchestration center and the orchestration agent. The orchestration center and the orchestration agent can each call methods exposed by the other, with forward method calls initiated by the orchestration center and reverse method calls initiated by the orchestration agent. Method calls can be implemented using Application Protocol Data Units (APDUs), where request APDUs transmit call parameters and response APDUs transmit call return values. In at least one example, AHI can be operationally configured to implement multiple method calls, such as install(), update(), delete(), query(), and notify() (a reverse method call in response to updates to subscribed edge rows / records).

[0105] Figure 14 This is the example encoded AHI APDU 1400. As shown in the example encoded AHI APDU 1400, bytes 0 and 1 together form a 16-bit Interface Identifier value (IID 1402). Byte 2 specifies the interface version (IV 1404), and byte 3 specifies the payload type (PT 1406). Bytes 4 and 5 form a 16-bit Method Invocation Identifier (MCID 1408). Forward method calls use MCID values ​​in the range of 0 to 32767 (inclusive), while reverse method calls use MCID values ​​in the range of 32768 to 65535 (inclusive). The MCID advances by 1 for each subsequent method call, wrapping around its range, such that 65535 advances to 32768 and 32767 advances to 0. Bytes 6 and 7 include parity information (PAR 1410), and bytes 8 to the end of the APDU contain the encoded payload (payload 1412). The IID and MCID fields are encoded using the least significant byte in the least significant byte position (also known as "little-endian" byte layout).

[0106] A PT value of 0 specifies that the "Payload" field includes the encoded request or response APDU payload. A PT value of 1 specifies an error response, where the payload field contains a 32-bit integer error value encoded as four bytes, with the least significant byte first. A PT value of 255 specifies a window reset request, canceling any pending calls and resetting the MCID to the lowest possible number, which is 0 for forward transactions and 32768 for reverse transactions. In the illustrative embodiment, the IID is set to the value 48090, the IV is set to the value 1, and the payload encoding for PT=1 is based on the proto3 specification file. The PAR field is set such that the CCITT CRC-16 value calculated from the first payload byte to the end of the encoded APDU, followed by the first 8 bytes of the encoded APDU, is zero.

[0107] Those skilled in the art will recognize that typical remote procedure calls may fail during normal operation due to transmission problems, timeouts, synchronization issues, and other reasons. Therefore, the AHI 134 discussed herein includes... Figure 14 The data structure shown is used to ensure packet integrity, implement Automatic Repeat Request (ARQ), and remove duplicate APDUs. In one example, Figure 14 The data structure shown is sufficient to allow AHI to be implemented as a simple length-prefixed envelope using basic transmission methods such as UART serial links. AHI 134 can also be implemented using higher-level protocols such as UDP or TCP. However, in the illustrative embodiment, AHI 134 is implemented using explicit tunneling via OHI 118, Device Manager 106, Device Management Protocol 128, Device Application 204, and OAI 216. This arrangement provides a high level of flexibility, where different Device Management Protocols 128 are used at different points in the device lifecycle. For example, the Device Management Protocol may include wiring harnesses during manufacturing, Bluetooth during provisioning, NBIoT after deployment, and mobile ISM band base stations during recovery from regional disasters.

[0108] Now for reference Figure 15This illustrates an example of a first AHI forward operation call 1500 for an initially unavailable device (e.g., device 202 from multiple devices 108) according to the disclosed technology. The unavailable device may include any particular device in sleep mode and / or in a non-powered state. Device manager 106 may interface with orchestration center 104 via OHI 118. Device manager 106 may communicate with device application 204 using device management protocol 128. Device application 204 may interface with orchestration agent 206 using OAI 216. In one example, OAI 216 may be operablely configured to execute various methods for interfacing with device application 204 and orchestration agent 206, such as oai_start() (which includes a configuration structure and callback hooks), oai_stop(), oai_reconfig(), oai_get_adpu(), oai_put_adpu(), oai_get_sub(), oai_get_sub_list(), oai_query(), and oai_enable_sub().

[0109] Figure 15The AHI forward method call shown can be initiated when the device is in a power-off state, power-saving mode, and / or any specific unreachable state. The orchestration center 104 using OHI 118 can send a notification 1501 to the device manager 106. Notification 1501 can include notification of pending request AHI APDU 1302 for a specific device's orchestration agent 206. Because the device may be unavailable, the device manager 106 can withhold a specific AHI transaction. At some later time (e.g., minutes or weeks later), the device application 204 can wake from static sleep mode 1502 and send a notification 1503 to the device manager 106 via the device management protocol 128. Using OHI 118, the device manager 106 can invoke a request APDU operation 1504 and retrieve the request AHI APDU 1302 for the device. Request APDU operation 1504 can include an operation to retrieve the next pending request AHI APDU 1302 for a specific device. Request APDU operation 1504 may include parameters such as a device ID that identifies the device that should receive request AHI APDU 1302. Request APDU operation 1504 may return an encoded request AHI APDU 1302, wherein device management protocol 128 can deliver request AHI APDU 1302 to the specified device. Device manager 106 can use device management protocol 128 to transmit request AHI APDU 1302 to device application 204. Upon receiving request AHI APDU 1302, device application 204 can forward request AHI APDU 1302 to orchestration agent 206 via OAI put APDU operation 1506, which is available via OAI 216. OAI put APDU operation 1506 may include an operation that can pass request AHI APDU 1302 received from orchestration center 104 to orchestration agent 206. Orchestration agent 206 can acquire a HUB lock or EUICC lock 312 suitable for a method call represented by request AHI APDU 1302. Orchestration agent 206 can begin processing request AHI APDU 1302. Upon completion of processing request AHI APDU 1302, orchestration agent 206 can send a notification 1507 to the device application stating that response AHI APDU 1304 is pending. If orchestration agent 206 does not wish to continue communication with orchestration center 104, orchestration agent 206 can release any acquired locks 312. Device application 204 can retrieve response AHI APDU 1304 by invoking the OAI get APDU operation 1508 available via OAI 216.OAI APDU acquisition operation 1508 may include the following operation: if response AHI APDU 1304 is available, then response AHI APDU 1304 is returned, wherein response AHI APDU 1304 can be delivered to orchestration center 104. Device application 204 uses device management protocol 128 to transmit the encoded response AHI APDU 1304 to device manager 106. Using OHI 118, device manager 106 may invoke placement APDU operation 1510 to deliver response AHI APDU 1304 to orchestration center 104. Placement APDU operation 1510 may include an operation of delivering response AHI APDU 1304 from a device. Parameters of placement APDU operation 1510 may include, but are not limited to, device ID and encoded APDU 1400, where device ID can identify the device sending response AHI APDU 1304.

[0110] Now for reference Figure 16 The diagram illustrates an example of a second AHI forward operation call 1600 for an initially available device, according to the disclosed technology. Device Manager 106 can interface with Orchestration Center 104 via OHI 118. Device Manager 106 can communicate with Device Application 204 via Device Management Protocol 128. Device Application 204 can interface with Orchestration Agent 206 via OAI 216. The example scenario can begin when a particular device is in a reachable state. For example, a reachable state can include, but is not limited to, a powered-on state, a de-powered state, and / or any specific state that allows open connectivity to the particular device.

[0111] Using OHI 118, the orchestration center 104 can send a notification 1601 to the device manager 106. Notification 1601 may include a pending notification of a specific AHI APDU 1400 for the orchestration agent 206 of a particular device. Using OHI 118, the device manager 106 can invoke a request APDU operation 1504 to retrieve a request AHI APDU 1302 for the device. The device manager 106 can use the device management protocol 128 to transmit the request AHI APDU 1302 to the device application 204. Upon receiving the request AHI APDU 1302, the device application 204 can use the OAI Place APDU operation 1506, available via OAI 216, to forward the request AHI APDU 1302 to the orchestration agent 206. The orchestration agent 206 can acquire a HUB lock or EUICC lock 312 suitable for a method call represented by the request AHI APDU 1302. The orchestration agent 206 can then begin processing the request AHI APDU 1302. When orchestration agent 206 completes processing request AHI APDU 1302, orchestration agent 206 may send a notification 1605 indicating that response AHI APDU 1304 is pending to device application 204. If orchestration agent 206 does not wish to continue communicating with orchestration center 104, orchestration agent 206 may release any acquired locks 312. Device application 204 may retrieve response AHI APDU 1304 by invoking OAI Acquire APDU operation 1508, which is available via OAI 216. Device application 204 may use device management protocol 128 to transmit the encoded response AHI APDU 1304 to device manager 106. Using OHI 118, device manager 106 may invoke Place APDU operation 1510 to deliver response AHI APDU 1304 to orchestration center 104.

[0112] Now for reference Figure 17 The diagram illustrates an example of an AHI reverse operation call 1700 according to the disclosed technology. Device Manager 106 can interface with Orchestration Center 104 via OHI 118. Device Manager 106 can communicate with Device Application 204 via Device Management Protocol 128. Device Application 204 can interface with Orchestration Agent 206 via OAI 216.

[0113] Using OAI 216, orchestration agent 206 can send notification 1701 to device application 204. Notification 1701 may include notification of pending request AHI APDU 1306 for orchestration center 104. Using OAI 216, device application 204 can trigger OAI Acquire APDU operation 1508. OAI Acquire APDU operation 1508 can retrieve request AHI APDU 1306 for orchestration center 104. Device application 204 can use device management protocol 128 to transmit request AHI APDU 1306 to device manager 106. Using OHI 118, device manager 106 can invoke place APDU operation 1510 to deliver request AHI APDU 1306 to orchestration center 104. Orchestration center 104 can process request AHI APDU 1306. When the orchestration center 104 finishes processing the request APDU, it can send a notification 1705 to the device manager 106 using OAI 216. This notification may include a statement that the orchestration center 104 is ready to respond to AHI APDU 1308. Using OHI 118, the device manager 106 can invoke the request APDU operation 1504 to retrieve the response AHI APDU 1308. The device manager 106 can use the device management protocol 128 to transmit the response AHI APDU 1308 to the device application 204. Using OAI 216, the device application 204 can invoke the OAI place APDU operation 1506 to deliver the response AHI APDU 1308 to the orchestration agent 206.

[0114] Now, the overall reference Figures 15 to 17 The first AHI forward operation call 1500, the second AHI forward operation call 1600, and the AHI reverse operation call 1700 can synchronize the device manager 106 with one or more devices, thereby reducing the transaction interruption rate due to signal loss, power loss, sleep mode, and other adverse events. Although, as with any communication system, these types of interruptions will still occur occasionally, the structure of the AHI APDU 1400 (including the MCID 1408 and the parity field 1410) allows for recovery.

[0115] like Figure 15 and Figure 16As shown, when an AHI APDU 1400 is ready to be transferred to a device, the orchestration center 104 can notify the device manager. When the device manager 106 invokes the request APDU operation 1504, the orchestration center 104 can construct the AHI APDU 1400. By waiting for the request APDU operation 1504, the orchestration center 104 can support one or more devices that are unavailable for extended periods. For example, one or more devices installed in a seasonal location may be repeatedly shut down and stored for most of the year, long enough that business conditions can change before an activity can be completed. While waiting for the device to become available, business conditions may change, and the orchestration center 104 can manage the AHI APDU 1400 by removing those that are no longer needed or by generating new AHI APDU 1400s with newer updates or activities.

[0116] Now for reference Figures 18 to 22 Five different example operations performed by the disclosed innovation are shown. These five different example operations are not intended to limit the scope of the disclosed innovation, and the disclosed innovation can perform operations other than those currently understood. The five different operations may include, but are not limited to, the first installation operation (see [link to documentation]). Figure 18 For further details), the second installation operation (see...) Figure 19 For further details), first update operation (see...) Figure 20 For further details), the second update operation (see...) Figure 21 (For further details) and deletion operations (see) Figure 22 (For further details). The disclosed innovations can also perform activation and suspension operations. For example, the first and second installation operations may include installing the subscription edge record with the help of an SM-DP+ server or an installation script. The first and second update operations may include updating the subscription edge record. The deletion operation may include deleting the subscription edge record. The activation and suspension operations may respectively include activating and suspending the subscription edge record.

[0117] Now for reference Figure 18The diagram illustrates a first installation operation 1800 according to an example of the disclosed technology. The first installation operation 1800 may include a sequence diagram illustrating an example progression of a particular installation operation, wherein the disclosed innovation can install a subscription edge record 402 into one or more devices. The orchestration center 104 can interface with the SM-DP+ server 122 via the ES9+ interface 124. The orchestration center 104 can interface with the orchestration agent 206 via AHI 134. The orchestration agent 206 can connect to the eUICC 224. The eUICC 224 may be compatible with SGP.22 version 2.4 and / or any other specific remote SIM configuration architecture.

[0118] Orchestration center 104 can invoke AHI install operation 1801 to orchestration agent 206. AHI install operation 1801 can define a request to install subscription edge record 402. For example, AHI install operation 1801 includes a technology for initiating the install operation. Continuing this example, the parameters of AHI install operation 1801 can include, but are not limited to, operation_id and the subscription context fields shown in Table 5. The band_list, plmn_rank, geo, cm_attributes, dm_attributes, cm_extdata, and dm_extdata fields in the subscription context fields shown in Table 5 can contain inline data or BLOB identifiers for subsequent retrieval if the subscription context is larger than the maximum APDU size. During the initial install phase, orchestration agent 206 can save the subscription context to a new subscription edge record 402 in local repository 218. Orchestration agent 206 can return a successful completion message to orchestration center 104 for the AHI install operation 1801 invocation.

[0119] The orchestration agent 206 may request EUICC and / or HUB locks as described in Table 1. Upon acquiring the EUICC and / or HUB lock (possibly after any time period), the orchestration agent 206 may open a logical channel with the destination eUICC 224 via ISD-R, perform an eUICC information acquisition operation 1802, and then perform an eUICC challenge operation 1803.

[0120] Using EUICC data from the EUICC Information Acquisition operation 1802 and EUICC Challenge data from the EUICC Challenge Acquisition operation 1803, the orchestration agent 206 can invoke the Initiate Authentication Reverse Operation 1804. The first Initiate Authentication Operation 1804 may include techniques for proxying the ES9+ Initiate Authentication Operation to the SM-DP+ server 122 via the orchestration center 104 as part of a public mutual authentication process. In response to the first Initiate Authentication Operation 1804, the orchestration center 104 can obtain the SM-DP+ URL from the subscription center line 404 and can execute the corresponding second Initiate Authentication Operation 1805 using the appropriate SM-DP+ server 122. The second Initiate Authentication Operation 1805 can trigger a response from the SM-DP+ server to generate the transactionID, serverSigned1, serverSignature1, euiccCiPKIdToBeUsed, and serverCertificate fields, which the orchestration center 104 can return to the orchestration agent 206 via the first Initiate Authentication Operation 1804.

[0121] Orchestration agent 206 can use the dpp_token field from the subscription context and information associated with modem 208 (received from device application 204) to construct the CtxParams1 value as described in SGP.22 version 2.4. Using the CtxParams1 value along with the transactionID, serverSigned1, serverSignature1, euiccCiPKIdToBeUsed, and serverCertificate fields, orchestration agent 206 can perform authentication server operation 1806.

[0122] The orchestration agent 206 can invoke the first authentication client operation 1807 using the transactionID value returned by the first authentication operation 1804 and the authenticateServerResponse value returned by the authentication server operation 1806. The orchestration center 104 can then execute the second authentication client operation 1808 using the appropriate SM-DP+ server 122. The second authentication client operation 1808 may include relaying the transactionID and authenticateServerResponse fields between the SM-DP+ server 122 and the orchestration center 104. The second authentication client operation 1808 may include transactionID, profileMetadata, smdpSigned2, smdpSignature2, and smdpCertificate fields, which the orchestration center 104 can relay to the orchestration agent 206 as the return value of the first authentication client operation 1807. The first authentication client operation 1807 and / or the second authentication client operation 1808 may include technology for proxying the ES9+ authentication client operation to the SM-DP+ server 122 via the orchestration center 104 as part of a public mutual authentication process.

[0123] After completing the first authentication client operation 1807 and the second authentication client operation 1808, the orchestration agent 206 can check the profileMetadata fields and follow the procedures described in steps 7 and 8 of SGP.22 version 2.4, 3.1.3. If user consent is required based on the PPR value in the eSIM profile metadata and the eUICC rule authorization table, the ppr1_consent and ppr2_consent fields in the subscription context can provide consent for PPR1 and PPR2 present in the profile metadata. If PPR1 exists in the profile metadata and ppr1_consent is false in the subscription context, or if PPR2 exists in the profile metadata and ppr2_consent is false in the subscription context, consent can be denied. If necessary, the orchestration agent 206 can execute the ES10b.GetRat and ES10b.GetProfilesInfo functions to complete the evaluation process. If a confirmation_code value exists in the context information, orchestration agent 206 can use SHA256 to generate a hashcc value from the cc field of the subscription context, as explained in step 8 of 3.1.3 of the SGP.22 specification.

[0124] Orchestration agent 206 can perform a prepare-to-download operation 1809. The prepare-to-download operation may include retrieving parameters from eUICC 224, such as smdpSigned2, smdpSignature2, smdpCertificate, and hashcc (if a cc field exists in the subscription context). Orchestration agent 206 can invoke a first profile package operation 1810. The first profile package operation 1810 may include a transactionID and an ES10b.PrepareDownload response as parameters. The first profile package operation 1810 may include techniques for proxying the ES9+ GetBoundProfilePackage operation to the SM-DP+ server 122 via orchestration center 104. The orchestration center can utilize the appropriate SM-DP+ server 122 to perform a second profile package operation 1811. The SM-DP+ server 122 can respond with an ES9+ GetBoundProfilePackage response. Orchestration center 104 may store the boundProfilePackage in its database, such as in table rows related to the subscription being installed. In one example, orchestration center 104 may return the boundProfilePackage output field as part of the first profile package return value to orchestration agent 206. In another example, orchestration center 104 may return the BLOB ID of boundProfilePackage as part of the first profile package return value to the orchestration agent for subsequent retrieval by orchestration agent 206 using BLOB retrieval operation 1812. BLOB retrieval operation 1812 may include techniques for reading the BLOB from orchestration center 104. Orchestration agent 206 may read the BLOB entirely or in segments across multiple method calls. Parameters for reading include, but are not limited to, blob_id (identifying the BLOB), offset (identifying the starting offset of the data), and length (identifying the maximum byte length of the data to be returned). The return value may include a result code and, upon success, the requested data from the BLOB.

[0125] The orchestration agent 206 can invoke the BLOB retrieval operation 1812, receiving the BLOB ID returned by the first configuration file package operation 1810 as the BLOB_id parameter. The BLOB retrieval operation 1812 can return the bound configuration file package data to the orchestration agent 206.

[0126] Orchestration agent 206 can follow the process described in SGP.22 version 2.4 5.7.6, segmenting the bound profile package and calling the load bound profile package operation 1813 multiple times as needed. Once the last segment of the profile package is successfully loaded, the load bound profile package operation 1813 can return the ProfileInstallationResult value. In one example, the load bound profile package operation 1813 can be the "loadBoundProfilePackage()" operation according to the GSMA standard.

[0127] Orchestration agent 206 may invoke the first processing notification operation 1814, passing the ProfileInstallationResult from the loaded bound configuration file package operation 1813 as a parameter. Orchestration center 104 may utilize the appropriate SM-DP+ server 122 to invoke the second processing notification operation 1815. Upon successful completion of the second processing notification operation 1815 and the return value of the first processing notification operation 1814, orchestration agent 206 may perform a notification removal operation 1816 on eUICC 224. Orchestration agent 206 may send a notification 1817 to orchestration center 104 indicating that the operation is complete. In the illustrative embodiment, the subscription installation process may send more than one notification 1817 after the configuration file is successfully installed.

[0128] In one example, the subscription installation process of the first install operation 1800 can download the complete binding configuration file package in a single fetch BLOB operation 1812. In another example, the orchestration agent 206 can use multiple fetch BLOB operations 1812 to download the binding configuration file package, or the first configuration file operation 1810 can include the complete binding configuration file package in its return call, depending on resources and capabilities.

[0129] Now for reference Figure 19 The diagram illustrates a second installation operation 1900 using a configuration file to install a script, as an example of the disclosed technology. The second installation operation 1900 may illustrate a sequence diagram for installing a subscription edge record 402 into a specific device. The orchestration center 104 may interface with the connectivity manager 102 using a CMI 116. The orchestration center 104 may interface with the orchestration agent 206 using an AHI 134. The orchestration agent 206 may connect to an eUICC 224.

[0130] Orchestration Center 104 can invoke AHI Install Operation 1901 to Orchestration Agent 206. Parameters for AHI Install Operation 1901 may include the subscription context fields shown in Table 5, including `ins_script`. Orchestration Agent 206 may save the subscription context to a new subscription edge record 402 in its local repository 218, with the initial state of this new subscription edge record 402 being "Installing" 902. Orchestration Agent 206 may return a successful completion message for AHI Install Operation 1901 to Orchestration Center 104. Orchestration Agent 206 may invoke the Get BLOB Operation 1812 to retrieve the install script from Orchestration Center 104 using the blob ID included in the `ins_script` field of AHI Install Operation 1901. Orchestration Center 104 may invoke the CMI Get Script Operation 1903 to retrieve the install script from Connectivity Manager 102 using the `ins_script` field of the subscription center row. The script retrieval operation 1903 can return a script, which is then returned to the orchestration agent 206 in the return value of the BLOB retrieval operation 1902.

[0131] Orchestration agent 206 can acquire EUICC lock 312 and then execute the C-APDU component 1904 of the installation script, thereby capturing the R-APDU response for each command. When all C-APDUs have been sent to eUICC 224 and the loop is complete, orchestration agent 206 can release the EUICC lock, acquire the HUB lock, and call the BLOB placement operation 1905 to write the R-APDU data to orchestration center 104, using ins_script (from AHI installation operation 1901) + 1 as the blob_id and the R-APDU data as the blob data. Orchestration agent 206 can send a notification 1906 indicating that the operation is complete to orchestration center 104. Orchestration center 104 can call the script shutdown operation 1907 to report the results of the installation script to connectivity manager 102.

[0132] Now for reference Figure 20 The diagram illustrates a first update operation 2000 without configuration file content management, as an example of the disclosed technology. The first update operation 2000 can be illustrated as a sequence diagram, which may include changes to the subscription context 414 of the subscription edge record 402. The orchestration center 104 can use AHI 134 to invoke update operation 2001 of the orchestration agent 206. Since the parameters of update operation 2001 only specify changes to the subscription context, update operation 2001 can complete and return a success status, thus completing the operation.

[0133] Now for reference Figure 21The diagram illustrates a second update operation 2100 with configuration file content management, as an example of the disclosed technology. The second update operation 2100 may illustrate a technique for updating a subscription edge record 402 (including its subscriber identity 412 and subscription context 414). The orchestration center 104 can use AHI 134 to invoke update operation 1601 of the orchestration agent 206. Since the update method parameter includes the blob ID of the update script, the orchestration agent 206 can preimage the updated subscription context and return a pending state. The orchestration agent 206 can acquire a HUB lock and can invoke the get_blob operation 2102 to retrieve the update script. Upon receiving the get_blob method call, the orchestration center 104 can use CMI 116 to issue a corresponding open script operation 2103 to the connectivity manager 102. The return value of the open script operation 2103 is relayed to the orchestration agent as the return value of the get_blob operation 2102.

[0134] The orchestration agent 206 can release the HUB lock and acquire the EUICC lock 312. The orchestration agent 206 can iterate through the update script C-APDU commands 2104, while recording R-APDU responses. Upon completion of all script commands, the orchestration agent 206 can release the EUICC lock 312 and acquire the HUB lock. The orchestration agent 206 can invoke the BLOB placement operation 2105 to send a response to the update script. The orchestration agent 206 can send a notification 2106 indicating operation completion and release all locks. The orchestration center 104 can close the script using the script shutdown operation 2107.

[0135] In embodiments with limited MTU size and other resource constraints, orchestration agent 206 can replace a single fetch BLOB operation 2102 with multiple fetch BLOB operations 2102, and it can replace a single place BLOB operation 2105 with multiple place BLOB operations 2105.

[0136] Now for reference Figure 22 The diagram illustrates an example deletion operation 2200 according to the disclosed technology. Orchestration center 104 can use AHI 134 to invoke deletion operation 2201 of orchestration agent 206. After a possible delay of any duration, orchestration agent 206 can acquire the eUICC and modem locks and perform deletion profile operation 2202. eUICC 224 can then release its lock.

[0137] Based on local conditions and the eSIM profile configuration, the profile deletion operation 2202 can generate a notification. Therefore, the orchestration agent 206 can acquire the EUICC and Hub lock. The orchestration agent 206 can perform a notification list retrieval operation 2204. The orchestration agent 206 can begin an iteration loop 2205 for each notification. During each loop iteration 2205, the orchestration agent 206 can invoke a first notification processing operation 2206. The orchestration center 104 can use the ES9+ interface 124 with the appropriate SM-DP+ server 122 to perform a second notification processing operation 2207. The orchestration agent 206 can perform a notification removal operation 2208 on the eUICC 224, thereby clearing the notification from the eUICC storage.

[0138] Once iteration loop 2205 is complete, orchestration agent 206 can generate notification 2209 to orchestration center 104. Notification 2209 may include information informing orchestration center 104 that subscription edge record 402 has been deleted. Orchestration center 104 may take appropriate further actions, such as, but not limited to, terminating subscription and other appropriate steps.

[0139] Now for reference Figure 23A The diagram illustrates a general query operation 2300A, an example of the disclosed technology. General query operation 2300A may include techniques for querying the topology of a specific device regarding its eUICC 224, subscription, and modem. The orchestration center 104 may use AHI 134 to invoke query method 2301A of the orchestration agent 206 to return the topology of the eUICC 224, subscription, and modem associated with the specific device.

[0140] Now, the overall reference Figures 23B to 23C Device Manager 106 and Connectivity Manager 102 can forward subscription source lines to Orchestration Center 104. By forwarding subscription source lines to Orchestration Center 104, Orchestration Center 104 can replicate changes in the subscription center lines to subscription edge lines. Orchestration Center 104 can use the sub_uid and sub_rev fields of the subscription center lines and subscription edge lines, as well as the sync_state field of the subscription center lines, to utilize a two-stage asynchronous replication system to replicate changes in the subscription center lines to the subscription edge lines.

[0141] Now for reference Figure 23BSequence diagram 2300B, illustrating an example of the disclosed technology, is shown. Sequence diagram 2300B can illustrate the progress of an asynchronous subscription update operation driven by a subscription source line update from connectivity manager 102. Orchestration center 104 can interface with connectivity manager 102 using CMI 116. Following a rezoning operation that can, for example, change the list of subscription PLMNs, connectivity manager 102 can generate a notification 2301B for orchestration center 104 declaring the rezoning operation. Orchestration center 104 can then perform a read subscription operation 2302B to obtain the subscription source line. Orchestration center 104 can then follow... Figure 6 The detailed process described in section 600 is to merge the updates into the relevant subscription center rows.

[0142] Now for reference Figure 23C The diagram illustrates a sequence diagram 2300C, representing an example of the disclosed technology. Sequence diagram 2300C can illustrate the progress of an asynchronous subscription update operation driven by an update of the subscription source row from device manager 106. Orchestration center 104 can interface with device manager 106 using OHA 111. After, for example, a user changes the ranking of a specific subscription, device manager 106 can update the subscription with the updated fields in the subscription source row via update subscription operation 2304C. Orchestration center 104 can follow... Figure 6 The detailed process described in section 600 is to merge the updates into the relevant subscription center rows.

[0143] Overall reference Figures 24 to 27 The disclosed innovation enables Device Manager 106 to organize operations into activities. An activity can be defined as a sequentially ordered set of operations applied to one or more devices. While the operations can be sequential and ordered for each device in an activity, the devices themselves can be processed in parallel. For example, an activity may include two installation operations followed by a deletion operation, each performed on 500 (or more) devices. Orchestration Center 104 can initiate all 500 installation operations simultaneously, and when these operations are completed, Orchestration Center 104 can begin subsequent operations device by device. Activities provide a useful management structure where RSP operations may incur costs, and the costs of RSP operations can be controlled and accounted for differently from other aspects of device management.

[0144] Now for reference Figure 24The diagram illustrates an example of a lifecycle state machine 2400 for an activity, based on the disclosed technology. Device Manager 106 can create an activity by invoking the Create Activity operation of OHI 118. Device Manager 106 can create an activity in the COMPOSING state 2401, while in this state, Device Manager 106 can use subsequent append activity operations to add additional operations and devices. Device Manager 106 can invoke the Cancel Activity operation to change the state to CANCELLED 2402. Alternatively or additionally, once the activity has been constructed, Device Manager 106 can invoke the Commit Activity operation to change the state to COMMITTED 2403. Once the activity is in the Committed state 2403, Device Manager 106 can invoke the Confirm Activity operation to change the state to EXECUTING 2405, or it can invoke the Reject Activity operation to change the state to REFUSED 2404. Once an activity is in the running state 2405, Device Manager 106 can run the activity until completion, unless it is terminated by a terminate activity operation. Either condition can bring the activity to the terminated state, i.e., DONE 2406.

[0145] The lifecycle state machine 2400 and the aforementioned operations allow control and accounting to exist on both sides of OHI 118, which may be helpful when the orchestration center 104 can be provided as a service or when managing large events. For example, device manager 106 may only allow confirmation of event operations originating from certain user accounts, where these users follow a well-defined process to confirm or reject events. When the orchestration center 104 is more tightly integrated into the device management system or when the event is smaller, these controls can be tailored to favor controls primarily implemented within device manager 106. In these cases, a single device manager 106 and / or any other specific system of the disclosed technology can initiate calls for creating, submitting, and confirming events. Device manager 106 and / or any other specific system of the disclosed technology can prompt a dialog box requiring confirmation before proceeding with the confirmation event operation.

[0146] Now for reference Figure 25The diagram illustrates a sequence of activities for an installation operation, 2500, according to an example of the disclosed technology. Device Manager 106 can create an activity by invoking Activity Creation Operation 2501. Parameters for Activity Creation Operation 2501 may include a list of device_id values, modem_ordinal, modem_slot, and template_id. Device Manager 106 can submit the activity using Update Command Operation 2502 and subsequently approve the activity using a second Update Command Operation 2503. Orchestration Center 104 can initiate Loop 2504 to iterate through the devices specified in the list of device_id values. Device Manager 106 and / or Orchestration Center 104 can execute Loop 2504 sequentially, one device at a time, or in parallel for all devices, or as a series of parallel operations involving multiple devices, depending on available system resources and urgency. For each device, Orchestration Center 104 can acquire a subscription from Connectivity Manager 102 using CMI 116 by invoking Acquire Subscription Operation 2505. Once a subscription is acquired, connectivity manager 102 can send a notification 2506 to orchestration center 104. Orchestration center 104 can then retrieve the subscription using read subscription operation 2507. The disclosed innovation can then be executed as follows: Figures 18 to 19 The installation operation 2508 described herein is used to install the desired information on each specific device. For example, for a subscription installed using SM-DP+ download, an example embodiment may employ... Figure 18 The first installation operation is 1800. In another example, for a subscription installed using a configuration file installation script, the illustrative embodiment may employ... Figure 19 The second update operation 1900. In response to the completion of the installation operation, the orchestration center 104 can send a progress notification 2509 to the device manager 106. Once cycle 2504 is complete, the orchestration center 104 can update the activity status to completed 2006 and send a final notification 2510 to the device manager 106 indicating that the activity is complete.

[0147] Now for reference Figure 26The diagram illustrates a sequence of activities for an update operation, as shown in Figure 2600, according to an example of the disclosed technology. Device Manager 106 can invoke Activity Creation operation 2601 to create an activity. Parameters for Activity Creation operation 2601 may include a list of subscription identifiers. Device Manager 106 can submit the activity using Update Activity operation 2602. Device Manager 106 can then approve the activity using a second Update Activity operation 2603. Orchestration Center 104 can organize the subscription identifiers into common devices and begin Loop 2604 to iterate through these devices. Device Manager 106 and / or Orchestration Center 104 can execute Loop 2604 sequentially, one device at a time, or in parallel for all devices, or as a series of parallel operations involving multiple devices, depending on available system resources and urgency. Device Manager 106 and / or any other system using the disclosed technology can perform operations such as... Figures 20 to 21 The update operation 2605 is shown in the illustration. For example, for a subscription that is updated without configuration file content management, the illustrative embodiment may employ... Figure 20 The first update operation is 2000. In another example, for a subscription that is updated in the presence of configuration file content management, the illustrative embodiment may employ... Figure 21 The second operation 2100. The orchestration center 104 can generate a notification 2606 when each device is updated. The orchestration center 104 can generate a notification 2607 indicating that the activity has been completed.

[0148] Now for reference Figure 27 The diagram illustrates a sequence of activities for a deletion operation, as shown in example 2700, according to the disclosed technology. Device Manager 106 can invoke Create Activity operation 2701 to create an activity. Parameters for Create Activity operation 2701 may include a list of subscription identifiers. Device Manager 106 can submit the activity using Update Activity operation 2702. Device Manager 106 can then approve the activity using a second Update Activity operation 2703. Orchestration Center 104 can organize the subscription identifiers into common devices and begin Loop 2704 to iterate over these devices. Device Manager 106 and / or Orchestration Center 104 can execute Loop 2704 sequentially, one device at a time, or in parallel for all devices, or as a series of parallel operations involving multiple devices, depending on available system resources and urgency. Device Manager 106 and / or any other system using the disclosed technology can perform one or more deletion operations (such as...) for each specific device. Figure 22(See operation 2201 shown). In one example, the "UpdateCampaign()" operation can be used to update activity information or delete an activity or activity information. The orchestration center 104 can generate a notification 2706 when specific data is deleted from each device. The orchestration center 104 can generate a notification 2707 indicating that the activity has been completed.

[0149] In one example, this article (specifically regarding combination) Figures 15 to 27 The operations mentioned in the sequence diagrams shown and discussed may be GSMA operations, or operations according to other standards, specifications, and protocols. For example, these operations may correspond to operations described in the SGP.02, SGP.22, and SGP.32 standards (and others). In at least one example, Figure 15 Step 1504, the "Request APDU Operation" step, can correspond to the GSMA "GetApdu()" operation. In another example, such as combining... Figure 18 The operation discussed in step 1802, such as "get EUICC information," can correspond to an operation described according to the ES10 interface, such as "ES10b.GetEUICCInfo." In other examples, such as Figure 18 Operations like "First Initiate Authentication Operation" (1804) can correspond to operations described according to ES9+ interfaces, such as "es9p_InitiateAuthentication()". Furthermore, such as Figure 18 The "second initiation of authentication" operation at step 1805 can correspond to the GSMA "InitiateAuthentication" operation. Therefore, although some operations are referred to in a broad sense (for ease of understanding), it should be understood from the discussion herein that these operations can correspond to one or more standards, specifications, and protocols described throughout this disclosure.

[0150] in conclusion The disclosures herein may be performed wholly or partially by a computing environment, which may include server computers or any other system providing computing power. Alternatively, the computing environment may employ multiple computing devices, which may be arranged in, for example, one or more server banks or computer banks or other arrangements. Such computing devices may be located in a single installation location or may be distributed across many different geographical locations. For example, a computing environment may include multiple computing devices that together may include hosted computing resources, grid computing resources, and / or any other distributed computing arrangements. In some cases, the computing environment may correspond to elastic computing resources, where the allocated processing power, networking, storage, or other computing-related resources may vary over time.

[0151] Various applications and / or other functions can be executed in the computing environment according to various embodiments. Furthermore, various data are stored in a database accessible to the computing environment. As will be understood, the database may represent multiple databases. For example, the data stored in the database may be associated with the operation of the various applications and / or functional entities described herein.

[0152] The computing environment can communicate with multiple computing devices and query devices (which may include computing devices) via a network. The network includes, for example, the Internet, intranet, extranet, wide area network (WAN), local area network (LAN), wired network, wireless network, or other suitable networks, or any combination of two or more such networks. For example, such networks may include satellite networks, wired networks, Ethernet networks, and other types of networks.

[0153] The aspects, features, and benefits of the systems, methods, processes, formulations, apparatuses, and products discussed herein will become apparent from the accompanying drawings and information disclosed in other applications incorporated herein by reference. Variations and modifications to the disclosed systems and methods may be made without departing from the spirit and scope of the novel concept of this disclosure.

[0154] However, it will be understood that the information disclosed in the accompanying drawings or in the applications incorporated herein by reference is not intended to limit the scope of this disclosure; any changes and further modifications to the described or illustrated embodiments and any further application of the principles of this disclosure as illustrated herein are to be thought of by one of ordinary skill in the art to which this disclosure pertains.

[0155] The description of the exemplary embodiments above is presented for illustrative and descriptive purposes only and is not intended to be exhaustive or to limit the systems and processes to the precise forms disclosed. In view of the above teachings, many modifications and variations are possible.

[0156] The embodiments have been chosen and described to explain the principles of the systems and processes and their practical application, enabling those skilled in the art to utilize the systems and processes and the various embodiments, as well as to utilize various modifications suitable for the particular intended use. Alternative embodiments will become apparent to those skilled in the art to which these systems and processes pertain, without departing from the spirit and scope of these systems and processes. Therefore, the scope of these systems and processes is defined by the appended claims, and not by the foregoing description and the exemplary embodiments described herein.

[0157] As will be understood from the foregoing, the various aspects of the processes described herein are software processes executed on a computer system that forms part of the system. Therefore, it will be understood that the various embodiments of the systems described herein are typically implemented as specially configured computers that include a variety of computer hardware components and, in many cases, include significant additional features compared to conventional or known computers, processes, etc., as discussed in more detail herein. Embodiments within the scope of this disclosure also include computer-readable media for carrying or having computer-executable instructions or data structures stored thereon. Such computer-readable media can be any available medium that is accessible by a computer or downloadable via a communications network. By way of example and not limitation, such computer-readable media can include various forms of data storage devices or media, such as RAM, ROM, flash memory, EEPROM, CD-ROM, DVD or other optical disc storage devices, disk storage devices, solid-state drives (SSDs) or other data storage devices, any type of removable non-volatile memory (such as Secure Digital (SD), flash memory, Memory Stick, etc.), or any other medium that can be used to carry or store computer program code in the form of computer-executable instructions or data structures and is accessible by a computer.

[0158] When information is transmitted or provided on a network or on another communication connection to a computer (hardwired, wireless, or any combination of hardwired and wireless), the computer appropriately represents that connection as a computer-readable medium. Therefore, any such connection is appropriately called and considered a computer-readable medium. Combinations of the above should also be included within the scope of computer-readable media. Computer-executable instructions include, for example, instructions and data that cause the computer to perform a specific function or a set of functions.

[0159] Those skilled in the art will understand the characteristics and aspects of a suitable computing environment in which the aspects of this disclosure can be implemented. While not essential, some embodiments of the claimed systems and processes can be described in the context of computer-executable instructions, such as program modules or engines executed by a computer in a networked environment as previously described. Such program modules are often reflected and illustrated by flowcharts, sequence diagrams, exemplary screen displays, and other techniques used by those skilled in the art to convey how such computer program modules are made and used. Typically, program modules include routines, programs, functions, objects, components, data structures, application programming interface (API) calls to other computers, whether local or remote, that perform specific tasks or implement specifically defined data types within a computer. The data structures and / or schemes associated with the computer-executable instructions and the program modules represent examples of program code for performing the steps of the methods disclosed herein. Specific sequences of such executable instructions or associated data structures represent examples of corresponding actions for implementing the functions described in such steps.

[0160] Those skilled in the art will also understand that the claimed and / or described systems and methods can be practiced in networked computing environments with many types of computer system configurations, including personal computers, smartphones, tablets, handheld devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, networked PCs, minicomputers, mainframes, etc. Embodiments of the claimed systems and processes are practiced in distributed computing environments, where tasks are performed by local and remote processing devices linked via a communication network (via a hardwired link, via a wireless link, or any combination of hardwired and wireless links). In a distributed computing environment, program modules can reside in local and remote memory storage devices.

[0161] An exemplary system, not shown, for implementing various aspects of the described operations, includes a computing device comprising a processing unit, system memory, and a system bus that couples various system components, including the system memory, to the processing unit. A computer typically includes one or more data storage devices for reading data from and writing data to them. The data storage devices provide the computer with non-volatile storage of computer-executable instructions, data structures, program modules, and other data.

[0162] The computer program code that implements the functions described herein typically includes one or more program modules that can be stored on a data storage device. As those skilled in the art will appreciate, such program code typically includes an operating system, one or more applications, other program modules, and program data. Users can input commands and information into the computer via a keyboard, touchscreen, pointing device, script containing computer program code written in a scripting language, or other input devices (not shown) (such as a microphone), or, in the case of an NFC wristband or RFID device, by holding it near or touching it to an NFC- or RFID-enabled computer, smartphone, or mobile device. These and other input devices are typically connected to the processing unit via known electrical, optical, or wireless connections.

[0163] The computers affecting many aspects of the described process typically operate in a networked environment using logical connections to one or more remote computers or data sources, which are further described below. Remote computers can be other personal computers, servers, routers, network PCs, peer devices, or other common network nodes, and typically include many or all of the elements described above regarding the host computer system in which the system and process are implemented. Logical connections between computers include local area networks (LANs), wide area networks (WANs), virtual networks (WANs or LANs), and wireless LANs (WLANs), which are presented herein as examples rather than limitations. Such networked environments are common office-wide or enterprise-wide computer networks, intranets, and the Internet.

[0164] When used in a LAN or WLAN networking environment, the computer system implementing the system and process aspects is connected to the local network via a network interface or adapter. When used in a WAN or WLAN networking environment, the computer may include a modem, wireless link, or other mechanisms for establishing communication over a wide area network such as the Internet. In a networking environment, program modules or portions thereof described with respect to the computer may be stored in a remote data storage device. It should be understood that the network connections described or illustrated are exemplary, and other mechanisms for establishing communication over a wide area network or the Internet may be used.

[0165] While various aspects have been described in the context of preferred embodiments, those skilled in the art will readily discern additional aspects, features, and methods of the claimed systems and processes from the description herein. Without departing from the spirit or scope of the claims, numerous embodiments and adaptations of this disclosure and the claimed systems and processes, as well as numerous variations, modifications, and equivalent arrangements and methods, will be apparent or reasonably suggested by this disclosure and its foregoing description. Furthermore, any order and / or timing of the steps of the various processes described and claimed herein should be considered as the best mode for implementing the claimed systems and processes. It should also be understood that while the steps of various processes may be shown and described in a preferred order or timing, the steps of any such process are not limited to any particular order or sequence in the absence of specific instructions for achieving a particular intended result. In most cases, the steps of such processes may be implemented in various different orders and sequences and still fall within the scope of the claimed systems and processes. Additionally, some steps may be implemented simultaneously, concurrently, or synchronously with other steps.

[0166] The embodiments were chosen and described to explain the principles of the claimed systems and processes and their practical application, enabling those skilled in the art to utilize the systems and processes and the various embodiments, as well as to utilize various modifications suitable for the particular intended use. Alternative embodiments will become apparent to those skilled in the art to which the claimed systems and processes pertain, without departing from the spirit and scope of the claimed systems and processes. Therefore, the scope of the claimed systems and processes is defined by the appended claims, and not by the foregoing description and the exemplary embodiments described herein.

Claims

1. A system comprising: An orchestration agent, comprising software configuration installed on a mobile computing device, wherein the orchestration agent is operatively connected to an embedded general-purpose integrated circuit card (eUICC) and memory on the mobile computing device; and An orchestration center, operatively connected to the orchestration agent, wherein the orchestration center includes a processor and a database, the database including centralized network subscription information from one or more management platforms, wherein the processor is operatively configured to: Receive first updated network subscription information from the device management platform in one or more management platforms; Receive a second updated network subscription information from the network connectivity management platform in one or more of the management platforms; The first updated network subscription information and the second updated network subscription information are compared with multiple subscription records in the centralized network subscription information; In response to determining a common identifier among a specific subscription record in the plurality of subscription records, the first updated network subscription information, and the second updated network subscription information, a new subscription record including the current network subscription information is generated based on the first updated network subscription information and the second updated network subscription information; and A copy of the new subscription record is transmitted to the orchestration agent at the mobile computing device, wherein the orchestration agent is operablely configured to replace one or more information fields of the subscription edge record at the eUICC and the memory with corresponding information fields from the copy of the new subscription record.

2. The system according to claim 1, wherein, The public identifier is the Integrated Circuit Card Identifier (ICCID) value.

3. The system according to claim 1, wherein, Transmitting the copy of the new subscription record to the orchestration agent includes transmitting the copy of the new subscription record to the orchestration agent via a network tunnel.

4. The system according to claim 1, wherein, The orchestration center is operatively configured to transmit the copy of the new subscription record in response to receiving an indication of device availability.

5. The system according to claim 1, wherein, The orchestration center is operatively connected to the Subscription Manager Data Preparation Enhanced Version SM-DP+ server.

6. The system according to claim 5, wherein, The subscription edge record includes an eSIM profile received from the SM-DP+ server and stored in the eUICC, and also includes subscription context information received from the network connectivity management platform and stored in the memory.

7. The system according to claim 6, wherein, The orchestration center is operatively configured to update the eSIM profile via one or more APDU scripts.

8. A method comprising: Receive the first updated network subscription information from a device management platform in one or more management platforms; Receive a second updated network subscription information from the network connectivity management platform in one or more of the management platforms; The first updated network subscription information and the second updated network subscription information are compared with multiple subscription records in the centralized network subscription information stored in the orchestration center; In response to determining a common identifier among a specific subscription record in the plurality of subscription records, the first updated network subscription information, and the second updated network subscription information, a new subscription record including the current network subscription information is generated based on the first updated network subscription information and the second updated network subscription information; as well as A copy of the new subscription record is transmitted to an orchestration agent at the mobile computing device, wherein the orchestration agent is operablely configured to replace one or more information fields of the eUICC at the mobile computing device and the subscription edge record at the memory with corresponding information fields from the copy of the new subscription record.

9. The method according to claim 8, wherein, The public identifier is the Integrated Circuit Card Identifier (ICCID) value.

10. The method according to claim 8, wherein, Transmitting the copy of the new subscription record to the orchestration agent includes transmitting the copy of the new subscription record to the orchestration agent via a network tunnel.

11. The method according to claim 8, wherein, The orchestration center is operatively configured to transmit the copy of the new subscription record in response to receiving an indication of device availability.

12. The method according to claim 8, wherein, The orchestration center is operatively connected to the Subscription Manager Data Preparation Enhanced Version SM-DP+ server.

13. The method according to claim 8, wherein, The subscription edge record includes an eSIM profile received from the SM-DP+ server and stored in the eUICC, and also includes subscription context information received from the network connectivity management platform and stored in the memory.

14. The method according to claim 13, wherein, The orchestration center is operatively configured to update the eSIM profile via one or more APDU scripts.

15. A non-transitory computer-readable medium comprising instructions that, when read by a processor, cause the processor to execute: Receive the first updated network subscription information from a device management platform in one or more management platforms; Receive a second updated network subscription information from the network connectivity management platform in one or more of the management platforms; The first updated network subscription information and the second updated network subscription information are compared with multiple subscription records in the centralized network subscription information stored in the orchestration center; In response to determining a common identifier among a specific subscription record in the plurality of subscription records, the first updated network subscription information, and the second updated network subscription information, a new subscription record including the current network subscription information is generated based on the first updated network subscription information and the second updated network subscription information; as well as A copy of the new subscription record is transmitted to an orchestration agent at the mobile computing device, wherein the orchestration agent is operablely configured to replace one or more information fields of the eUICC at the mobile computing device and the subscription edge record at the memory with corresponding information fields from the copy of the new subscription record.

16. The non-transitory computer-readable medium according to claim 15, wherein, The public identifier is the Integrated Circuit Card Identifier (ICCID) value.

17. The non-transitory computer-readable medium according to claim 15, wherein, Transmitting the copy of the new subscription record to the orchestration agent includes transmitting the copy of the new subscription record to the orchestration agent via a network tunnel.

18. The non-transitory computer-readable medium of claim 15, further comprising instructions that, when read by the processor, cause the orchestration center to transmit the copy of the new subscription record in response to receiving an indication of device availability.

19. The non-transitory computer-readable medium according to claim 15, wherein, The orchestration center is operatively connected to the Subscription Manager Data Preparation Enhanced Version SM-DP+ server.

20. The non-transitory computer-readable medium according to claim 19, wherein, The subscription edge record includes an eSIM profile received from the SM-DP+ server and stored in the eUICC, and the subscription edge record also includes subscription context information received from the network connectivity management platform and stored in the memory, wherein the orchestration center is operatively configured to update the eSIM profile via one or more APDU scripts.

Images