WO2017077339A1

WO2017077339A1 - Device configuration

Info

Publication number: WO2017077339A1
Application number: PCT/GB2016/053467
Authority: WO
Inventors: Kareem Mohamed Yousri Ebrahim Ezzat HANNO
Original assignee: Vodafone Ip Licensing Limited
Priority date: 2015-11-06
Filing date: 2016-11-07
Publication date: 2017-05-11
Also published as: GB201519638D0; GB2544099A

Abstract

Method and system configuring a device, wherein the device has a subscriber identity transformable from a first subscriber module identifier to a second subscriber module identifier, the method comprising the steps of communicating with the device connected to a subscriber network. Determining a set of device parameters including at least the subscriber network identity. Matching the device parameters with a stored set of parameters associated with a group of subscriber module identifiers, wherein the stored set of parameters includes at least the subscriber network identifier. Providing the device with a second subscriber module identifier from the group of subscriber module identifiers associated with the matched stored set of parameters.

Description

Device Configuration

Field of the Invention The present invention relates to a method and system for configuring new devices and mobile devices, in particular, when they initially subscribe to a subscriber network.

Background of the Invention

Consumer Device Manufacturers or Original Equipment Manufacturers (OEMs) who produced devices that require mobile connectivity would like to make it easier for their customers to connect to a network (e.g. the internet) shortly after acquiring the device. For mobile devices this requires a SIM. OEMs may distribute their devices to many different countries. One way of providing their customers with a simple "out of the box" experience is to ship devices with a traditional SIM that will immediately work in the end user's country. This requires purchasing SIMs from different companies (OpCos) specific to each country or region and so requires a prediction of how many devices will be sold in each country. This prediction can be difficult because the reaction of the market to each device may be different, especially in light of alternative options provided by competitors.

Additionally, devices may be re-shipped between countries and so the devices may contain a SIM that is not suitable for the eventual country. As a result, re-shipping devices to another country may lead to SIMs that don't work (and can result in a very negative customer experience) or require devices to be shipped back to a factory to unpack the devices, remove the wrong SIM, install a correct SIM, pack the devices and then ship them to the new country. This can lead to additional costs and lost time for the OEM.

One possible solution is to provide OEMs with SIMs that can work in any country and that preferably provide data services within the same price margin of the target country as a country-specific SIM. However, this can raise a number of technical and legal challenges because of the following requirements:

There are different legal requirements for consumer registration in each country; There is a legal requirement to be able to intercept communication (legal interception);

There are different content filtering rules for consumers in each country;

The internet break out experience in each country is different;

The top-up and billing aspects of operating companies (OpCos) is different from each other so a top-up voucher from one OpCo will not work in any other OpCo; and

The customer care, SIM swap, and all legal and technical aspects for OpCos are built specifically to support the SIMs of that OpCo and any minor change in these systems will be very expensive and will take a lot of time to complete.

However, even where a customer receives a device with a SIM that will work with an OpCo in their country, this SIM may be restricted to particular cellular services such as data, voicemail, SMS and/or various tariffs. If different cellular services are required then this can also require that the SIM is swapped. This can be a particular problem if the cellular services offered by an OpCo change after the device has been manufactured and the SIM placed in the device. Furthermore, the management of SIMs itself can cause difficulties. Certain devices may require particular cellular services. For example, M2M devices such as smart meters or vehicles may not require voice services but may only require data and/or SMS. These requirements may vary by country, device or even over time (a vehicle may not initially require voice services but following a software upgrade then it may, for example). In another example, particular cellular services and configurations may vary by user for the same device and country. This can extend to the choice of options or tariffs available or that the user may choose. Again, this can require SIMs to be changed.

Whilst swapping SIMs can cause difficulties, the increase in use of embedded SIMs or eUICCs can cause even greater problems as there is no possibility to remove the SIM after manufacture.

Therefore, there is required a method and system that overcomes these problems. Summary of the Invention

Against this background there is provided a method and system that allow products or devices (e.g. tablets, e-readers, laptop computers, vehicle communication systems, home automation systems, etc.) that require network connectivity (e.g. to a subscriber network or internet connectivity over a cellular network) to be delivered to a customer together with a SIM or other subscriber module and configured more conveniently without requiring the SIM or other subscriber module to be swapped or changed. Devices have a subscriber identity that can switch or transform from an initial identity to a final identity. Therefore, they may use an embedded or removable single subscriber module with a transformable identity or identifier. When the end user powers the device for the first time (or powers on or connects a further time before subscriber identity transformation, for example) then it connects to a local subscriber network (e.g. a local cellular network). As the subscriber identity has not yet transformed then this initial connection may be a roaming connection, for example (the initial subscriber module identifier may include a subscriber network identifier different to local subscriber network that the SIM is in communication with).

The user may have previously connected but the process may not have completed for some reason. Therefore, the process may restart from where it left off. For example, the SIM may still have its initial identity (not yet transformed).

