GB2589095A

GB2589095A - An apparatus and method for managing communication with security modules

Info

Publication number: GB2589095A
Application number: GB1916757.6A
Authority: GB
Inventors: James Reid Paul; Clarke Kyle; Henry Thomson Nimmo Robert; Whiteside Jaimie
Original assignee: Kigen UK Ltd
Current assignee: Kigen UK Ltd
Priority date: 2019-11-18
Filing date: 2019-11-18
Publication date: 2021-05-26
Anticipated expiration: 2039-11-18
Also published as: WO2021099754A1; GB2589095B; GB201916757D0

Abstract

Traditionally eSIM (embedded subscriber identity modules), eUICC (universal integrated circuit card) and iUICC (integrated UICC) were owned by MNO (mobile network operators) which owned/ran their own SM-SR (Subscription Manager Secure Routing) to securely transmit profiles to eSIM to provision them. Transmission may be via SMS-C (short message service centre). Now, more entities may own eSIM (e.g. smart meter operators) and not wish to operate an SM-SR. The embodiment is SM-SR as a service 12 for multiple SIM owning customers 70,75,80. The SM-SR stores bindings between SIMs 35-60 and owners and between owners and preferred SMS-C/MNO 15,20,25. Profiles are transmitted to the SIMs 72,77,78,79,82 via the SIM owners preferred SMS-C. The bindings may rules/algorithms for SMS-C selection. The selection rules may take into account profiles active on eSIM and/or load balancing. The claims generalise to security module, subscription manager and message delivery element.

Description

AN APPARATUS AND METHOD FOR MANAGING COMMUNICATION WITH SECURITY MODULES

BACKGROUND

The present technique relates to an apparatus and method for managing communication with security modules.

Security modules may be associated with devices in order to control access by those devices to network infrastructure provided by a network operator. The security module may for example be implemented by a Subscriber Identity Module (SEM), which may also be referred to as a Universal Integrated Circuit Card (IJICC). Modern security modules may be embedded or integrated within the device, and may be able to store multiple subscription profiles, where each subscription profile is associated with a network operator.

The organisation and structure of such security modules may be defined by certain Telecommunications Standards, for example by GSMA Standards, and those Standards may define the use of an access control apparatus such as a server to provide a secure path for accessing security modules. For example, in accordance with the GSMA Standards, such an access control apparatus may be referred to as a Subscription Manager Secure Routing (SM-SR) server.

Typically a plurality of security modules may be associated with such an access control apparatus, arid then other entities in the system that want to interact with those security modules will need to contact the access control apparatus in order to seek to establish communication with the relevant security module. When communicating with the security modules under its control, the access control apparatus may send commands to those security modules via an intervening message delivery element. For example, commands may be sent as SMS messages via a Short Message Service Centre (SMSC) element.

Traditionally, all of the security modules associated with such an access control apparatus would typically be owned by the same entity, and indeed that entity would also typically operate the access control apparatus used to establish a secure routing with those security modules. Thus, the owning entity can determine how commands are routed between the access control apparatus and the security modules, and thus can determine which message delivery element(s) is/are used.

However, the provision of an apparatus such an SM-SR server is very costly, due to the high levels of security and integrity that need to be achieved by that apparatus. Accordingly, it would be desirable to allow a single such access control apparatus to control access to a plurality of security modules that are not all owned by the same owning entity, so as to enable amortisation of some of the costs associated with providing such an access control apparatus. However, different owners may have relationships with different message delivery elements, and this can impact the ability to adopt the above approach.

SUMMARY

In one example arrangement, there is provided an apparatus comprising: subscription management circuitry to manage subscription profiles used by a plurality of security modules, wherein at least one security module in the plurality of security modules has a different owner to at least one other security module in the plurality of security modules; a storage to store ownership information identifying the owner of each security module in the plurality of security modules; interface circuitry to establish owner specific connections with a plurality of message delivery elements; the subscription management circuitry to communicate with a given security module in the plurality of security modules via a selected message delivery element amongst the plurality of message delivery elements; and selection circuitry to determine the selected message delivery element in dependence on the owner of the given security module as determined from the ownership information and the owner specific connections established by the interface circuitry for the owner of the given security module.

In another example arrangement, there is provided a method of managing subscription profiles used by a plurality of security modules, wherein at least one security module in the plurality of security modules has a different owner to at least one other security module in the plurality of security modules, the method comprising: arranging subscription management circuitry to communicate with a given security module in the plurality of security modules via a selected message delivery element amongst a plurality of message delivery elements with which owner specific connections are established; and determining the selected message delivery element in dependence on (i) the owner of the given security module as determined from stored ownership information identifying the owner of each security module in the plurality of security modules and (ii) owner specific connections established for the owner of the given security module.

In another example arrangement there is provided a computer readable medium comprising a computer program which, when executed on a computer, implements the above described method.

In a still further example arrangement, there is provided an apparatus comprising: subscription management means for managing subscription profiles used by a plurality of security modules, wherein at least one security module in the plurality of security modules has a different owner to at least one other security module in the plurality of security modules; storage means for storing ownership information identifying the owner of each security module in the plurality of security modules; interface means for establishing owner specific connections with a plurality of message delivery elements; the subscription management means for communicating with a given security module in the plurality of security modules via a selected message delivery element amongst the plurality of message delivery elements; and selection means for determining the selected message delivery element in dependence on the owner of the given security module as determined from the ownership information and the owner specific connections established by the interface means for the owner of the given security module.

BRIEF DESCRIPTION OF THE DRAWINGS

The present technique will be described further, by way of illustration only, with reference to examples thereof as illustrated in the accompanying drawings, in which: Figure 1 schematically illustrates a system in accordance with one example arrangement; Figure 2 is a block diagram illustrating components provided within a security module in one example arrangement; Figure 3 is a block diagram of an apparatus in accordance with one example arrangement; Figure 4 is a flow diagram illustrating the operation of the apparatus of Figure 3 in accordance with one example arrangement; Figure 5A illustrates fields provided within each entry of the ownership information storage of Figure 3 in accordance with one example arrangement; Figure 5B illustrates fields that may be provided within a registration request issued to an access control apparatus in order to seek to register a given security module with that apparatus; Figure 5C is a flow diagram illustrating steps performed by the access control apparatus upon receipt of the registration request, in accordance with one example arrangement; Figure 6 illustrates fields provided within each entry of the owner-based selection rules storage of Figure 3 in accordance with one example arrangement; and Figure 7 is a flow diagram illustrating how step 210 of Figure 4 may be implemented in one example implementation.

