CONTROL OF OPERATION OF MOBILE COMMUNICATION DEVICES

Description

Technical field

[0001] This invention relates to methods and systems for controlling mobile communication devices such as mobile phones.

Background art

[0002] Mobile communications devices such as mobile phones, PDAs with communication capability and the like are able to communicate in a number of different ways. Two of the most common are voice communication and short messaging service (SMS), also known as text messaging. The ability of a device such as a handset to handle such different communication capabilities is a function of its design. However, in current service offerings, it is the communications service provider that enables the various types of communication with other devices. In simple terms, if a subscriber is not signed up for a certain type of service, the service provider does not allow any instance of that type of communication to take place, irrespective of the functional capability of the device. Examples of this could be the ability to make calls to international numbers, the ability to make calls when outside a home country, etc. Such permissions are all handled at the level of the service provider.

[0003] It is becoming increasingly desirable due to rising customer needs and hence potential commercial opportunity to provide greater levels of control or finer grain control of services provided on a user by user basis. One example of this that exists today is number blocking. In this case, the service operator is informed of a number to be blocked and it configures its service to prevent any communication from this number from being connected to the subscriber. This blocking is performed at the service provider level and is typically an 'all services on' or 'all services off level of control. The way in which this is performed, using the core network equipment and software, is such that there is sufficient commercial risk to disruption of the established network services as to make it unattractive for a service provider to offer this facility to a wide range of customers with a varied set of configuration options.

[0004] Most handsets for communication devices include a subscriber identification module (SIM) which comprises a relatively small integrated circuit device (a chip) that can be inserted into a handset to make it operable on a given service provider's network. The SIM is typically provided by the service provider or its trading partner and includes certain data pre-programmed into it to control the basic operations of the handset. The SIM acts to identify the subscriber to the service provider (operator) and allows standardised, secure account authorisation for the customer (subscriber) to access the contracted (or pre-paid) network services. The SIM can be moved from one handset to another, allowing the subscriber to upgrade the handset while retaining the same service or services. As the processing and memory capacity of SIMs has increased since their introduction in the 1980's , more functionality has been made accessible via the handset. One common way in which this is done is by providing the SIM with Java programming ability and installing on it small Java applications (known as 'applets') to control the handset and provide extra services. However, due to their processing and memory limitations and the way in which they integrate with the software functions of the handset, current SIMs do not have sufficient capacity to handle all aspects of call handling in their standard form. They require an external system of some kind to manage the rules they must operate by and additional control functions to be implemented that allows them to execute the extra call handling functions.

[0005] Detailed, qualitative control of a particular device, for example barring certain types of call at certain times of the day, is relatively cumbersome for the operator using their core switching network to provide the control though it can be shown to be highly desirable for certain groups of subscriber. It is an object of the invention to provide a system that allows a subscriber to exert detailed control over the possible uses of a handset without the need for the operator to continually revise the network's delivery of services for that handset.

Disclosure of the invention

[0006] One aspect of the invention comprises a method of controlling operation of a mobile communication device, comprising: establishing in the device means for controlling its operation in accordance with programmable control conditions as defined and held on a remote server; communicating one or more control conditions from a remote server to the device; storing the control conditions in the device; and operating the device in accordance with the stored control conditions; wherein operation of the device comprises using the control conditions to enable, disable or conditionally moderate in some way the ability of the device to communicate with one or more other communication devices via one or more communication channels such as but not limited to voice, SMS or data.

[0007] By separating components of the method between the device and the remote centre, it is possible to work within the limited processing capabilities of the device while still allowing effective detailed control of the device.

[0008] The remote server is the means by which control conditions are created, stored, modified, deleted, delivered to remote devices or shared with other network service management systems. The remote server is not limited to a single processing machine or software instance, but rather the remote server may be one or more servers working in concert to handle a few or a great many representations of subscribers, services and control conditions and the delivery of the relevant service data to systems or devices on an as required basis.

[0009] Where the communication device is integrated with a SIM, the step of establishing a means for controlling operation of the device preferably comprises programming the SIM with a control application which effects its control of services delivered to the handset on the basis of the control conditions supplied to it from the remote server. The control application is preferably but not limited to a Java applet.