Upon initial connection (or reconnection before the process completes and/or with the SIM having its initial identity) the device may communicate with a server or system, typically outside of the subscriber network or device manufacturer. This communication may provide parameters or information about the device, the user, and/or the particular subscriber network identity (e.g. a particular OpCo). This information may be described as device parameters and may encompass these specific items or any other information that describes the device, the user of the device, device manufacturer, device supplier, the subscriber, how and where the device is used or more generally device and/or user parameters. These parameters may be static or dynamic and may be stored on the device permanently or temporarily, or transmitted using the device or otherwise defined. The device is then provided with a subscriber identity for the subscriber module (e.g. SIM) to transform to based on the provided parameters. The device type may be derived from its unique identifier (e.g. IMEI), which may fall within a range of identifiers associated with a particular type. Various subscriber identities (or ranges of identities) may be pre-allocated with their own parameters and properties. The device parameters are matched against the subscriber identity parameters so that the device receives a subscriber identity with particular properties specific to that device and/or user selection. For example, the system or server may store many different groups of subscriber identities. Each group may be assigned or associated with a particular device type, OpCo, physical SIM identifier within the device, cellular service, country or other parameter received from the device. The system can then ensure that only a subscriber identity with appropriate properties is sent to each device. The properties may include particular cellular services that are available. This may include any one or more of voice, SMS, data, tariff or tariff type. For example, a user may only require data for their device. Therefore, all devices of this type will only be sent subscriber identities to transform to that provide data and not voice or SMS. In another example, a device may communicate with a subscriber network that only works with a particular prepay voucher. Therefore, the device may be sent a subscriber identity that includes a property that it may accept credit from that type of prepay voucher. In another example, the user of a device may select a particular tariff or tariff type when they initially use their device. Therefore, a subscriber identity that comes from a group that operates according to the selected tariff or tariff type is sent to the device before transformation.

This system and method allows device parameters (e.g. device type and/or location details) to be matched for multiple operating countries at the same time and within a single system. In other words, this system and method provides a global framework for matching device parameters, including where the device is located, for multiple network operators and operating companies, at the same time or within a single system. According to a first aspect there is provided a method for configuring a device, wherein the device has a subscriber identity transformable from a first subscriber module identifier to a second subscriber module identifier, the method comprising the steps of: communicating with the device connected to a subscriber network;

determining a set of device parameters including at least the subscriber network identity;

matching the device parameters with a stored set of parameters associated with a group of subscriber module identifiers, wherein the stored set of parameters includes at least the subscriber network identifier; and

providing the device with a second subscriber module identifier from the group of subscriber module identifiers associated with the matched stored set of parameters. Therefore, the subscriber module and so configuration of the device can be tailored for a particular device type, user selection (e.g. cellular service including tariff selection), network where the device will operate, and/or country of operation. This can aid usability of the device and simplify the set-up procedure. This can be further beneficial before subscriber identity transformation as the registration procedure may operate whilst the device is effectively roaming and a simplified set-up will require less data or time on a roaming network. Furthermore, the supplier of the device can help ensure that each user will receive a device that is ready to use without requiring the further step of adding a subscriber module or SIM without needing to add particular SIMs to each device or group of devices at manufacture.

Preferably, the method may further comprise the step of initiating transformation of the subscriber identity of the device from the first subscriber module identifier to the provided second subscriber module identifier. The enables the device to make use of particular cellular services (e.g. tariffs) that can be varied for different subscriber identities. Groups of or even individual subscriber identities (second identifiers) can be associated with and provide different cellular services.

Advantageously, the method may further comprise the step of determining a device type of the device, wherein the set of device parameters and the matched stored set of parameters associated with the group of subscriber module identifiers further include the device type. In other words, groups of subscriber module identifiers may be specific to certain device types. Therefore, the requirements of each device may be accommodated more flexibly. This may be beneficial should device requirements changes due to software updates, for example. Again, this will reduce the need to physically change SIMs under these circumstances.

Optionally, the device type may be determined by: receiving a device identifier; and determining that the received device identifier corresponds with a group of device identifies associated with a predetermined device type. Devices may have different identifiers. In one example, the identifier may be its IMEI. Devices may be

manufactured to have an IMEI from within a range of IMEI. Another device type may have a different range of IMEI. The system may be configured to have access to these ranges and corresponding device types. The stored parameters of subscriber modules to be sent out may include one or more device type and/or range of IMEI, for example. Optionally, subsets of the group of subscriber module identifiers are associated with different cellular services provided by the subscriber network, the method further comprising the step of:

receiving from a user of the device an indication of a selected cellular service, wherein the provided second subscriber module identifier is within a subset of the group of subscriber module identifiers associated with the selected cellular service. The stored parameters may include particular cellular services to facilitate a match based at least in part of the user's response or selection.

Optionally, the indication of the cellular service may be a tariff selected by the user of the device. Therefore, subscriber identities may be pre-provisioned with a particular tariff rather than having to use other account management infrastructure. The user of the device can therefore enjoy more freedom to select a particular tariff. For example, the SIM does not need to be fixed to either a prepay or monthly contract service. Instead, the device receives a subscriber identity preconfigured to an appropriate tariff or tariff type.