DESCRIPTION OF EXAMPLES

In accordance with the techniques described herein, an apparatus is provided that can be used to control access to a plurality of security modules that are not all owned by the same owner. The access control apparatus can take a variety of forms, but in accordance with the GSMA Standard, for example, such an apparatus may be implemented as an SM-SR server. Such an apparatus is used to establish a secure connection with the security modules that fall under its control, and that secure connection may be used by other entities within the system. For at least some of the communication between the SM-SR server and the security modules, the SM-SR sewer may use one or more intervening message delivery elements. For example, certain commands may be sent to the security modules from the SM-SR server using SMS messages routed via an SMSC element. Typically, the owner of the security modules may enter into agreements with providers of such SMSC elements, allowing such SMSC elements to be used to route SMS messages to the security modules belonging to that owner, and for the owner to be billed appropriately based on the SMS traffic routed via those SMSC elements.

In order to amortise the cost associated with providing such an access control apparatus to manage communication with the security modules, it would be desirable to provide for a "multi-tenanted-system where such an apparatus can be used to control access to a plurality of security modules, but where not all of those security modules are owned by the same owner. Within such a system, global rules could be enforced regarding the SNISCs that are to be used when routing SNIS messages between the apparatus and the security modules controlled by that apparatus. However, this could significantly impact the ability to establish such multi-tenanted systems, since it would only be possible in situations where the various owners of the security modules that are to be controlled by the apparatus are able to take a common approach as to the message delivery elements to be used for routing messages to their security modules, and the owners may wish to retain the freedom to negotiate their own commercial relationships with the message delivery element providers, with the aim of seeking the best value for money, and to retain flexibility as to which message delivery element is used in any particular instance, for example to take into account factors such as the physical location of their security modules, the current network those security modules are connected to, etc. Even if a common approach could be taken, it would still be necessary to ensure each owner was billed appropriately to reflect usage of the message delivery elements for each owner's security modules.

In accordance with the techniques described herein, a mechanism is provided that allows for flexibility as to which message delivery elements are used when communicating with the various security modules that fall under control of the apparatus, with the apparatus being able to select an appropriate message delivery element to use in any particular instance taking into account the owner of the security module to be communicated with.

In particular, in one example implementation, the apparatus is provided with subscription management circuitry for managing subscription profiles used by a plurality of security modules, wherein at least one security module in the plurality of security modules has a different owner to at least one other security module in the plurality of security modules. There are a number of subscription profile management functions that the subscription management circuitry may perform, for example to change a currently enabled subscription profile on a given security module, to delete a particular subscription profile from a given security module, to download a new subscription profile to a given security module, etc. During such subscription profile management task, the subscription management circuitry will need to communicate with the given security module, and this may invoke sending one or more commands/messages via a selected message delivery element for routing to the given security module.

In accordance with the techniques described herein, the apparatus has storage to store ownership information identifying the owner of each security module in the plurality of security modules falling under the control of the apparatus, and interface circuitry to establish owner specific connections with a plurality of message delivery elements. Further, selection circuitry is provided to determine a selected message delivery element to be used when communicating with a given security module taking into account the owner of the given security module as determined from the ownership information and the owner specific connections established by the interface circuitry for the owner of the given security module.

Hence, with reference to the storage, the selection circuitry can determine who the owner is of the given security module that the subscription management circuitry currently wishes to communicate with. It can then determine which owner specific connections have been established by the interface circuitry for that owner. This information can then be used to constrain which message delivery element is used when communicating with the given security module.

For instance, the selection circuitry can be used to ensure that the selected message delivery element is a message delivery element for which an owner specific connection has been established, taking into account the owner of the given security module that is to be communicated with. Further, in instances where the owner specific connections available for a particular owner mean that there is more than one message delivery element that can be selected, then the selection circuitry may be arranged to employ selection rules to determine the selected message delivery element, with the selection rules being configurable for each owner. Thus, in situations where more than one message delivery element could be selected, the manner in which a particular one of those message delivery elements is selected can be varied dependent on the owner, hence providing a great deal of flexibility as to the way in which a message delivery element is selected by the apparatus, for example to take into account owner preference.

Further, in situations where there may be more than one owner specific connection between the apparatus and the selected message delivery element, the selection circuitry can be further arranged to identify the particular owner specific connection that is to be used. There can be a number of reasons why more than one owner specific connection might be established with a particular message delivery element for the same owner. For example, one or both of the apparatus and the message delivery element may run multiple instances of the relevant communication software, for example having software running on different virtual machines in a hardware stack, and each software instance may create its own owner specific connection. The use of multiple software instances can assist in providing redundancy, and also providing for load balancing functionality. Hence, in instances where the selection circuitry chooses a particular message delivery element, and it is determined that for the owner in question there is more than one owner specific connection to that chosen message delivery element, then the selection circuitry may further identify the particular owner specific connection to be used.

In one example arrangement, the selection circuitry is arranged, when the subscription management circuitry is communicating with the given security module, to prevent use of an owner specific connection associated with an owner other than the owner of the given security module. In particular, individual owners may enter into their own billing arrangements with the message delivery element provider. The message delivery element provider may take a variety of forms, but could for example be a mobile network operator, and typically an owner of one or more security modules will enter into an agreement with the mobile network operator, setting out the pricing arrangement by which the owner will be billed for messages routed by that mobile network operator's message delivery element. In such instances, it is important to ensure that, when determining the appropriate message delivery element to be used when communicating with any particular security module, an owner specific connection is not used that is associated with a different owner, as in that instance one owner may end up being billed for traffic relating to a different owner. However, through the maintenance of the ownership information within the apparatus identifying the owner of each security module, the apparatus can ensure that only the owner specific connections established for that owner by the interface circuitry are used, thus ensuring that the independent billing arrangements made by the various owners with the message delivery element providers are not compromised.

As mentioned earlier, the selection circuitry can employ selection rules to determine the selected message delivery element and those selection rules may be configurable for each owner. This configurability can be achieved in a variety of ways. In one example arrangement, the selection circuitry is arranged to provide a set of selection algorithms, and at least one owner is arranged to configure the selection rules by identifying at least one selection algorithm from the set to be used to determine the selected message delivery element for communicating with that owner's security modules. Hence, an owner can control which selection algorithms are used when seeking to select a message delivery element for routing communications between a given one of its security modules arid the apparatus.