[0010] It is particularly preferred that the control conditions are communicated to the device by means of an encoded message that makes optimal use of the selected communications channel. In the example of using the SMS

channel the message can be binary or text. In the case of using a binary SMS channel the message can merely contain the necessary binary code to be implemented in the control application. In the case of a text encoded SMS, additional binary code is added to the message such that it corresponds to binary code representation of ASCII formatted text. The encoded message may additionally be subject to encryption for purposes of security without affecting the end to end delivery of control conditions.

[0011] The control conditions can be established at a user interface which communicates with the remote server which in turn creates and sends the appropriate encoded control condition messages to the device.

[0012] The SIM-based control application typically contains a set of rules to enact the control conditions. An encoded control condition message can include administration commands which, when implemented, act to delete an existing rule and/or write a new rule or modify an existing rule in the control application.

[0013] The commands are preferably formatted as Tag-Length-Value (TLV) combinations containing an identifying tag, a length and a value field corresponding to the length. The value field may itself comprise another TLV.

[0014] After receipt of an encoded message and a notification of arrival, the SIM can send an acknowledgement message back to the server indicating the status of each command received by the control application.

[0015] It is particularly preferred that the control application implements rules defined by the supplied control conditions in relation to specified events occurring on the phone as the user receives benefit from or initiates services, and these rules may be enacted to include (but are not limited to) to a 'service allowed list' ('white list ¹ ) or 'service not allowed list' ('black list') and the device triggers the control application to determine if the event is allowed, not allowed or should undergo some predefined moderation or modification.

[0016] The invention also comprises a mobile communication device including means for controlling its operation in accordance with programmable control conditions, the means being capable of storing one or more control

conditions communicated from a remote server to the device and operating the device in accordance with the stored control conditions, the means using the control conditions to enable or disable the ability of the device to communicate with one or more other communication devices and / or to provide the requested service to the intended other device or devices via an alternative means or channel of communication. For example an incoming request for a voice call could be modified to generate an SMS message or email to a predefined destination indicating the service request for a voice call while rejecting or passing through to the subscriber the voice call.

[0017] The device preferably comprises a SIM on which the means reside.

[0018] A system according to the invention comprises one or more such mobile communication devices and a remote server capable of communicating control conditions to each device in a timely or otherwise manner to allow representation of the control condition defined in the remote server having appropriate representation available locally to the control application at the time that it may be needed. For example certain changes to control conditions on the remote server may be delivered to the control application within a matter of seconds and others may be delivered once a day or at a predefined time on an as required basis.

[0019] The means for controlling operation of the device preferably comprise a SIM card on which a control application is programmed and data representing the control conditions are stored within the same SIM card (locally). In this way, the service provider can retain control over this programming environment via the use of cryptographic security for the puφoses of defence against fraud or subversion

[0020] The control application can have a linked list or table structure to define the locally held control conditions, which shall include separate tables or linked lists for various indices, properties and rules that allow for memory and processing efficiency in their operational use. One particular form of core application comprises a core byte table containing basic core properties, a numbering index table containing phone numbers to which rules apply, an additional properties table containing properties other than

numbers to which rules apply and a master rules table containing the default rules to be applied by the core application in operation of the device.

[0021] A user interface, typically in the form of a web interface, can be provided which allows a user to connect to the remote server and view or delete or modify control conditions and the events to which they each relate and for them to be communicated to the control application on the SIM device as required.

Brief description of the drawings

[0022] Figure 1 shows schematically the general information exchange between a SIM application and a microOSS server in one embodiment of the invention;

Figure 2 shows schematically how the SIM-based control application executes a command and gets the requested parameters that define a control condition from the SIM and stores the data representation of the control parameters locally in an embodiment of the invention; Figure 3 shows the roles and functions available in a Parental Control application ; and

Figure 4 shows schematically the use of the Parental Control application in an embodiment of the invention.

Mode(s) for carrying out the invention

[0023] This invention differs from other mobile communication management systems in that it allows the SIM to perform call handling functions. The SIM has not previously been used to perform such a sophisticated task since the core voice switching network normally performs such a task for reasons that it has historically been the only option. However, making modifications to the core system typically represents high cost, long timescales and high risk to the owner or operator of that network. By contrast, systems according to the invention implemented on the SIM have no impact on the core network and can communicate via a readily available communication channel between the remote server and the SIM, such as the SMS network or pre-existing network control channels and these alternative channels represent very low cost and low risk control

options to the service providers. For example using SMS as the communication medium requires at a minimum just a single connection to a Short Message Service Centre (SMSC) via a standards compliant interface or multiple connections for purposes of resilience to failure.

[0024] The particularly preferred form of control at the device (handset) level is in the form of a control application in the SIM which operates according to the control conditions which consist of a set of rules that define the blocking, permitting or modification actions triggered upon defined events. This concept of service permission control is referred to as blacklist (blocking) and whitelist (allowing) When an event (such as a voice call, an SMS or an MMS) occurs on the handset the core application intercepts the request and scans for any and all applicable rules. For an event occurring in blacklist mode the service request parameters are checked against the predefined control conditions that explicitly state numbers to be barred. If a number (i.e. phone numbers) has an explicit blacklist rule then the service request to or from that number is rejected by the control application. For an event occurring in whitelist mode, only events are allowed for numbers for which 'allowed ' rules have been explicitly made. In other words, blacklist mode allows blocking of specrfic events, whitelist mode permits specific events.

[0025] The control application tests the control conditions in such a way as to differentiate between defined events for 'service to' and 'service from' the handset to the network and this directionality is embodied in all relevant representations of service permissions defined in control conditions on the remote server.

[0026] If at any time during this control condition checking process a rule is not satisfied, the next rule in the list or table is repeatedly checked until all have been exhausted or a service has been explicitly allowed or not allowed which acts a termination condition for the rule checking. If no applicable rule is found then the service is passed through to the user unmodified and the control application has no impact upon the service.

[0027] The control application has the option to provide to the handset user messages on the screen to indicate its actions or decisions and further to

have the option to offer the user input and choice in how certain rules may be applied. For example, should a call be blocked the user may be given the option to request that calls are allowed in future and a predefined person, handset or system process may allow or deny the request. [0028] Examples of rule parameters which can be applied to events in blacklist or whitelist mode to block or permit the event include:

1. Geographical location - e.g. permit calls only from a given area, permit calls only if outside a given area where defined by national telephone number system area codes.

2. Time - e.g. block all calls if it is between 10pm and 4am, permit only outgoing calls between 8am and 4pm;

3. By Network - e.g. block calls if the user is on the specified network, permit calls only if the user is on the specified network;

4. On the basis of the role in organisation of a party to a service, where control conditions exist to define the permission of a called or calling party's role or grade or job function where those attributes are available from suitable data sources or external systems;

5. Specific numbers - e.g. only allow outgoing calls to be made to 0123456789, only allow incoming calls from 01233456678.

6. Number ranges - e.g. only allow outgoing calls to numbers 01233456670 to 01233456679.

7. Countries - e.g. only allow or block outgoing calls to be made to a specified country or group of countries or only allow incoming calls from a specified country or group of countries. Further, in keeping with the flexibility already defined for control conditions the countries that may be allowed or blocked are not required to be the same for incoming and outgoing calls

8. Wildcards - e.g. only allow outgoing calls to be made to 078*. only allow incoming calls from 0786*

[0029] These can be used in any combination and other parameters are also possible. [0030] The system records date, and source destination phone numbers, service type for not only outgoing calls (which all operators can do through their

billing records) but also incoming calls, incoming SMS and incoming MMS. These records are all stored on the remote server and are retrievable at any stage for reporting, analysis or other purposes. This data is collected on the SIM and delivered to the remote system via the defined communication channel that may be, but is not limited to, SMS, GPRS or UMTS where available or preferred by the service provider. [0031] A system according to the invention shall have three main elements:

• SIM-card application, that runs on the end-user's SIM in their phone;

• Remote server which is a back-office application and supports business system interfaces which controls the service and provides the user the ability to define and manage control conditions for each service (this is called as a product the microOSS); and

• A communications protocol that operates from the SIM to the back- office (for example, using well known and existing standards and interfaces).

[0032] Figure 1 shows the general information exchange between the SIM application and the remote (microOSS) server. In these examples SMS described as representative of one communications protocol; others may also be used. Every transaction transits the SMSC interface of the operator so as to ensure that all transactions conform to the operator's provisioning environment.

[0033] The microOSS (Server, User Profile Settings and SIM Information Repository) and a set of SIM based applications (SIM Application, Permission Checking, and Call Control Parameters) (applets) are shown in Figure 1. These SIM applications embody the 'control application' and can communicate bi-directionally using any one of a number of protocols including: SMS, BIP, IP, etc.

[0034] The SIM identifies a subscriber to the mobile phone operator's network and allows standardized, secure account authorization for their customers. The SIM can typically be moved from one phone to another within the provider's network.

[0035] The SIM application is a compact piece of code that resides on the SIM. It enables the operator to remotely interrogate the mobile device via the SIM.

Its function is to provide basic information back to the operator about the identity of the device, who is using the device and the device operating status. It provides the ability for the operator to execute management commands common to many mobile devices.

[0036] Since this invention allows the SIM to be used as the application platform it can provide these applications with the same level of integrity that operators are familiar with from their Over the Air (OTA) account provisioning systems. The GSM infrastructure is preferred to securely communicate between its custom components.

[0037] The core application in the SIM application typically has the following functionality and can report the following information to the microOSS remote server.

• Reports IMEI and device model (e.g. reports if SIM is put into different device)

• Reports the device profile.

• Reports the location of the device.

• Provides communication to microOSS (via operator's OTA or SMSC). [0038] Every time the SIM is placed into a new device the 'profile' of the handset is checked by the SIM application to see if the handset is compatible and any profile information is sent to the microOSS.

[0039] A set of parameters are needed for SIM applications, some of which are common to all applications and some of which are application specific. Core parameters, needed by all applications, include the standards defined: IMEI ₁ MISDN, Terminal Profile, Location. Additional parameters needed for specific uses such as parental control or enterprise control (discussed in more detail below), include: call control parameters, SMS control parameters, MMS control parameters, NMR parameters, call disconnect monitoring, call initiation monitoring.

[0040] The operator uses an OTA server/SMSC in order to authorize and provision the account and subsequent operation on their SIM.

[0041] The microOSS server provides a user interface (Ul), a data repository, and in some cases an analysis engine for the processing of raw data into results, reports and scripts. The remote server is the main interface for the

service provider operations staff and additionally via an internet web portal the handset end user and is also responsible for sending the commands to the applet. The server also stores all information about subscribers, phone numbers, configured services and information coming back from the device about status and operation.

[0042] The server will typically have a web interface with a variety of service configuration and subscriber records available which, when changed, result in the update to the SIM control application or relevant control conditions and service handling rules. The server may reside on the operator's premises and the server applications conform to the rules implemented on the operator's OTA server or SMSC for the delivery of service updates to their subscriber handsets and SIMs.

[0043] Sending a message to a target SIM card involves the following steps:

1. The microOSS server issues an command requesting the OTA or SMSC platform to perform a given task on one or more remote SIM cards. This command includes the target SIM card, subscriber-related data, and the command to be executed by the CA.

2. Using the parameters passed by the microOSS, the communications platform retrieves additional information (e.g. subscriber data) required to create an appropriate message and generates the header as part of the message. This header is in turn used by the remote SIM card for authentication, identify the message's origin and to establish a secure environment in which to execute the application.

3. An SMSC forwards the message or messages to the target devices via the GSM network. The arriving SMS messages have to be transparent to the user, and uses the appropriate SMSC settings This command loads the message into a buffer on the SIM card. This method enables the SIM card to load and execute the SIM applications in a manner that is totally transparent to the end-user (no notification is displayed on the mobile equipment's display).

4. Once a message has been loaded on the SIM card, the SIM card checks the message's SMS header. This enables the SIM card to differentiate messages containing data from standard SMS text

messages and checks the message's integrity and authenticity by applying a number of security mechanisms. 5. The SIM application executes the command and gets the requested parameters from the SIM and stores the data locally in a structured file or sends the information back to the microOSS (see Figure 2). [0044] The core application is a Java Card application that resides on the SIM card. It enables a server to send commands via SMS to implement rules as defined by a cellular subscriber from a web based front end from a computer. Subscribers may repeatedly create and delete rules that modify the behaviour and permissions of the services (calls and SMSs) provided by their mobile phone. The following details describe one specific implementation of the Core Application. [0045] The Core Application consists of 3 Java files:

• CoreApp.java

• CoreAppConstants.java

• CoreAppTable.java

[0046] All of the code resides in CoreApp.java, while CoreAppTable.java contains a structure to hold the master Rules table (MRT) and CoreAppConstants.java contains all of the constants used throughout the application.

[0047] These three Java files are compiled and converted into corresponding

.class files and one .jar file. This .jar file is approximately 5.8K with space for 100 phone numbers and 100 rules. It can be enlarged or decreased depending or requirements and memory space.

1. The Core Application consists of four tables that hold all pertinent information. These four tables are:

2. CORE Byte Table (CID)

3. Numbering Index Table (NID)

4. Additional Properties Table (AID)

5. Master Rules Table (MRT)

[0048] Correctly formatted commands create rules in the MRT that utilize a combination of the other tables. Each entry in the first three tables contain an index and a property, while the MRT organizes rules out of indexes. In

this fashion, multiple rules may utilize the same number and/or additional property. Additionally, because all rules contain only indexes to the CID ₁ changes made to the CID are automatically applied to all rules that refer to that index.

[0049] The CORE table (Table 1 below) is the only pre-populated table. The table contains 1 byte where each bit represents properties of the CORE properties:

• Direction: Incoming or Outgoing

• Service: Call, SMS, or MMS

• List: None, Black, White

[0050]

Table 1

[0051] Only bits 0 and 1 of the CORE table are modifiable. A mode's list is modified with every WRITE command. Additionally, a WRITE command may be issued with only a CORE byte and no NID or AID tag such that a mode's list may be changed without creating a new rule. Each mode defaults to having no mode selected such that all services are allowed. An unrecognized CORE value in an incoming command invalidates that command.

[0052] The NID and AID are merely indexes to strings of bytes. In the case of the NID, the bytes are phone numbers to which rules apply. In the case of the AID, the bytes are TLVs, which contain additional properties.

[0053] Three commands are implemented in the Core Application:

• READ

• WRITE

• DELETE

[0054] The READ command provides the server with the means of reading rules from the SIM When a READ command is issued the core applet will transmit the existing rules to the server. These can then be checked for and modified if necessary. The WRITE command provides the server with a means of creating rules to be stored on a SIM. DELETE similarly provides the server with a means of deleting existing rules from a SIM.

[0055] All commands are transferred to the SIM via SMSs. Therefore, each SMS may contain as many commands as fit within the typical 162-byte SMS limit. Commands may be concatenated within an SMS. Updating a rule requires first deleting a rule and then rewriting the rule with the desired changes.

[0056] All commands are formatted as Tag-Length-Value (TLV) combinations. TLVs contain a 1 byte identifying tag, 1 byte length, and a value field corresponding to the length. The Value field may itself be another TLV.

[0057] Commands may have from one to three tags per command, depending on the usage of the command. Those tags are:

1. CORE tag

2. Number tag

3. Additional properties tag (optional)

[0058] The CORE TLV contains only 1-byte referring to a shared CORE table between the server and application on the SIM. [0059] The NUMBER TLV contains up to 10 bytes of semi-octet data formatted as a TON/NPI/Number. TON and NPI are defined in the standard 3G 23.040, section 9.1.2.5. The Number is defined in 11.11 in the description of the file contents of EF_ADN. [0060] The additional properties are contained in sub-TLVs which can be defined for each property. [0061] Upon completion of all commands within an SMS, an acknowledgement

(ACK) SMS may be sent from the SIM to the remote server with the status of each command performed corresponding to the respective bytes of the

SMS. WRITE commands will return either O or 1 for true or false. However, as DELETE commands may delete multiple rules, they return the number of rules that have been deleted. In one example, the server sends an SMS every time a phone number is written or deleted or modified.

[0062] Example of a command: WRITE 0x17

CORE 0x01 0x47 // Index 1 referring to incoming calls whitelist, 3 bytes

NUMBER OxOA 0123456789 // Not a real number, OxOC bytes ADDT_PROP 0x06 // 8 bytes

TIME 0x040x01 0x020x030x04 // 6 bytes

[0063] The WRITE, DELETE, READ, CORE, NUMBER, ADD_Prop and TIME have predefined values.

[0064] Some operators do not allow binary SMS so it may be necessary to send binary and text SMSs. For example, whereas the server would send: 0x01 0x06 // WRITE Tag and Length

0x100x01 0x47 // CORE Byte Tag, length and data byte 0x11 0x01 0x12 // Number Tag, length and data

[0065] Therefore, the server has a parameter which adds an additional value to every byte of each command (e.g. 0x30) to bring the value into the typeable ASCII range. A variable useful for this purpose is 0x30. [0066] Therefore, adding 0x30 to each byte: 0x31 0x36 0x40 0x31 0x77 0x41 0x31 0x42

[0067] And as ASCII characters: 1 6

@ 1 w A 1 B

[0068] So the command to write the rule to White list incoming calls would be 16@1wA1B.

[0069] The following details set forth aspects relating to rules implemented in the

SIM. [0070] All incoming rules contain:

1. CID

2. Number

3. Optionally, additional properties

[0071] An incoming command gets a new entry in the MRT that consists of references to each of the CID ₁ NID and AID tables.

1. The server is aware of the Indexing scheme for the CID and sends the appropriate CID. Unrecognized CID are not allowed.

2. The Number is added to the NID table. Before adding the number, the table is searched to see if the number already exists. If it does, that index is used. If not, a new entry is added.

3. The Additional Properties are added to the AID table. Before adding the property(s), the table is searched to see if the EXACT property(s) already exists. If it does, that index is used. If not, a new entry is added. If no Additional Properties exist, this reference is "0".

[0072] When an event occurs on the handset (call, MMS, SMS):

1. The CID is used to determine if that event is in B/W/none mode. If it is in "none" (00), the event is allowed. If other than "00", go to (2).

2. The MASTER table is searched for a CID entry that matches that of the attempted event.

3. When a match is found in the MASTER table, the NID is read across. The NID is used to retrieve the number and is compared against the one being attempted. If it matches, go to (4). If it fails, go to (5).

4. Continue reading across to the AID column. If the AID entry is "0", this event is automatically allowed. Otherwise, the AID entry is used to retrieve the additional properties. If the additional properties are false, go to (5). If they are true, then if in White list mode, allow the event. If in Black list mode, do not allow the event.

5. Check next MASTER table entry.

6. If the end of the MASTER table is reached: a. If in White list mode, the event is not allowed b. If in Blacklist mode or "none", the event is allowed.

[0073] To change between B/W/none modes, send a command with no number and the CID corresponding to the list to be changed with bits 0 and 1 representing the mode to change to.

[0074] When deleting an event, care must be taken not to delete NIDs or AIDs that are being used by other rules. Therefore, when deleting a rule:

1. Search the MASTER table to see if another rule is also using the same NID. If so, then do not delete it.

2. Search the MASTER table to see if another rule is also using the same AID. If so, then do not delete it.

[0075] When an event occurs on the handset (call, MMS, SMS), the MRT is scanned searching for applicable rules. The CID field of the MRT is first checked searching for rules with CID indexes corresponding the direction and service type of the event. When a match is found, the corresponding NID is then compared against the number that is being attempted. If this number matches, then the AID is checked to see if there are any additional properties. If none exist, then the list type of the CID entry is examined to determine the appropriate behavior. For a service and direction in Blacklist mode, only numbers for which rules have been explicitly made will not be allowed. Conversely, for a service and direction in White list mode, only numbers for which rules have been explicitly made will be allowed. If at any time during this rule checking process a rule is not satisfied, the next rule is then checked until all have been exhausted or a service has been explicitly allowed or not allowed.

[0076] A direction and service may also be changed to and from "No List" mode. This state would be used if rules have been created for a particular mode that temporarily are not applicable. Rather than deleting the rules, they may be set to "No List" mode, as they were by default, and then later reactivated to either Black or White list mode.

[0077] If the end of the MRT is reached and no applicable rule has been found: 1. If in White list mode, the event is not allowed

2. If in Blacklist mode or "none", the event is allowed.

[0078] The system described above allows control over the use of mobile phones. Two particular examples of such controls, parental control over the use of a mobile phone by a child, and enterprise (company) control over the use of a mobile phone by an employee.

[0079] The core application described above works in conjunction with the microOSS and allows parents to monitor and control who their child will be able to talk and SMS/MMS with.

[0080] Figure 3 shows the roles and functions available in the Parental Control application for the Parent, customer service representative (CSR) and system administrator (Sys Admin). This application enables parents to restrict calls made and received by their children. Calls include both voice calls and SMS/MMS messages. Parents can set spending limits on the child's account and limit phone usage to particular hours. Parents can also get activity reports on activity and usage.

[0081] The following are some of the functions that can be permitted, denied, monitored and reported:

• The child's phone will only be able to make or receive calls from one or more specified numbers

• Attempts of the child to make call to a number which is not permitted by the parents will be denied and reported

• Attempts by denied outside numbers to make calls to the child's phone can be prevented and reported

• Attempts to contact services or numbers which are deemed inappropriate by the parent(s) can be denied and reported.

• Set priorities for billing (e.g. parent's number has unlimited calls but friends are only allowed to be called for £10 a month)

[0082] Figure 4 shows schematically the use of the parental control application: 1. Parents enter which numbers the child is allowed to call, or which numbers are allowed to call the child's phone (they create a profile for allowed usage for each phone) by means of a web interface on a screen.

2. The numbers are sent to the SIM and the core application (CA) selects the desired phone numbers

3. If the transaction is successful, the CA sends an acknowledgement back to the server. The success or failure is visible for the parent on the screen.

4. Child initiates a call. If the called number is not permitted (previously not included by the parents in step 1 , the call is not initiated by phone. If the called number is on the permitted list THEN

5. The call is made to destination number.

6. In the case in which a member of the public is trying to initiate a call to child, if the caller is not on the list then the call is not let through by the SIM. If the caller is on the list THEN

7. Child receives call from the number.

8. All the called numbers and received calls are logged and send to the server/web interface.

9. Parent can view call transactions (successful and failed attempts to make or receive calls).

[0083] The enterprise control application operates in much the same way as parental control. In this case, the application comprises a utility in an application that allows an authorized person to manage whole domains, groups, and individuals via the web interface. This application allows business rules to be constructed and implemented via the microOSS. The microOSS can also collect data which can be analyzed to show patterns of usage, abuse, excessive roaming, and out of working hours usage. A potential example is as follows:

• Data can be collected and analysed for patterns of abuse or for te purpose of other ad hoc reporting.

[0084] Example of use - Company X is a beverages delivery company provides GSM enable PDA devices to all of its delivery drivers. The GSM-PDA has the ability to place mobile voice calls as well as data calls. Since all drivers work fixed shifts and drive fixed routes, the desire to limit time and roaming may be at a premium. The application allows the Company to set business rules limiting or prohibiting the use of devices outside of shift

times, authorized coverage areas, and iimit access to non-business related services. Rules can also be set up to allow the employee to use the device for personal use. These rules can be used to segregate what is business use and personal use. [0085] The following are some of the Enterprise application functions:

• Employee's phone is able to make calls to a set of specified numbers.

• Employee can only call within a specified geography.

Employee can only make authorized calls within a defined time period.

• Employee can be limited to personal calls either to specific numbers or within a specified time period.

• Data can be collected and analyzed for patterns of abuse. [0086] The application allows the corporate administrator to change and configure new rules based upon usage patterns or change in responsibilities.

[0087] It will be appreciated that the rules given above are mere examples and others can be derived. By allowing each phone to be controlled by the rules programmed into the SIM, a detailed level of control can be obtained that does not require the operator to make changes to its core network. Variations can be made while staying within the scope of the invention.