Optionally, the method may further comprise the step of providing the device with a web landing page specific to the set of device parameters, wherein the indication of the selected cellular service is received using the web landing page. This may be one way in which the user selects a particular cellular service or services. The web landing page may be loaded when the device powers on in its initial or first subscriber identity. Optionally, the indication of the selected cellular service may be received from an application programming interface, API, call made by the device. This may be a further way in which the user selects a particular cellular service or services.

Advantageously, the method may further comprise the step of determining a first subscriber module identifier of the device, wherein the set of device parameters includes the first subscriber module identifier of the device, the matched stored set of parameters associated with the group of subscriber module identifiers further include data indicating a group of first subscriber module identifiers, and the matching step further includes determining that the first subscriber module identifier of the device is within the group of first subscriber module identifiers. In other words, the second identifier sent to the device may be based on the particular subscribe module (or group or batch of subscriber modules). This provides the device supplier or manufacturer with a way to control how devices are distributed, used and configured (by placing different subscriber modules in different groups of devices). For example, some devices may be supplied with an unlimited or high data allowance for some or all services (e.g. purchasing content).

Other devices may have more restrictions. The devices may be priced accordingly or have other conditions.

Optionally, the method may further comprise the step of processing a payment from a user of the device before providing the device with a second subscriber module identifier. This may be processed over a web page or application. Other requirements may be made instead or in addition to the payment. For example, the user may need to register or provide logon credentials. Optionally, the method may further comprise the step of confirming eligibility of the user before providing the device with a second subscriber module identifier.

According to a second aspect, there is provided a system for configuring a plurality of devices, wherein each device of the plurality of devices has a subscriber identity transformable from a first subscriber module identifier to a second subscriber module identifier, the system comprising:

a processor;

a communications interface;

a data store configured to store data describing a plurality of groups of second subscriber identities, wherein each group of second subscriber identities is associated with a stored set of parameters, the stored set of parameters including at least a subscriber network identity;

a memory storing instructions that, when executed by the processor, cause the system to:

communicate, using the communications interface, with a device connected to a subscriber network;

determine a set of device parameters including at least the subscriber network identity; match the device parameters with a stored set of parameters associated with a group of subscriber module identifiers, wherein the stored set of parameters includes at least the subscriber network identifier; and

provide the device with a second subscriber module identifier from the group of subscriber module identifiers associated with the matched stored set of parameters.

Optionally, the parameters may include device type and the stored instructions, when executed by the processor, further cause the system to determine a device type of the device, and match the parameters based on device type.

Preferably, the transformable subscriber identity is stored within a UICC within the device. This may also be an embedded UICC or SIM. Optionally, the device is any of: a computer, a cell phone, a tablet computer, an e-book reader, a machine-to-machine, M2M, device, a smartphone or a vehicle. Other devices may be used.

Preferably, the stored instructions, when executed by the processor, may further cause the system to receive data describing the plurality of groups of second subscriber identities and associated sets of parameters. In other words, the system may be configured or updated and receive new groups of subscriber identities to issue.

Preferably, the stored instructions, when executed by the processor, may further cause the system to receive instructions to edit or update the data describing the plurality of groups of second subscriber identities and/or associated sets of parameters. Other amendments may be made. The edits may include deletion, for example.

Advantageously, the stored instructions, when executed by the processor, may further cause the system to:

receive data describing the plurality of groups of second subscriber identities; receive instructions to associate sets of parameters with the plurality of groups of second subscriber identities;

receive instructions to associate an indication of a cellular service with each group of second subscriber identities; and store the data describing the plurality of groups of second subscriber identities, associated sets of parameters and associated cellular service within the data store.

According to a third aspect, there is provided a method for defining properties of a plurality of subscriber identity modules, each subscriber identity module transformable from a first subscriber identifier to a second subscriber identifier, the method comprising the steps of:

provide data describing a plurality of groups of second subscriber identities; provide instructions to associate sets of parameters with the plurality of groups of second subscriber identities; and

provide instructions to associate an indication of a cellular service with each group of second subscriber identities. Therefore, a data store of second subscriber identities may be populated and configured. Advantageously, the data and instructions may be provided as application programming interface, API, calls. The data may also be provided using other communication channels including web interfaces and client-server interactions.

The methods described above may be implemented as a computer program comprising program instructions to operate a computer. The computer program may be stored on a computer-readable medium.

The computer system may include a processor such as a central processing unit (CPU). The processor may execute logic in the form of a software program. The computer system may include a memory including volatile and non-volatile storage medium. A computer-readable medium may be included to store the logic or program instructions. The different parts of the system may be connected using a network (e.g. wireless networks and wired networks). The computer system may include one or more interfaces. The computer system may contain a suitable operating system such as UNIX, Windows (RTM) or Linux, for example.

It should be noted that any feature described above may be used with any particular aspect or embodiment of the invention. Brief description of the Figures