In some implementations, an owner may be constrained to select a specific selection algorithm that will be used in all instances. However, alternatively at least one owner may be arranged to configure the selection rules used to determine the selected message delivery element for communicating with that owner's security modules by defining a priority ordering amongst multiple selection algorithms in the set, such that if use of a higher priority selection algorithm fails to identify a message delivery element for which the owner has a valid owner specific connection, the selection circuitry is then arranged to use a lower priority selection algorithm in order to seek to determine the selected message delivery element. This provides enhanced flexibility by allowing multiple selection algorithms to be available to the selection circuitry when seeking to determine the appropriate message delivery element to use for communicating with a particular security module belonging to a particular owner.

Whilst the various selection algorithms may be predetermined algorithms available to all owners, such that each owner selects from a set of predetermined available selection algorithms, there is no requirement for all of the selection algorithms to be predetermined. For example, at least one selection algorithm in the set may be an owner-defined selection algorithm. This provides additional flexibility by allowing an individual owner to define its own selection algorithm(s) that are to be used when seeking to select a message delivery element for communicating with its security modules.

Furthermore, in addition to choosing one or more selection algorithms to be used by the selection circuitry, an owner may be arranged to provide data for at least one of the selection algorithms, with that data then being referenced by the selection circuitry when using the relevant selection algorithm to determine the selected message delivery element for communicating with that owner's security modules. Hence, a relatively generic selection algorithm can be defined, but with owner specific data then being provided for use when applying that selection algorithm, thus enabling the selection process to be tailored to the particular owner's requirements. Purely by way of example, one of the selection algorithms may make a selection of a message delivery element based on International Mobile Subscriber Identity (IMSI), this being a number that uniquely identifies every user of the cellular network. The owner data could then identify MIST ranges that are associated with particular message delivery elements, such that if the IIVISI of the given security module falls within a first range, then a first message delivery element will be selected, whilst if that IMSI falls within a second IMSI range, then a different message delivery element may be selected. By allowing the owner to specify the IMSI ranges, this can provide a great deal of flexibility, by controlling how the IMSI based selection algorithm operates in relation to that owner's particular security modules.

The set of selection algorithms can take a variety of forms, but in one example implementation comprise at least one selection algorithm that takes into account a currently active subscription profile on the given security module. Hence, by way of example, the set of selection algorithms may comprise a mobile network operator selection algorithm that takes into account a mobile network operator associated with the currently active subscription profile when determining the selected message delivery element. Alternatively, or in addition, the set of selection algorithms may comprise a mobile subscription selection algorithm that takes into account a mobile subscription identifier for the currently active subscription profile when determining the selected message delivery element, where different ranges of mobile subscription identifier values are associated with different message delivery elements.

Hence, the mobile network operator selection algorithm, when selected for a particular owner, may take into account which mobile network operator that particular owner's security module is using, when deciding which message delivery element to use. Hence, the choice of message delivery element may depend on whether the given security module under consideration at the current time is connected to the Vodafone network, the 02 network, etc. However, if the mobile subscription selection algorithm is instead chosen for a particular owner, then this can take into account the above mentioned MST information when determining which message delivery element to use. In particular, the IN/ISI information will vary depending on the currently active subscription profile, and hence when the currently active subscription profile on the given security module is changed, then the MST information will also change, and hence may result in a change in the message delivery element that is selected for use when communicating between the apparatus and the given security module.

As another example of a selection algorithm that can be used, the set of selection algorithms may comprise a load balancing selection algorithm to seek to balance the load over multiple owner specific connections to the selected message delivery element when those multiple owner specific connections are associated with the owner of the given security module. It should be noted that multiple selection algorithms can be employed when selecting the particular message delivery element. For example, a primary algorithm may be chosen to determine a particular message delivery element, and then an algorithm such as the load balancing selection algorithm can be used in instances where more than one owner specific connection exists with the selected message delivery element, in order to decide which particular owner specific connection to use.

Whilst above some selection algorithms that may be used have been discussed, it will be appreciated that they provide a non-exhaustive list, and any suitable selection algorithm can be used. Purely as another example, subscription profiles can include additional information, such as a profile type. A profile type effectively forms an optional marker field held against profiles. Whilst the values in that field are arbitrary, some typical usages allow identification of profiles either by home country, included applets, roaming arrangements, etc. If desired, a selection algorithm could be chosen that takes into account the profile type of the currently enabled subscription profile when deciding which message delivery element to select.

There are a number of ways in which the apparatus can establish the owner specific connections with the message delivery elements. As mentioned earlier, each owner will typically enter into its own commercial arrangements with the message delivery element provider, and as part of that process will be provided with login credentials used to establish connections with the relevant message delivery element. In accordance with one example implementation, each owner is arranged to provide login credentials for one or more message delivery elements that the owner has authority to use for sending messages to that owner's security modules, and the interface circuitry is arranged to use those login credentials to establish the owner specific connections for that owner. Hence, the apparatus can use the login credential information provided by the various owners in order to establish the owner specific connections, and can keep track of which connections are provided for which owner so that the message traffic issued between the apparatus and the security modules is constrained to use connections established for the relevant owner.

There are a number of ways in which the ownership information can be maintained by the apparatus. However, in one example implementation, when a new security module is allocated to the apparatus to form one of the plurality of security modules, the apparatus is responsive to a registration request identifying the new security module and providing an owner indication, to update the ownership information in the storage to identify the owner of the new security module. Hence, at the time a new security module is registered with the apparatus, its owner can be identified in the registration request, such that the owner can be identified in the ownership information maintained by the apparatus.

In order to increase flexibility, at least one security module owning party may be allocated multiple owner indications to allow different message delivery element selection rules to be applied for different subsets of the security modules owned by that particular owning party.

Hence, by way of example, in such a situation the registration request may provide, as the owner indication, an owner identifier for a security module owning party and a type indication associated with a given subset of security modules owned by that security module owning party. The ownership information can then be maintained for each combination of owner identifier and type indication provided for that owner identifier.

In one example implementation, the registration request may further provide at least one additional attribute used by the selection circuitry when determining the selected message delivery element to be used when communicating with that new security module This provides further flexibility, by enabling a particular owner to selectively override the default selection algorithm used to choose the message delivery element, and instead to provide specific additional information that is used when selecting the message delivery element for the particular security module being registered. As a particular example, an additional properties selection algorithm can be defined, and when one or more additional attributes are specified in the registration request when registering a particular security module, then those additional attributes will be used to apply the additional properties selection algorithm when seeking to select a message delivery element for communicating with that security module.

The registration request can be issued via a variety of entities within the system, 10 but in one example is issued by a manufacturer of the given security module.

The security modules can take a variety of forms. Whilst traditionally a security module may be a separate smartcard inserted into a device, which may for example provide a single predetermined subscription profile, it is becoming more common for such a security module to be embedded within the device at manufacture, and to be capable of hosting multiple profiles in associated security domains. For example, the security module may be an embedded UICC (eUICC) where the UICC is provided as a chip mounted on the circuit board of a device, or an integrated UICC (iUICC) incorporated as one of the modules within a System-on-Chip (SoC).

Particular examples will now be described with reference to the Figures.

Figure 1 is a diagram schematically illustrating a system in accordance with one example implementation. An access control apparatus 10 is provided for controlling access to a plurality of security modules 35, 40, 45, 50, 55, 60 within a group 30 of security modules falling under the control of the apparatus 10. Each security module will typically be registered with the apparatus 10, and thereafter the apparatus 10 can be used to control access to each registered security module by one or more other entities within the system. For the purposes of the following description, each security module will be considered to be a Universal Integrated Circuit Card (UICC) and in particular will be considered to be an embedded UICC or an integrated UICC that is capable of storing a plurality of subscription profiles, where each subscription profile is associated with a network operator.

Such security modules are being used in a wide variety of different devices, as it becomes more and more common to connect individual devices to networks in order to facilitate reporting of information by those devices, and performance of certain management operations in respect of those devices. Hence, while such security modules may traditionally have been owned by mobile network operators, with the advent of the Internet of Things (loT), allowing the possibility for a wide variety of devices to be provided with connectivity to a network, such security modules are now being owned by a wider variety of different entities. Purely by way of example, a smart meter company may own security modules which can be located in their energy meters to report back information to the smart meter company.

In Figure 1 security modules associated with a variety of different devices are shown, such as associated with a water meter in the case of the security module 35, with a banking application in the case of the security module 40, with a vehicle in the case of the security module 45, with a camera in the case of the security module 50, with an appliance such as a kettle in the case of the security module 55, or with a health monitoring device in the case of the security module 60.

However, the relevant Telecommunications Standards controlling the use of security modules such as UICCs requires very stringent controls over those security modules, including the manner in which they are accessed. For example, the GSMA Standards define how an access control apparatus such as the apparatus 10 shown in Figure 1 should function, in accordance with the GSMA Standards such an apparatus being referred to as a Subscription Manager Secure Routing (SM-SR) apparatus or sewer. The SM-SR sewer 10 is used to establish secure connections with the various security modules registered with it via an intervening communication network. Communications between the SM-SR 10 and the security modules 30 may typically rely upon the exchange of SMS messages, and these may be passed through an intermediary Short Message Service Centre (SMSC). Multiple different SMSCs may be provided, for example SMSCs associated with different mobile network operators such as the SMSCs 15, 20, 25 shown in Figure 1. Connectivity between the SM-SR and each SMSC is performed via a connection (also referred to herein as a bind) which may be based on the Short Message Peer to Peer (SMPP) protocol.

To comply with the GSMA's SAS-SM (Security Accreditation Scheme for Subscription Management), data within an SM-SR sewer is subject to the highest standards of integrity and confidentiality. This requires the use of hardware security modules (FISMs), which are extremely expensive items of equipment. This expense can be further compounded by additional instances required to comply with service level agreements (SLAs) relating to high availability, business continuity and disaster recovery. Whilst such an SM-SR server might traditionally be under the control of a particular network operator, and used to manage connections to that network operator's UICCs, as the diversity of owners of UICCs increases, then it can become impractical for those individual owners to provide their own SM-SR server. Accordingly, it would be desirable to support a multi-tenanted system, where a single SM-SR server can be used to control access to a plurality of security modules that are not all owned by the same owning entity. The techniques described herein aim to assist in the development of such multi-tenanted systems, by supporting the ability for individual owners to control which SMSCs are used for exchanging SMS messages with their security modules.

Typically, each owner of one or more security modules may enter into agreement with an SMSC provider in order to enable SNIS messages to be routed to that owner's security modules using an SMSC of that SMSC provider. It is important that all SMS traffic to that owner's security modules are routed through the appropriate SMSC, for example to ensure that billing arrangements are handled correctly. When a security module owner enters into an agreement with an SMSC provider, it will typically be provided with login credentials that should be used when seeking to access the SMSC of that SMSC provider. In particular, these login credentials can be used to establish a connection (bind) with the SMSC, to thereby enable SMS traffic to be routed via that SMSC to and from the security modules of that owner.

In accordance with a multi-tenant system such a shown in Figure 1, a plurality of owners (also referred to herein as customers) may register their security modules with a single SM-SR, and hence in the example of Figure 1 three different customers 70, 75, 80 may register certain of their security modules with the SA/I-SR 10. As a result, when any entity needs to communicate with one of the security modules 30 registered with the SMSR 10, it will first need to contact the SNI-SR in order to seek to establish that communication. The multi-tenant SM-SR 10 can then police those accesses to ensure that only elements that are authorised to access the security modules do in fact do so, but assuming communication is authorised then SMS traffic can be exchanged between the SM-SR and a chosen security module via the intervening message delivery elements, namely an appropriate one of the SMSCs 15, 20, 25.

As discussed earlier, each customer will have obtained login credentials from the SMSC provider that it has entered into an arrangement with, and can provide those login credentials to the multi-tenant SM-SR 10, thereby enabling interface circuitry within the SM-SR 10 to establish owner specific connections (SMSC binds) with the SNISCs. Some customers may only have entered into an arrangement with a single SMSC, in which case the SMSC bind or binds established for that customer will all be in respect of the same SMSC. This is illustrated schematically in Figure 1, where one or more binds 72 are established in respect of customer 1 70 between the SNI-SR 10 and the SMSC 15.

Similarly, customer 3 80 may have an arrangement with SMSC 25 and one or more binds 82 may be established between the SM-SR 10 and the SMSC 25 for that customer. A single bind may be established for a particular owner, or alternatively multiple separate binds may be provided. For example, it may be the case that either or both of the SNI-SR 10 and the relevant SMSC run multiple instances of the communication software, for example running software on different virtual machines. This can provide redundancy and also load balancing benefits. In such a situation, a separate bind may be established for each software instance, each bind being established using the same login credentials.