The present invention may be put into practice in a number of ways and embodiments will now be described by way of example only and with reference to the accompanying drawings, in which:

FIG. 1 shows a flowchart of a method for configuring a device;

FIG. 2 shows a flowchart of a method for managing data to configure a plurality of devices;

FIG. 3 shows a flowchart of a further method for configuring a device;

FIG. 4 shows a schematic diagram of a system for configuring a plurality of devices and associated data, given by way of example only;

FIG. 5 shows a schematic diagram of a data structure of a database used to configure a plurality of devices;

FIG. 6 shows a schematic diagram of the flow of data through different components of the system of figure 4;

FIG. 7 shows a flowchart of a further method for configuring a device;

FIG. 8 shows a flowchart of a further method for configuring a device;

FIG. 9 shows a sequence diagram of a method for configuring a device, according to an example;

FIG. 1 0 shows a sequence diagram of a further method for configuring a device, according to an example.

It should be noted that the figures are illustrated for simplicity and are not necessarily drawn to scale. Like features are provided with the same reference numerals.

Detailed description of the preferred embodiments

Figure 1 shows a flowchart (at a high level) of a method 10 for configuring a device. The device has a subscriber module (e.g. UICC or SIM) that has a

transformable identity or identifier. The first identity provides the subscriber module with the ability to connect with a wide variety of subscriber networks and provide the device with at least a data communication facility. In one example, this first identity allows the device to roam on to many different networks or any network with a roaming agreement with the subscriber module issuer. The second identity may not be defined within the subscriber module but can be received from a server or system in communication with the device (typically but not limited to over a cellular network using the subscriber module having its first identity). Configuration is achieved by providing the device with the second identifier and then transforming the subscriber module to this second identity (or providing an instruction to do so). The second identifier may be associated with specific cellular services. These cellular services may include a variety of different tariffs or tariff types, different types of communication (e.g. voice, SMS, data) or services provided by a particular network (e.g. location specific services such as mapping, traffic alerts, content provider services, video, music, or text service, for example). In order to determine a particular subscriber identity to send to the device, parameters of the device are determined at step 30. These parameters can be physical parameters (such as the device type), variable parameters (such as software version), user specific (e.g. details of an account holder), user selected (e.g. the user may indicate a particular request tariff), subscriber network specific (e.g. based on the subscriber network identity), or based on the subscriber module (e.g. the second identities sent to a device are restricted to particular batches or ranges of first subscriber module identifiers). Any all or more device parameters may be used and matched with stored parameters (or ranges of parameters) as step 40. A match may occur with a group of second subscriber module identifiers previous stored and associated with particular stored parameters (e.g. a group of identifiers is associated with a pay-as-you-go tariff selected by the user of a particular device type connecting to a particular subscriber network) at step 40. One of the group of matched second subscriber module identifiers is selected and provided to the device at step 50. The subscriber module identifier may then be transformed within the device, which provides the configuration of the device to access particular cellular services (e.g. a chosen tariff). The selected subscriber module may be selected based on different criteria. Example criteria include, selecting the next available subscriber identity (e.g.

SIM) from within the matched group. Alternatively, the next subscriber identity to be selected will be one that has a close expiry date, nearest expiry date or an expiry date within a predefined range (usually SIMs manufactured have a default period to stay on ready on the HLR of the local OpCos (for example 18 months). If the SIM is not activated within these 18 months, then the SIM is de-activated and removed from the OpCo systems, the system may select SIMs that will expire soon to more efficiently use SIMs from the local OpCo.

This method 10 proceeds between the device and a system (or server). The system may be able to administer subscriber identities issued by a number of different issuers (e.g. SIM manufactures), for a plurality of subscriber networks and/or for a plurality of original equipment manufacturers (OEMs) or device suppliers.

Figure 2 shows a flowchart of a method 200 for defining properties of the subscriber module identifiers provided to devices in the method 10 described with reference to figure 1 . The method may be carried out by the system (or server) described with reference to figure 1 and OEMs or device suppliers. The OEMs may acquire transformable subscriber modules and their corresponding identities from a UICC supplier. These subscriber modules may be placed in or with devices to be shipped to end users. The OEMs may add groups of these subscriber module identifiers (i.e. possible second identities) to the system using various formats. Data describing the groups of subscriber module identifiers are received by the system at step 210. These data may be individual identifiers (e.g. IMSI) or ranges of identifiers (e.g. IMSI ranges), for example.

Each OEM may need to configure device types differently. Furthermore, each

OEM may provide different cellular services in a different way to users and devices. For example, a first OEM may provide prepay cellular services only. Another OEM may wish to provide contract services to some devices and prepay cellular services to other devices. Additionally, each OEM may require that their devices use specific networks in different countries. These data may be defined by each individual OEM. The system receives subscriber module parameters at step 220. In order for different subscriber module identities to provide different cellular services (e.g. tariffs) then groups of the subscriber module identities (i.e. second identities) may be associated with (e.g. stored together with) information indicating such cellular services. For example, an IMSI range X to X+10,000 may be associated with subscriber module parameters: network A, for device B providing tariff C. IMSI range X+10,001 to X+15,000 may be associated with network D for device E providing tariff F. If a user of a device of type B connecting to network A selects tariff C then they will receive an IMSI within the range X to X+10,000 (provided one is available). At step 230, the system receives data indicating a particular cellular service. These may be fixed or altered later on. The data are stored at step 240 ready for method 10 to execute and the stored IMSIs to be issued. The system may support different local IMSI ranges and each operator may also have a reserved IMSI range globally. Advantageously, the system can support multiple operators. Figure 3 shows a flowchart of a method 300 for a user to initiate the configuration of a device. This will typically be a new device containing a transformable SIM before transformation has taken place. The user powers on the device and connects to a subscriber network at step 31 0. In this example, communication will be over a Radio Access Network (RAN) operated by the subscriber network (e.g. an OpCo). However, even though the device may have cellular capability, other communication channels may be used, including WiFi for any or all of the communications with the system. The user may be directed to a global landing page (GLP) when initially connecting. Whilst figure 1 shows a request being made at step 20, this may also be an indication that the device has connected to the network. At step 30 a first subscriber module identifier is determined. This is an initial identity or identifier (e.g. number) of a subscriber module that is transformable from a first identity to a second identity. In this example, the subscriber module is a SIM. The device will use this connection to communicate with the system that has stored the subscriber identifier data and associated parameters. The device may present the user with options regarding cellular services (e.g. on the GLP). In this example, this includes presenting the user with tariff options at step 330. The user selects a particular tariff at step 330. The options may be presented in different ways. For example, the device may use a browser to connect to a web landing. Alternatively, an application on the device (e.g. a mobile app) may run and be used to present and capture the user's selection. In any case, the user's selection and any other device parameters are communicated to the system over the subscriber network. As previously described, the system selects a subscriber identity (e.g. SIM ID or IMSI) to send to the device, which receives it at step 340. The SIM transforms to this new or second identity at step 350. The device may reconnect to the subscriber network using the new identity and receive cellular services, including the selected tariff, based on this transformed identity.

The device may be provided with a web landing page (GLP) that is specific to device parameters (e.g. combination of subscriber module identifier (initial identity) and the determined subscriber network identity). Other parameters may also be matched to provide a specific web landing page for that combination. The web landing page may be presented on a screen of the device in a browser or in another form. The web landing page initiates network configuration of the device. Figure 4 shows a schematic diagram of a system 100 used to implement the methods described with reference to figures 1 to 3. One or more devices 1 10 each include a subscriber module (e.g. UICC, eUICC or SIM) 120 that is transformable from a first subscriber module identifier (ID1 ) to a second subscriber module identifier (ID2). ID2 is received before transformation. Each of these IDs in their separate SIMs 120 are different and unique. When a device 1 10 having a subscriber module identifier before transformation, is first powered on and connects to a subscriber network 130, the device 1 10 sends a request to access a network such as the internet. This request is received by a server 140 which may be a simple out of the box experience (SOBE) control engine (SCE) 140, in this example. The SCE or server 140 also contains or is in communication with a database 150 for storing the parameters and subscriber module identifiers stored during execution of method 200 described with reference to figure 2.

A user or operator within in an OpCo may add subscriber identifiers 160 and associated parameters 170 as a data input 180, which may be stored in the database 150. This same system 100 may then be used to provide the subscriber identifiers according to methods 10 and 300 described with reference to figures 1 and 3, respectively. The interface between the OpCo and server 140 and user and server 140 may be a browser-based interface (web page), client server interface or application programming interface (API), for example.

The SCE 140 has the ability to integrate multiple Operating Companies (OpCos) at the same time and the ability to integrate to multiple SIM transformation services, which allow SIMs 120 to transform from using one OpCo (e.g. a Global OpCo) to another OpCo (e.g. local OpCo). This transformation can be two-way so users can revert their devices to the initial subscriber identifier and re-select a cellular service (e.g. tariff) or change OpCo (for instance, when moving abroad to a region served by a different network). Once the configuration of the device 1 10 has been initiated then the SIM transformation may take place. Transforming the SIM from a global to a local SIM allows the use of the local OpCo legal interception, content filtering, support and billing systems in order to provide a more consistent user experience, customizable per OpCo and per device, with the same tariff options, across different SIM assets which may belong to different OpCos. Different operating companies may also specify their own marketing or technical messages in their own language to the customer using the global and local SIM attributes together in a single platform.

In this example, the system or SCE 140 allocates target SIMs (second subscriber identities) which:

1 . Are designed to work with M2M transformable SIMs;

2. Belong to different Operating companies;

3. Have different tariff options;

4. Have the ability to tailor the tariff option and the target SIM according to the customer device; and

5. Tailor the tariff option and the target SIM according to the country to which the customer belongs.

This improves flexibility and fine-grained control different network operators with reduced integration from each operator.

Each operator and/or device supplier or OEM may define a technical and/or commercial proposition based on a number of parameters for a plurality of target devices. Each target device or device type may be defined in the SCE 140 using stored parameters 170 that may include multiple IMEI ranges, for example. The commercial proposition (e.g. cellular services including tariffs) may have a specific pool of group of subscriber identities (SIMs) assigned to it. In this example, the pool may be identified by multiple IMSI ranges. It will also be possible to define multiple IMSI ranges for the same commercial proposition. The commercial proposition (identified by possible multiple IMSI ranges) may have a link toward the pools of local IMSI ranges where the SIM is allowed to transform to. It is possible to add a new OpCo to an existing commercial proposition, by adding a local IMSI pool of that OpCo to the existing commercial proposition.

Figure 5 shows schematically the logical construction of an example commercial proposition defined within business logic of the SCE 140. The commercial proposition may be defined by a manager using a SCE administration GUI. Various components may interact using APIs, for example. A batch of IMEIs representing the devices are uploaded using operational users in the SCE Admin GUI. For example, a batch of 54,321 devices (or any other number) can be uploaded in a single operation to the commercial proposition by the responsible operational user in SCE Admin GUI.

Target (second identity) SIMs for the home country of the user of a device is provided with an appropriate tariff or tariff options across multiple OpCos for consumers of machine-to-machine (M2M) SIM transformation products by providing a the ability for each country to provide multiple SIM pools which can be configured in the SCE 140.

The SCE 140 also allows the addition of more countries to any commercial proposition at any time, which provides operational teams with the flexibility of increasing the scope of devices. This can occur while the system is fully operational and avoiding downtime. When a new country is added to the commercial proposition, a SIM pool from the new country may be associated with the commercial proposition. The SCE commercial proposition allows the new operating company to specify a local pool for all commercial propositions, or specify a local SIM pool for multiple commercial propositions or cellular services.

In on example, a commercial proposition may be provided in the SCE 140 to control device X12 (a tablet). This device may be rolled out initially to UK and Germany and may support tariff 1 and tariff 2. The SCE commercial proposition provides the ability to allocate different SIM local OpCo pools for the same device as illustrated in figure 7.

The SCE commercial proposition allows the definition of multiple tariffs which can be associated to the device group. Each tariff may have a tariff code and multiple tariff parameters which can be utilized by the local operating company to associate company specific parameters to the tariff. SCE commercial proposition combines multiple local SIM pools with multiple tariffs from different operating companies and allows the consumer or OEM to specify the required tariff.

Figures 7 and 8 show the interactions and method flows device configuration. A device is supplied by an OEM. An OpCo is being set up to provide connectivity and an operator administers the overall stem and process. In this example, Vodafone is described as the overall system operator but this may be any other operator or entity. The numbered interactions illustrate: 0. This is a preparation step where Vodafone (or any other operator of the system) shares text and images with the OEM. These images and text will be displayed on the device during the registration and/or configuration process.

1 . 3G (or other) call from device to determine customer eligibility. The device opens a 3G connectivity for X1 minutes (where x1 minutes is a counter configurable on the SOBE platform) to perform SCE eligibility checks regarding IMSI, IMEI, and the Country of connection (or any others).

Notes:

a. The 3G connectivity may be made when the customer accepts to register with the particular operator to avoid making un-necessary 3G connectivity checks.

b. This step may happen in the background and may not be visible to the end customer or user.

c. The client on the OEM may handle establishing a PDP context, waiting for X1 minutes, and then tearing down the session.

d. If the client on device is not able to establish a PDP context, then an error message may be displayed to the customer. 2. Customer Registration from OEM to Vodafone

This may be an API call from the OEM servers to Vodafone (or any other operator) to validate and register the customer information to the Target OpCo where the customer is trying to register. In case any of the information of the customer being invalid, the OEM will let the customer re-enter this information (example: Invalid post code) and re-send it back to Vodafone. The number of retries may be limited from OEM side up to X2 retries, for example, during a 24 hour perior (where X2 is a configurable parameter on the SOBE platform).

If the customer connects again after X3 for registration then another 3G connectivity may be required to recheck the customer eligibility. The maximum duration between 3G connectivity and successful registration is X3 (where X3 is a configurable counter on the SOBE platform). Tariff type may be one of the attributes of this API, which may also determine the behaviour in further steps (8 and 9 described below). Other numbers of connections may be defined. 3. Registration call-back API from Vodafone to the OEM (SIM status-update API)-Step 7

This may be an API call from Vodafone to the OEM with the status of the customer registration along with the assigned local SIM details, IMEI, group SIM details, for example.

SCE has the logic of registration flows for each OpCo, in one example case:

SCE may make another API call to OpCo to register the customer details then the response from OpCo will be passed to SCE (using a setSIMDetails API call) and SCE will pass the response back in the form of a call-back API along with the details about the assigned local SIM details, IMEI, group SIM details, and other parameters which will be specified later.

In case of customer registration failure due to invalid data, Vodafone may provide the OEM in the API parameters with the error code/reason of this failure. 4. Payment notification from Vodafone to the OEM (Device status-update

API call)- Step 8

In case the customer selected a tariff that requires payment, then Vodafone systems may wait for a payment notification call from the OEM (using OEM-Plugin - step 9).

The customer payment may be handled within the OEM systems without any interactions from Vodafone side.

5. 3G call from the OEM to Vodafone for SIM transformation request-Step 10. The Device opens a 3G connectivity to Vodafone to a trigger SIM transformation request.

Preferably, the device should be on a 3G (or equivalent) connection until the SIM transformed process completed to be able to receive over the air (OTA) calls. In one implementation, the device can receive the new SIM parameters using Circuit Switching attachment or over PDP context (3G or 4G) or use any other suitable procedure.

Figure 8 illustrates further enhancements and implementation details for this example. The OEM may implement its landing page or software on the device with the described functionality occurring in the background. Another option for customer registration is to use a GLP provided by the operator. The system allows OEMs to define tariffs and other cellular services provided to users of their devices. The tariffs may also be agreed between the OEMs and the OpCos or service provider. Figure 9 shows a sequence diagram describing an example process of the OEM specifying the cellular services and tariffs that may be associated with the customer device and are associated with the target SIM in the M2M SIM transformable product.

The follow includes the follow actions and events:

1 . OpCo flow: The registration process starts by receiving an external registration call from OEM servers with the customer information. The OEM plug-in makes an internal validation to check previous registration actions. If any inconsistencies are detected an error message is sent back to the OEM, and the flow may stop at this point. Otherwise a success message will be returned to the OEM (informing the registration request was accepted). The next part of the registration process may be executed in asynchronous manner. A new entry in the SIM Repository database 150 is inserted. This insert contains SIM details and marks the customer registration status to "REG_SCE_VALIDATION".

2. GetSIMDetailsV2 interface in SCE is invoked to validate that SIM information received from the OEM API call (MCC, MNC, IMSI, ICCID, etc.) matches what is stored in SOBE DB 150 from the PDP context made by the device.

3. If the validation is correct, then the GetNextPage interface is invoked so that a local SIM is assigned from SCE 140 to the SIM. The information about the local SIM details in the SOBE system are provided in the response to this API call. The tariff code is provided in this API call so that SCE can assign the target local SIM with the requested tariff.

4. Inserts another transaction in SIM Repository to update the status of customer registration process to "REG_SCE_SIM_ASSIGNED".

5. A second call to GetSIMDetailsV2 is executed to extract information about local SIM assigned from SCE. Customer registration status should be updated to " R EG_S C E G ET S I M_D ETA I LS " .

6. OEM plugin invokes setlMSIMapping interface to the OpCo systems (through GIG/Mondrian) to initiate customer registration on the OpCo with the customer details received from the OEM API call and the information about the assigned local SIM received from SCE. This information allows the OpCo to store a mapping between group ICCID/IMSI and local IMSI and also validate the customer registration details and initiate local SIM provisioning.

7. Inserts another transaction in SIM Repository to update the status of customer registration process to "REG_IMSI_MAPPING_SET".

8. Once the OpCo registration is finished, then the OpCo sends an update using setSIMDetails API call to the OEM plugin through GIG (detecting context property Partner/OEM).

9. After receiving the setSIMDetails call forwarded by GIG, the OEM Plugin will insert another transaction in SIM Repository to update the status of customer registration process to "REG_OPCO_REGISTERED"

10. The OEM plugin will then make a getNextPage API call to SCE. This invocation will update registration details in SCE and update the SIM state to either go to page 2 on the GLP (waiting payment) or page 3 (ready for SIM transformation) according to the tariff.

1 1 . Inserts another transaction in SIM Repository to update the status of customer registration process to "REG_SCE_SIM_UPDATED".

12. Invocation of interface SIMStatusUpdate in OEM Plugin to send back to the OEM the status of the registration process and customer details. This particular invocation represents SIMStatusUpdate (Call-back) use case.

13. After SIMStatusUpdate call-back being sent successfully to an OEM simple queue service (SQS) then another transaction will be inserted in the SIM

Repository to update the status of customer registration process to

"REG_CALLBACK_PROVIDED". Figure 10 shows a sequence diagram of the same steps as described with reference to figure 9 but with from the perspective of the interactions between the device and the GLP of SOBE. The interactions between the SOBE platform and OpCos are not shown in this diagram as they were explained in detail in the previous diagram.

The sequence starts by the device opening a mobile internet connection and requesting the SCE GLP. The SCE 140 determines the commercial proposition which is associated with the device and captures the information about which country the device is connecting from.

Once the device receives the GLP, a registration step is executed where the registration details are sent from the device to an OEM server (a payment server), which initiates an API call from OEM servers to the OEM plugin component (part of the SOBE platform). The OEM plugin requests the SIM details from SCE 140 (using getSIMDetails call) and then initiates a call to assign the local SIM on SCE getNextPage (assign-local- SIM). This call determines the tariff to be associated with the SIM using the tariff code.

Based on the tariff code, which is sent in the assign-local-SIM request, the SCE

140 will assign a target local SIM from the target OpCo pool, which matches the tariff code sent in the request from the OEM plugin. The OEM plugin initiates another call to getSIMDetails and then provides a response back to the OEM for the registration API call.

If the requested tariff by the customer requires payment, then the payment will be taken by the OEM services. Once the payment is complete the device will send a request to initiate the transformation of the SIM by requesting a page on the GLP of SOBE (or another interface), which will initiate the SIM transformation process. As will be appreciated by the skilled person, details of the above embodiment may be varied without departing from the scope of the present invention, as defined by the appended claims.

For example, other parameters may be included when matching a subscriber identifier to device parameters.

Many combinations, modifications, or alterations to the features of the above embodiments will be readily apparent to the skilled person and are intended to form part of the invention. Any of the features described specifically relating to one embodiment or example may be used in any other embodiment by making the appropriate changes.

Claims

CLAIMS:

1 . A method for configuring a device, wherein the device has a subscriber identity transformable from a first subscriber module identifier to a second subscriber module identifier, the method comprising the steps of:

communicating with the device connected to a subscriber network;

providing the device with a second subscriber module identifier from the group of subscriber module identifiers associated with the matched stored set of parameters.

2. The method of claim 1 further comprising the step of initiating

transformation of the subscriber identity of the device from the first subscriber module identifier to the provided second subscriber module identifier.

3. The method of claim 1 of claim 2 further comprising the step of determining a device type of the device, wherein the set of device parameters and the matched stored set of parameters associated with the group of subscriber module identifiers further include the device type.

4. The method of claim 3, wherein the device type is determined by:

receiving a device identifier; and

determining that the received device identifier corresponds with a group of device identifies associated with a predetermined device type.

5. The method according to any previous claim, wherein subsets of the group of subscriber module identifiers are associated with different cellular services provided by the subscriber network, the method further comprising the step of:

receiving from a user of the device an indication of a selected cellular service, wherein the provided second subscriber module identifier is within a subset of the group of subscriber module identifiers associated with the selected cellular service.

6. The method of claim 5, wherein the indication of the cellular service is a tariff selected by the user of the device.

7. The method of claim 5 or claim 6 further comprising the step of providing the device with a web landing page specific to the set of device parameters, wherein the indication of the selected cellular service is received using the web landing page.

8. The method of claim 5 or claim 6, wherein the indication of the selected cellular service is received from an application programming interface, API, call made by the device.

9. The method according to any previous claim further comprising the step of determining a first subscriber module identifier of the device, wherein the set of device parameters includes the first subscriber module identifier of the device, the matched stored set of parameters associated with the group of subscriber module identifiers further include data indicating a group of first subscriber module identifiers, and the matching step further includes determining that the first subscriber module identifier of the device is within the group of first subscriber module identifiers.

10. The method according to any previous claim further comprising the step of processing a payment from a user of the device before providing the device with a second subscriber module identifier.

1 1 . The method according to any previous claim further comprising the step of confirming eligibility of the user before providing the device with a second subscriber module identifier.

12. A system for configuring a plurality of devices, wherein each device of the plurality of devices has a subscriber identity transformable from a first subscriber module identifier to a second subscriber module identifier, the system comprising:

a processor;

a communications interface;

determine a set of device parameters including at least the subscriber network identity;

match the device parameters with a stored set of parameters associated with a group of subscriber module identifiers, wherein the stored set of parameters includes at least the subscriber network identifier; and

13. The system of claim 12, wherein the parameters include device type and the stored instructions, when executed by the processor, further cause the system to determine a device type of the device, and match the parameters based on device type.

14. The system of claim 12 or claim 13, wherein the transformable subscriber identity is stored within a UICC within the device.

15. The system according to any of claims 12 to 14, wherein the device is any of: a computer, a cell phone, a tablet computer, an e-book reader, a machine-to- machine, M2M, device, a smartphone or a vehicle.

16. The system according to any of claims 12 to 15, wherein the stored instructions, when executed by the processor, further cause the system to receive data describing the plurality of groups of second subscriber identities and associated sets of parameters.

17. The system according to any of claims 12 to 16, wherein the stored instructions, when executed by the processor, further cause the system to receive instructions to edit or update the data describing the plurality of groups of second subscriber identities and/or associated sets of parameters.

18. The system according to any of claims 12 to 17, wherein the stored instructions, when executed by the processor, further cause the system to:

receive instructions to associate an indication of a cellular service with each group of second subscriber identities; and

store the data describing the plurality of groups of second subscriber identities, associated sets of parameters and associated cellular service within the data store.

19. A method for defining properties of a plurality of subscriber identity modules, each subscriber identity module transformable from a first subscriber identifier to a second subscriber identifier, the method comprising the steps of:

provide instructions to associate an indication of a cellular service with each group of second subscriber identities.

20. The method of claim 19, wherein the parameters include tariff identifiers.

21 . The method of claim 19 or claim 20, wherein the data and instructions are provided as application programming interface, API, calls.