However, in addition, certain customers may enter into agreements with multiple SMSCs. This is illustrated in Figure 1 by way of example with reference to customer 2 75, which it is assumed has entered into agreements with each of the SMSCs 15, 20, 25. Hence, owner specific binds 77, 78, 79 may be established for that particular customer with each of the SMSCs 15, 20, 25.

In accordance with the techniques described herein, the multiple customers that wish to share use of a single multi-tenant SM-SR 10 are not constrained to use the same SMSCs, or indeed to employ the same rules for determining which SMSC to use in any particular instance, and instead a flexible mechanism is provided that enables different customers to use different SMSCs, and also for different customers to employ different selection algorithms for determining which SMSC is to be used when communicating with a particular one of its security modules.

As shown in Figure 1, a set of selection algorithms 90 can be provided for use by a rules engine 12 running within the multi-tenant SM-SR 10 in order to determine, when communication is required with a particular security module 35, 40, 45, 50, 55, 60, which SMSC 15, 20, 25 should be used as an intermediary for handling the required SMS messages. In particular, the rules engine 12 (also referred to herein as selection circuitry) may have access to ownership information identifying, for each security module registered with it, who is the owner of that security module. Armed with information about the owner of the security module that it needs to communicate with, reference can then be made to owner-based selection rules in order to determine which selection algorithm is used to determine the appropriate SMSC 15, 20, 25 to employ when routing SMS messages between the multi-tenant SNI-SR 10 and the security module in question.

In particular, where there are multiple binds to different SNISCs for the owner of the security module in question, the selection algorithm can be applied in order to determine which SMSC should be contacted. Further, in the event that there are multiple binds available with that particular SMSC, then an algorithm can be used to determine the appropriate bind to employ, for example to assist in achieving load balancing within the system.

There are a number of ways in which the set of selection algorithms 90 can be provided. For example, an abstract selector algorithm 92 may be provided that acts as an interface detailing the functions each concrete selection algorithm must implement, for example the structure of the requests it must handle and the responses it must return.

Based on this abstract algorithm 92, a number of different concrete selection algorithms 93, 94, 95, 96, 97 may be established, and each customer may then determine which selection algorithm should be used when seeking to establish the SMSC to be employed when communicating with its security modules. By using a selection algorithm, the determination of the SMSC to use may vary dependent on the security module in question. For example, security modules all owned by the same customer may actually be deployed in different geographical locations, and be connected to different mobile networks, and such factors can be used to influence the choice of SMSC.

Further, the customers are not restricted to only using a single selection algorithm, but instead can specify relative priorities of the selection algorithms. so that a high priority selection algorithm is first used to seek to establish an SMSC, and if that fails to identify an SMSC for which the customer has a valid bind, then a lower priority selection algorithm is used to determine the SMSC.

Whilst the various selection algorithms 93, 94, 95, 96, 97 may be predetermined, and each customer may merely select between the set of predetermined selection algorithms, in an alternative implementation one or more of the selection algorithms may be customer defined algorithms, allowing a great deal of flexibility as to the rules employed in respect of each customer to determine the appropriate SMSC to be used when communicating with ones of its security modules.

A number of software programming techniques can be used to develop the various selector algorithms. In accordance with one specific example implementation, an abstract factory design pattern may be used, the "abstract factory" being one of the design patterns set out in the book "Design Patterns: Elements of Reusable Object-Oriented Software-by E Gamma et al. The abstract factory design pattern provides a way to encapsulate a group of individual factories that have a common theme without specifying their concrete classes. Each of the individual selector algorithms 93, 94, 95, 96, 97 can then be considered to be concrete implementations of the abstract factory and use the generic interface of the abstract factory. Each of the concrete factories can then be viewed as providing selection algorithms for making a determination of a suitable SMSC bind based on one or more factors.

The concrete factories can hence be viewed as concrete subclasses that provide implementations of different bind selection algorithms based on varying requirements.

For example the NINOlD selector algorithm 93 may be used to select a bind based on the mobile network operator ID of the currently active profile in the given security module with which the SM-SR 10 needs to establish communication. Optionally this selector algorithm may also take into account data about the owner of the given security module, for example an eSim owner ID, so that the selected SMSC may depend on both the MNO ID and the eSim owner ID. The MST range selector algorithm 94 may select a bind based on which frvISI range the currently active profile falls within. As mentioned earlier, an IMSI is a number that uniquely identifies every user of a cellular network, and the IMSI will vary dependent on the currently active subscription profile within the security module for which the SM-SR 10 needs to establish communication.

The load balanced selector algorithm 95 may be used to provide a load balancing mechanism (for example employing a round robin technique) to select among different binds to the same SMSC. As discussed earlier, there may be multiple binds to the same SMSC for a particular customer, for example when multiple instances of the software are being deployed on one or both of the SM-SR 10 and the SMSC. In those instances, by employing the load balancing algorithm once a particular SMSC has been chosen, this can spread the load across the various binds established for the customer in question.

As will be discussed in more detail later when a new customer signs up to use the multi-tenant SM-SR 10, it can provide information about which selector algorithm it wishes to use when determining an SMSC to be used for communicating with its security modules, and can also provide the data that will be used by the relevant selection algorithm. For example, considering the IMSI range selector algorithm 94, that data may specify which MST ranges are to be associated with which SIVISCs. Alternatively, or in addition, such information may be provided as part of a registration request issued by the customer when registering a particular security module with the multi-tenant SM-SR 10. Further, such registration requests can be used to provide additional properties in an additional properties field of the registration request, and that additional properties information may identify that an additional properties selector algorithm 96 should be used when seeking to determine an SMSC to employ for communications with the associated security module. Such information can be used to override the default selector algorithm used for the customer, and hence could for example enforce that a particular SMSC is used when communicating with a particular security module irrespective of the general selector algorithm that would otherwise be employed for the customer.

Figure 2 is a diagram schematically illustrating a security module 100, in this example an eUICC. The security module 100 includes profile storage 102 in which to store a plurality of subscription profiles. In particular, security domains 105, 110, 115 could be established within the profile storage 102, where each security domain is used to host an associated subscription profile. The subscription profile of an enabled security domain within the security module is then used to control access via that security module to network infrastructure provided by the network operator with which the subscription profile of that enabled security domain is associated. Profiles can be downloaded to the security module 100 after the security module has been deployed. In particular, a profile download request may be received by the SM-SR server 10 from a profile download server, and at this point this may require a new security domain to be established within the profile storage 102, whereafter the subscription profile is downloaded into that security domain. In accordance with the GSMA terminology, such a security domain may be referred to as an Issuer Security Domain Profile (ISD-P).

As shown in Figure 2, an Issuer Security Domain Root (ISD-R) element 125 can be provided to communicate with the SM-SR 10 in order to establish the secure communication used when downloading a profile to the device. The ISD-R element will hence for example create a new ISD-P when a new profile is to be downloaded. The ECASD (eUICC Controlling Authority Security Domain) element 120 is arranged to establish a trust route with the relevant profile download server during the download process, and can for example be used to authenticate profiles being downloaded to the security module 100. One of its functions is to establish key sets during the profile download process. As mentioned earlier, communication between the SM-SR and a security module may rely upon the exchange of SMS messages. Such SMS messages may be used by themselves to implement simple commands, such as to switch to a different profile already stored within the profile storage 102, or to delete a profile. If more complex functions are needed, for example to download a new profile onto the security module 100, then an SMS message may be used as an initial command, and could for example be used to instruct the security module to open a TLS (Transport Layer Security) session via which the new profile can then be downloaded.

Figure 3 is a block diagram illustrating components provided within the multi-tenant SM-SR 10 of Figure 1 in accordance with one example implementation. The subscription management circuitry 150 is used to manage subscription profiles used by the various security modules 30 falling under control of the multi-tenant SM-SR. Interface circuitry 155 is used to establish owner specific binds with the various SMSC elements 15, 20, 25. As discussed earlier, each customer will provide the login credentials it has for the one or more SMSCs that it is entitled to use, and those login credentials can be used by the interface circuitry 155 to establish the relevant binds between the SM-SR 10 and the SMSCs 15, 20, 25, each bind being established for a particular customer. The individual binds may in principle be unidirectional, but alternatively may be bidirectional binds allowing communication in either direction between the SM-SR 10 and the SMSC. For the purposes of Figure 3, a single selected security module 160 will be considered, and it is assumed that via the interface to the internet 190, the subscription management circuitry 150 has received a request from a external element in the system to communicate with that selected security module 160. For example, a mobile network operator or a service provider may send a request via the interface 190 to request the subscription management circuitry 150 to switch the enabled profile on the selected security module 160, to delete an existing profile, or a profile download request may be received seeking to install a new subscription profile on the selected security module 160.

In the example shown in Figure 3, it is assumed that there are multiple available binds for the owner of the selected security module 160, including two binds to the SMSC 15, a bind to the SMSC 20 and a bind to the SMSC 25. Hence, in principle, any of the SNISCs 15, 20, 25 may be used to establish SATS communication with the selected security module 160 via the interface circuitry 155. Prior to the request coming in, the interface circuitry 155 will typically have already established the various binds with the SMSC elements 15, 20, 25, using the login credentials provided by the owner of the selected security module 160. Typically such binds can be viewed as long term connections, and a heartbeat mechanism can for example be used to keep the binds active so that they are available to use as and when required When the subscription management circuitry 150 determines that it needs to send an SATS communication to the selected security module 160, it references the selection circuitry 165 in order to seek to identify which SMSC should be used. The selection circuitry makes reference to an ownership information database 170, this providing an indication of the owner of each security module within the set of security modules 30 managed by the multi-tenant SM-SR 10 Based on the owner information, the selection circuitry can then reference the owner-based selection rules storage 175 in order to identify which selection algorithm should be used by the selection circuitry in order to determine the SMSC. The selection circuitry may also obtain from the owner-based selection rules database 175 any owner defined data for use with the selection algorithm, for example in INISI range information in situations where the IMS1 range selection algorithm is being used. The selection circuitry can then reference the selection algorithm storage 180 in order to retrieve the required software to run to implement the specified selection algorithm, and once a particular SMSC and associated bind has been determined, that information can be returned to the subscription management circuitry 150. The selection circuitry may be implemented by dedicated hardware, or alternatively may be implemented by software executing on a general purpose computer.

The subscription management circuitry 150 can then communicate with the interface circuitry 155 to identify the message that it wishes to send, and the particular SMSC and associated bind to be used. In some instances, the bind will be implicit based on the indicated SMSC. In particular, for the specific example shown in Figure 3, if either SMSC 20 or SMSC 25 is selected, then there is a single active bind for the owner that is used. However, if SMSC 15 is selected, then as shown in Figure 3 there may be multiple binds available, and the selection circuitry can also be used to identify the particular bind to use. For example, as mentioned earlier, the load balanced selector algorithm 95 can be employed to identify which of the multiple binds to use for the current communi cation.

There are a number of ways in which the information maintained within the owner-based selection rules storage 175 may be populated. For example, at the time a new customer is enrolled to use the multi-tenant SM-SR 10, that owner may provide details as to the selection algorithm to be used, and any owner defined data for use with that selection algorithm. As mentioned earlier, rather than just choosing a single selection algorithm, relative priorities can be associated with multiple selection algorithms, hence providing for more complex mechanisms to be employed when choosing a particular SMSC. For instance, if the highest priority selector algorithm fails to identify an SMSC for which the specific owner has a valid connection, then a lower priority selection algorithm may be employed, and this process can continue until an SMSC has been selected for which the owner has a valid bind. The information within the owner-based selection rule storage 175 may be populated manually, for example by an onboarding/support team associated with the provider of the multi-tenant SM-SR.

However, alternatively, or in addition, an application programming interface (API) may be provided to allow this information to be updated dynamically by the customers as and when required.

As will be discussed in more detail later, at the time a customer registers a particular security module with the multi-tenant SM-SR 10, a registration request may be issued to the multi-tenant SIM-SR, for example via the internet, where it will be received by the interface 190. That registration request information can then be processed internally within the multi-tenant SM-SR in order to update the ownership information database 170, in particular to identify the owner of the security module being registered, and to capture any ancillary information provided in the registration request. This process will be discussed in more detail later with reference to Figures 5A to 5C.

By providing a multi-tenant SM-SR 10 such as shown in Figure 3, then the cost associated with providing an SM-SR can be amortised across multiple customers. For example, elements with the SM-SR 10 such as the hardware security module (HSM) 185 are extremely expensive items of equipment, and hence it is highly beneficial for the costs associated with provision of such equipment to be amortised across multiple customers.

Figure 4 is a flow diagram illustrating the operation of the circuitry of Figure 3 in one example implementation. At step 200 the subscription management circuitry 150 identifies a selected security module that it wishes to communicate with. As discussed earlier, this will typically occur in response to receipt via the interface 190 of a request from an external entity to establish communication with a selected security module.

At step 205, the selection circuitry determines the owner of that selected security module from the stored ownership information in the storage 170. Then, at step 210, based on the determined owner, the selection circuitry determines the selection rules to apply in order to identify the SMSC and associated bind to be used when communicating with the selected security module. As discussed earlier, it may at this point determine that one specific algorithm should be used as selected by the owner, or alternatively may apply a sequence of selection algorithms in a priority order set by the owner until an SMSC is determined for which the owner has a valid bind. As another example, additional information stored in the ownership information storage for the selected security module may cause the default selection rules for the owner to be overridden, and instead for the additional properties selection algorithm 96 to be employed in order to identify the SMSC to be used. As a specific example, the additional information stored in the ownership information storage for the particular security module may identify a particular SMSC that is to be used.

At step 215, the determined selection rules are applied in order to identify the SMSC to use, and the bind in situations where the owner has more than one valid bind for that selected SMSC. Thereafter, at step 220, the subscription management circuitry 150 issues a message to the selected security module via the interface 155 and the selected SMSC/bind.

k some instances, it may be possible to cache information about the SMSC and associated bind selected for a particular security module using the process of Figure 4, so that that information can be reused when it is next determined necessary to communicate with that particular security module. This could improve efficiency. However, in some instances it may not be appropriate to cache such information, as the circumstances may have changed between different points in time where communication is required with the same security module, for example the active subscription profile may have changed, or the security module may have moved into a different jurisdiction.

Figure 5A illustrates fields that may be provided with each entry of the ownership information storage 170. Each entry may include a security module identification field 255 to identify the security module to which that entry relates, and may also include an owner indication field 260 to identify the owner of that security module. As mentioned earlier, a particular owner may have more than one owner indication, so as to allow SMSC selection rules to be varied between different subsets of security modules owned by that owner. Hence, the owner indication may include both an owner identifier for a security module owning party and a type indication associated with a given subset of security modules owned by that security module owning party.

An additional information field 265 can be used to provide any additional information provided for the security module, for example at the time the security module was registered with the SM-SR 10. As discussed earlier, this may for example provide information to be used if the additional properties selection algorithm is to be employed when determining the SMSC.

Figure 5B schematically illustrates fields that may be provided within a registration request 300, which in one example may be implemented by adding further information to a RegisterEis call from an EUM (eU1CC manufacturer) to the SM-SR sewer 10. As shown in Figure 5B, a request 300 will include a field 305 identifying a security module ED for the security module that is being registered. One or more fields 3 to will then provide certain metadata such as free memory, bootstrap profile details, etc. Symmetric keys can then be specified within the field 315, which are used to enable a secure channel to be established between the SM-SR and the security module. In particular, the security module will hold those keys, and those keys will also be registered with the FISM 185 within the SM-SR server 10 as part of the registration process.

An additional properties field 320 will also be provided, and can be used to hold an owner ID, and optionally type information used to encode the owner indication, i.e. identify the owner of the security module being registered. It can also optionally provide additional information if the additional property selection algorithm is to be used, for example an indication of a particular SMSC that is to be employed when contacting the particular security module to which the registration request relates.

Figure.5C is a flow diagram illustrating a process performed by the SM-SR server 10 upon receipt of such a registration request. In particular, once a registration request is received at step 350, then the details of the security module are stored within the SM-SR server. These will for example include the metadata discussed earlier with reference to the field 310. The 1-ISM will also be updated to store the symmetric keys at step 360. However, in addition to these two standard steps 355 and 360 associated with the registration request, at step 365 an entry is also made in the ownership information storage 170 to identify the security module ID and the associated owner indication (which as discussed earlier will include at least an owner ID and may optionally include type information). Additional information can also be captured within the entry if that additional information is provided within the registration request, for example if the additional properties selection algorithm is to be used. Accordingly, with reference to Figure 5A, it will be seen that a row in the table 170 is populated at step 365 to identify the security module being registered, and the associated information required within the fields 260, 265 of that entry.

Figure 6 schematically illustrates entries that may be provided within the owner-based selection rules storage 175 in accordance with one example implementation. A first field 405 is used to capture an owner indication, and then a field 410 is used to identify the selection rules applicable to that owner indication. This can hence indicate which selection algorithm or selection algorithms are to be used for the particular owner identified by the owner indication. As discussed earlier, this information may also include relative priority information relating to multiple algorithms if more than one selection algorithm is selected by the owner. Furthermore, the owner may provide owner defined data for use with the selection algorithm or selection algorithms identified in field 410, and this owner defined data can be captured within the field 415.

The data populated within each entry of the owner-based selection rules storage 175 can be populated in a variety of ways. For example, it could be initially populated at the time the customer is signed up and onboarded to use the multi-tenant SM-SR 10.

However, support may also be provided for in-life updates, and for example application programming interfaces (APIs) may be provided to allow customers to manage this information autonomously.

Figure 7 is a flow diagram illustrating how step 210 of Figure 4 may be implemented in one example. At step 450, the selection circuitry 165 determines if additional information is provided in the field 265 of the entry of the ownership information storage 170 provided for the selected security module. If so, then at step 460 the additional properties selection algorithm 96 may be used to determine the SMSC and associated bind to be used, using the additional information provided within the field 265.

However, if the additional information field 265 is not populated, then the process proceeds to step 455 where a lookup is performed in the owner-based selection rules storage 175 using the owner indication information obtained from the entry in the ownership information storage 170 for the security module in question, and the selection rules information and owner defined data provided within the fields 410, 415 of the identified entry are then used to apply the required selection algorithm or selection algorithms in order to determine the appropriate SMSC and bind to be used.

Through use of the techniques described herein, customers of an SM-SR can configure it to use different SMSCs for exchanging SMS messages with their eSIMs, depending on configurable rules expressed in a pluggable rules engine. It further facilitates the operator of a multi-tenanted SM-SR to segregate SMS traffic along distinct binds for different customers. Customers of an SM-SR will therefore be able to use the most economical or reliable SMSCs depending on prevailing circumstances. Operators of an SMSC can also ensure that SMS charges are directed appropriately, since the SMSR can be constrained to only allow binds applicable to particular owners to be used when communicating with the security modules of that owner.

In the present application, the words "configured to..." are used to mean that an element of an apparatus has a configuration able to carry out the defined operation.

In this context, a "configuration means an arrangement or manner of interconnection of hardware or software For example, the apparatus may have dedicated hardware which provides the defined operation, or a processor or other processing device may be programmed to perform the function. "Configured to-does not imply that the apparatus element needs to be changed in any way in order to provide the defined operation.

Although illustrative embodiments of the invention have been described in detail herein with reference to the accompanying drawings, it is to be understood that the invention is not limited to those precise embodiments, and that various changes, additions and modifications can be effected therein by one skilled in the art without departing from the scope and spirit of the invention as defined by the appended claims. For example, various combinations of the features of the dependent claims could be made with the features of the independent claims without departing from the scope of the present invention.

Claims

CLAIMS1. An apparatus comprising: subscription management circuitry to manage subscription profiles used by a plurality of security modules, wherein at least one security module in the plurality of security modules has a different owner to at least one other security module in the plurality of security modules; a storage to store ownership information identifying the owner of each security module in the plurality of security modules; interface circuitry to establish owner specific connections with a plurality of message delivery elements; the subscription management circuitry to communicate with a given security module in the plurality of security modules via a selected message delivery element amongst the plurality of message delivery elements; and selection circuitry to determine the selected message delivery element in dependence on the owner of the given security module as determined from the ownership information and the owner specific connections established by the interface circuitry for the owner of the given security module.
2. An apparatus as claimed in Claim 1, wherein the selection circuitry is further arranged to identify an owner specific connection to be used to communicate to the selected message delivery element.
3. An apparatus as claimed in Claim 2, wherein the selection circuitry is arranged, when the subscription management circuitry is communicating with the given security module, to prevent use of an owner specific connection associated with an owner other than the owner of the given security module.
4 An apparatus as claimed in any preceding claim, wherein: the selection circuitry is arranged to employ selection rules to determine the selected message delivery element, wherein the selection rules are configurable for each owner.
5. An apparatus as claimed in Claim 4, wherein the selection circuitry is arranged to provide a set of selection algorithms, and at least one owner is arranged to configure the selection rules by identifying at least one selection algorithm from the set to be used to determine the selected message delivery element for communicating with that owner's security modules.
6 An apparatus as claimed in Claim 5, wherein at least one owner is arranged to configure the selection rules used to determine the selected message delivery element for communicating with that owner's security modules by defining a priority ordering amongst multiple selection algorithms in the set, such that if use of a higher priority selection algorithm fails to identify a message delivery element for which the owner has a valid owner specific connection, the selection circuitry is then arranged to use a lower priority selection algorithm in order to seek to determine the selected message delivery element.
7. An apparatus as claimed in Claim 5 or Claim 6, wherein at least one selection algorithm in the set is an owner-defined selection algorithm.
8 An apparatus as claimed in any of claims 5 to 7, wherein at least one owner is arranged to provide data for at least one selection algorithm that is referenced by the selection circuitry when using that at least one selection algorithm to determine the selected message delivery element for communicating with that owner's security modules.
9. An apparatus as claimed in any of claims 5 to 8, wherein said set of selection algorithms comprise at least one selection algorithm that takes into account a currently active subscription profile on the given security module
10. An apparatus as claimed in Claim 9, wherein: said set of selection algorithms comprise at least one of: a mobile network operator selection algorithm that takes into account a mobile network operator associated with the currently active subscription profile when determining the selected message delivery element; and a mobile subscription selection algorithm that takes into account a mobile subscription identifier for the currently active subscription profile when determining the selected message delivery element, where different ranges of mobile subscription identifier values are associated with different message delivery elements.
11 An apparatus as claimed in any of claims 5 to 10, wherein said set of selection algorithms comprise a load balancing selection algorithm to seek to balance the load over multiple owner specific connections to the selected message delivery element when those multiple owner specific connections are associated with the owner of the given security module.
12. An apparatus as claimed in any preceding claim, wherein each owner is arranged to provide login credentials for one or more message delivery elements that the owner has authority to use for sending messages to that owner's security modules, and the interface circuitry is arranged to use those login credentials to establish the owner specific connections for that owner.
13. An apparatus as claimed in any preceding claim, wherein when a new security module is allocated to the apparatus to form one of the plurality of security modules, the apparatus is responsive to a registration request identifying the new security module and providing an owner indication, to update the ownership information in the storage to identify the owner of the new security module.
14. An apparatus as claimed in Claim 13, wherein the registration request provides, as said owner indication, an owner identifier for a security module owning party and a type indication associated with a given subset of security modules owned by that security 30 module owning party.
15. An apparatus as claimed in Claim 13 or Claim 14, wherein the registration request further provides at least one additional attribute used by the selection circuitry when determining the selected message delivery element to be used when communicating with that new security module.
16. An apparatus as claimed in any of claims 13 to 15, wherein the registration request is issued by a manufacturer of the given security module.
17. An apparatus as claimed in any preceding claim, wherein each security module is one of an embedded universal integrated-circuit card (eUICC) and an integrated UICC (iUICC) capable of storing a plurality of subscription profiles.
18. A method of managing subscription profiles used by a plurality of security modules, wherein at least one security module in the plurality of security modules has a different owner to at least one other security module in the plurality of security modules, the method comprising: arranging subscription management circuitry to communicate with a given security module in the plurality of security modules via a selected message delivery element amongst a plurality of message delivery elements with which owner specific connections are established; and determining the selected message delivery element in dependence on (i) the owner of the given security module as determined from stored ownership information identifying the owner of each security module in the plurality of security modules and (ii) owner specific connections established for the owner of the given security module.
19. A computer readable medium comprising a computer program which, when executed on a computer, implements the method of claim 18.
20. An apparatus comprising: subscription management means for managing subscription profiles used by a plurality of security modules, wherein at least one security module in the plurality of 3 1 security modules has a different owner to at least one other security module in the plurality of security modules, storage means for storing ownership information identifying the owner of each security module in the plurality of security modules; interface means for establishing owner specific connections with a plurality of message delivery elements; the subscription management means for communicating with a given security module in the plurality of security modules via a selected message delivery element amongst the plurality of message delivery elements; and selection means for determining the selected message delivery element in dependence on the owner of the given security module as determined from the ownership information and the owner specific connections established by the interface means for the owner of the given security module.