State Detection

Abstract

Method of determining a state of a mobile device, the mobile device having a one or more sensors, the method comprising the steps of: obtaining sensor data from the one or more sensors of the mobile device in an initial state. Determining if the initial state matches a previous state by comparing the obtained sensor data to previous sensor data acquired with the mobile device in the previous state. A mobile device includes logic to carry out this method.

Description

CROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to United Kingdom Application Number 1122206.4, filed on Dec. 21, 2011, and United Kingdom Application Number 1205160.3, filed Mar. 23, 2012 the entireties of which are incorporated herein by reference.

FIELD OF THE INVENTION

[0002] The present invention relates to a mobile device and method of determining a state of the mobile device.

BACKGROUND OF THE INVENTION

[0003] Mobile devices and especially cell phones, may be configured and operated in different ways depending on their particular state or context. For example, the display may be dimmed when the mobile device is in a state of low ambient illumination and the volume of the ringer may be raised when the mobile device is in a state of high ambient noise. A user may provide an input to the mobile device when the state or context of the mobile device changes, in order to actively alter operating characteristics or settings. For example, if a user enters a meeting, they may wish to place their mobile device in "meeting" mode, which disables the ringer, enables the vibration alert and perhaps disables or dims the display.

[0004] There may be many other different states and that the mobile device may operate within each requiring different settings or operational responses from the mobile device. There are other optimisations or functionality that may be used provided a particular state is known. However, it is impractical and inconvenient for the user to manually select or identify a particular state whenever such a new state is encountered.

[0005] Therefore, there is required an improved mobile device and method that may overcome these problems and disadvantages.

SUMMARY OF THE INVENTION

[0006] Against this background and in accordance with a first aspect there is provided a method of determining a state of a mobile device, the mobile device having one or more sensors, the method comprising the steps of:

[0007] obtaining sensor data from the one or more sensors of the mobile device in an initial state; and

[0008] determining if the initial state matches a previous state by comparing the obtained sensor data to previous sensor data acquired with the mobile device in the previous state. Therefore, the state or context of the mobile device may be detected or determined automatically. Furthermore, this avoids privacy issues as the state may be acquired or determined within the device without necessarily relying on or providing external information. This method may be preferably carried out within a mobile device and so network connections or external storage of personal data may be avoided. Preferably, data from more than one sensor may be acquired and compared simultaneously to provide more robust and accurate state detection. The initial state may be similarly described as the present or current state of the mobile device or the state at the time the sensor data are obtained.

[0009] The comparison may be made by comparing patterns within or of the obtained data against patterns in the previous data.

[0010] Advantageously, the comparison may use statistical inference. This allows a match to be made even where sensor data are not identical.

[0011] Advantageously, the comparison of the obtained sensor data to the previous sensor data may be carried out on vector representations of both data. The vector representations may be codebook vectors. The obtained data may be converted to a vector representation. The previous sensor data may also be in the form of vector representation and preferably stored in the format to aid comparison and matching and also to reduce storage space and processing power requirements.

[0012] Optionally, the comparison may use statistical inference, frequentist inference, Bayesian inference, or Hotelling's T.sup.2 distribution.

[0013] Preferably, the previous sensor data may be retrieved from a database of sensor data acquired with the mobile device in different states. Therefore, the sensor data may be stored locally without requiring data transfer resources.

[0014] Optionally, the method may further comprise the step of storing the obtained sensor data of the mobile device in the first state in the database when no matches are found. This provides a mechanism to update and increase the available matchable and comparable data.

[0015] Preferably, the previous sensor data is stored in a database as vector representations and preferably codebook vectors. Other storage formats may be used. Vectors representations may be compared more easily using statistical inference.

[0016] Optionally, the method may further comprise the step of selecting a previous state to compare with the initial state based on a nearest-neighbour search of the sensor data. This reduces the processing and time necessary to make a match.

[0017] Optionally, the method may further comprise the step of selecting a previous state to compare with the initial state by determining the most commonly matched previous states. This reduces the processing and time necessary to make a match as more commonly matched results may be more likely to be matched in future.

[0018] Optionally, the sensors of the mobile device may be one or more selected from the group consisting of: an accelerometer, a digital compass, a GPS receiver, a microphone, an ambient light sensor, a thermometer, a radio receiver, a proximity sensor, a Bluetooth receiver and a Wi-Fi receiver.

[0019] Optionally, the method may further comprise the step of receiving a state identifier for the initial state and/or the previous states. This may allow easier configuration of known states. This may involve semantically tagging the initial (and/or previous) states. The state identifier may be received from a user. User intervention may take the form of presenting the user with matched or unmatched states (i.e. a set of states that were initial states or previous states). The user may then provide a label, name, identification or context as the state identifier for these states if known to them. For example, the time and date may be presented along with each state and the user can provide a narrative or label for future use as a state identifier (e.g. should a match be made against a previously identified state). Unknown states may be presented for identification. Furthermore, previously identified or similar states may be presented for confirmation, updating or deletion if necessary.

[0020] Such state identifiers may be received from external sources (in addition or instead of from the user). These external sources may include social networks or other user data (e.g. crowd sourcing).

[0021] According to a second aspect there is provided a mobile device comprising:

[0022] one or more sensors; and

[0023] logic configured to: [0024] obtain sensor data from the one or more sensors of the mobile device in an initial state; [0025] determine if the initial state matches a previous state by comparing the obtained sensor data to previous sensor data acquired with the mobile device in the previous state. The logic may be contained within a processor or processors of the mobile device.

[0026] Advantageously, the comparison of the obtained sensor data to the previous sensor data may be carried out on vector representations of both data.

[0027] Optionally, the comparison uses statistical inference, frequentist inference, Bayesian inference, or Hotelling's T.sup.2 distribution.

[0028] Optionally, the mobile device may further comprise a database configured to store sensor data acquired with the mobile device in different states. The database may be configured to store fingerprints or vector representations of the sensor data instead of or as well as the actual data.

[0029] Optionally, the method or logic of the mobile device may further comprise:

[0030] obtaining further sensor data from the one or more sensors; and

[0031] determining whether there has been a transition from the initial state to a second state, based on a difference between the sensor data obtained in the initial state and the further sensor data. In other words, the method or logic within the mobile device may further determine a state transition. Transition detection may occur before, after or at the same time as state determination.

[0032] Optionally, the method or logic may be further configured to obtain additional sensor data from a plurality of the additional sensors if there has been a transition from the initial state to the second state.

[0033] Optionally, the method or logic may be further configured to determine there has not been a transition from the initial state to a second state if the difference between the obtained sensor data and obtained further sensor data does not exceed a predetermined threshold.

[0034] 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 or sent as a signal.

[0035] 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

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

[0037] FIG. 1 shows a schematic diagram of a mobile device in accordance with an embodiment of the present invention;

[0038] FIG. 2 is a flow diagram illustrating the steps taken by a mobile device for determining a context state transition and identifying a context state;

[0039] FIG. 3 is a schematic diagram illustrating an example of user context labelling, in accordance with an embodiment of the present invention; and

[0040] FIG. 4 is a schematic diagram illustrating an example of user context correction, in accordance with an embodiment of the present invention.

[0041] It should be noted that the figures are illustrated for simplicity and are not necessarily drawn to scale.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0042] Whilst various embodiments of the present invention are described below, the invention is not limited to these embodiments and variations of these embodiments may well fall within the scope of the invention which is to be limited only by the appended claims.

[0043] Further embodiments and specific examples may be found in the appended Annex, "Event-based Context Sampling and Online Interference with Mobile Devices", which is incorporated into this description.

[0044] FIG. 1 illustrates a mobile device in accordance with an embodiment of the present invention. Mobile device 10 comprises six sensors, 12a-12f, logic 14 stored in a suitable medium of the mobile device, such as a memory of the mobile device, and processor 16. Mobile device 10 is typically any portable device, such as a mobile telephone, a laptop computer, a personal digital assistance, etc. In other embodiments, the mobile device need not be easily portable, and, for example, could be a desktop computer.

[0045] Sensors 12a-12f are configured to accept input from the outside environment. For example, sensor 12a may be an ambient light sensor and may comprise a photosensitive detector adapted to measure a light level outside of mobile device 10. Sensor 12b may be an accelerometer and may be configured to measure an acceleration of mobile device 10 along a plurality of axes. Sensor 12c may be a GPS receiver and may be configured to measure a geographic position of mobile device 10, by receiving relevant data from GPS satellites. Sensors 12c-12f could comprise a network sensor, such as a radio transceiver adapted to receive communications from, and transmit them to, a mobile network of device 10.

[0046] Logic 14 is operatively connected to each of sensors 12a-12f and is configured to read a corresponding data output from each of sensors 12a-12f. Processor 16 is connected to logic 14 and is configured to read logic 14 so as to manipulate and process the data outputs read from sensors 12a-12f. Mobile device 10 may further comprise a memory (not shown) which may be configured to store data outputs read from sensors 12a-12f. Processor 16 may then be further configured to access data outputs stored in the memory, and manipulate these stored values, and may combine them with fresh data outputs read from one or more of sensors 12a-12f.

[0047] A database 19 may be used to store sensor data or representations of sensor data.

[0048] Mobile device 10 may determine its current state. In what follows, various advantages and particular implementations of the present invention are described.

[0049] The activity of a user may be considered as one of a number of discrete states--for instance, sitting at a desk, making a cup of coffee in the kitchen, having lunch in the work canteen, etc. A mobile device according to the present invention allows one to identify characteristics of a particular state as it is encountered and thereafter may determine the identity or category of the new state that has been entered. A process of `sensor fusion` may be used to derive a state that the individual (and their handset) has entered. By building up heuristic knowledge of the states that the user commonly enters, the mobile device can create a profile of the user and their most common (or habitual) states, and thereby use this for improving state recognition and/or predicting future states based on states that have already been encountered within a given time period.

[0050] For example, rather than simply using an accelerometer to determine movement, the mobile device may use algorithms across multiple sensor-based data sets to characterise the context of the individual. For instance, whilst in a meeting, an individual may leave their handset on the table, in a pocket, or be `fiddling` with it--each of these scenarios may be creating very different sensor profiles, but all pertain to the same static state of `in a meeting`.

[0051] 1. Context State Definition

[0052] The mobile device captures data from one or more sensors (accelerometer, digital compass, GPS receiver, Wi-Fi receiver, proximity sensor, Bluetooth receiver, Cell ID, microphone, ambient light sensor, etc.) and uses `sensor fusion` techniques and algorithms that are processed on the handset to create a unique fingerprint for the current context of an individual/handset (note that this fingerprint is not a static snapshot, but rather a characterisation created by sensor outputs within a specific temporal pattern and amplitude, and, when combined with the outputs of additional sensors, uniquely identify a state associated with an individual/handset). `Sensor fusion` is the term used to describe multiple sensors generating respective data outputs, these outputs then being read by logic of the mobile device so as to determine a particular state.

[0053] States may be defined as the characterisation of a context of an individual in such a way as to have semantic meaning, either to the individual or across a group of individuals. A `common` state most likely refers to a context that is linked to a place that is frequently visited (such as `home` or `work` on a macro level, or else `desk` or `canteen` on a micro level). An `ad hoc` state represents a transient context which is common across a group of individuals at a time and place (such as being stuck in a traffic jam on a motorway). When an `adhoc` state is repeated consistently (e.g., a traffic jam at a known traffic black spot), then such a state may then become a `common` state with a specific semantic tag (e.g. traffic jam on Heathrow Airport spur road). The respective outputs from multiple sensors of the mobile device may be used to characterise and assign an `output signature` to each of these states, or contexts.

[0054] 2. Context State Transition Triggering

[0055] Detecting the current state may be triggered by various conditions or simply achieved at regular and/or predefined intervals. In one embodiment, the mobile device may identify when a sensor output exceeds given thresholds, hence signalling a change in user state, possibly from a known state to an unknown state. The mobile device may be effectively moving from a static state to a dynamic one, and vice versa--e.g. getting up from your desk at work and walking to somewhere else. Upon transiting from one state to another (e.g. from a static state to a dynamic state), the mobile device may activate and analyse the outputs from additional sensors (sensor fusion) in order to identify what the new state is (e.g. as described under "Context state definition"). The sensors that are employed may depend on the type of state the user is transitioning into, e.g. location-based sensors for a static state, and activity-based sensors for a dynamic state.

[0056] 3. Context State Semantic Labelling & Correction

[0057] In order for the state information to be useful across a variety of different applications, it may be necessary to attach a semantic meaning to the state (at the very least, to those states that are common/habitual for the individual in question, or, alternatively, to all states, in which case generic tags may be used to describe ad hoc states that are common across multiple individuals, such as being in a traffic jam). There are multiple mechanisms that could be employed to attribute semantic meaning to each static state: [0058] States may be populated into an `inference` database and presented to the user for manual tagging and/or correction of inferred tags--to minimise the load on the user, this could be constrained to only common states. [0059] If the user uses a social media check-in service, then this semantic tag may also be used to tag that particular state recognised by the system (by leveraging public social media APIs to obtain details of the activity that the individual in question posted on the social media site). [0060] Similarly, if the individual uses #tags to represent their current context, this information could also be harvested by open Twitter APIs for semantic tagging. [0061] If the individual redeems a voucher (via their mobile handset) at a Point of Sale, then the information relating to which store the individual is in could also be used for semantically tagging the state (context) of the individual. [0062] If the user enters a state that is recognised as similar to an historic state recorded for another individual, then there may be the option of applying that state's tag to the user's state (effectively, a form of implicit crowd-sourcing of tags). Grouping state patterns across multiple users may generate a library of semantically tagged patterns against which the pattern/state of a new user can be compared, thereby determining the place of the user without the need for explicit training for that user.

[0063] Advantages of the present invention include: [0064] The invention may provide rich, real-time contextual information for a given user that can be used within a wide range of services. [0065] The invention may be carried out on a mobile device without the need for user interaction (although user interaction may improve performance, such as in the case of embodiments directed to labelling and correction). [0066] By recognising and historically creating a record of user states, the invention may provide context/state information to a 3rd party system without explicit user interaction (as would be the case with current social media systems that require the user to check-in manually each time a location is visited). In effect, a user would only have to `check-in` (i.e. semantically tag) a location (state) once, and thereafter the system could automatically `check-in` the user whenever that place was visited. [0067] Furthermore, the invention may (but not necessarily does) operate entirely on the handset without sending user data to 3rd parties, hence protecting the privacy of the user (i.e. contextual information may be derived on the handset and provided solely to applications on the handset to which the user has granted authorisation to use that information)--in doing so, the user is given a greater degree of privacy and control over the use of the data.

[0068] The present invention may be used in various different applications, examples of which are described below.

[0069] Transport (Traffic Congestion)

[0070] By defining journey paths as a succession of states (waypoints), common states (waypoints) across a multitude of users may indicate traffic blackspots (either historically or at a particular time). Note that, in this example, it may be assumed that a state may only be triggered when the user/car is deemed to have stopped (e.g. transitioned from a dynamic, moving state to a static, stationary state). As well as identifying traffic congestion, the invention could also be used to determine which motorway service stations are most popular for people on a journey travelling between two given points.

[0071] Shopping Mall

[0072] The invention may provide an effective solution for determining which store a user has visited, or is currently in, by identifying a unique state for each store (e.g., a combination of data outputs relating to location, movement, ambient lighting and ambient noise, determined through the mobile device's sensors). Taking a semantic approach to identifying which stores a user has visited obviates the need to deploy dedicated infrastructure for providing indoor positioning.

[0073] Network Optimisation

[0074] The invention may compare user state (context) against behaviour to identify where entering a given state might lead to a common behaviour (service usage). By linking behaviour with state, and predicting states across multiple users, a mobile network operator may then predict likely demand (usage) of services, and hence optimise the mobile network accordingly. This may include noting which content is downloaded when users enter a given state (which in this case may be defined according to the data outputs read from location sensor and a time sensor), and precaching content accordingly, based on the number of users likely to be entering that state (place) in a given timeframe.

[0075] Network Offload

[0076] Increasingly, mobile network operators are looking at various network offload strategies that leverage small cell technologies (e.g. Wi-Fi and Femto cells) to better manage and optimise the capacity and service offered by a cellular network. With the present invention, it may be possible for handsets to search for WiFi points at the moment of state transition rather than periodically, hence increasing the likelihood of a WiFi network being joined as soon as the user arrives at a new destination, and increasing battery efficiency. This is in contrast to handsets continually polling for available WiFi networks.

[0077] Enterprise Presence

[0078] Awareness of a state or changes of state could be used in an enterprise context for providing more accurate presence information. Typically, personal computer systems monitor keyboard activity as an indicator of whether an individual is available or `away`, but this can deliver false information if, for instance, the individual is reading at their desk, or is engaged in a conference call, rather than actively using the PC keyboard. With the present invention, using the mobile handset as a trigger point in addition to the keyboard, the resulting enriched presence system would have a better understanding of the individual's actual context. By building up a time-stamped record of the states that a user enters, it may be possible to start predicting which state an individual might be transitioning to either on a short-term basis (e.g. `has left desk, predict going to office canteen`) or a longer-term basis (e.g. populating the user's calendar with availability information for the use of other individuals--e.g. `David tends to work from home on a Friday so don't book meetings at the office location, but a conference call would be acceptable`).

[0079] User Profiling

[0080] By building up a record of the states (places) that are common to an individual, it becomes possible to assign semantic inference to that individual. For instance, a high proportion of states tagged as relating to shopping may be a leading indicator that the individual in question likes to shop (or works in a shop).

[0081] FIG. 2 illustrates the steps taken in a method according to a preferred embodiment of the present invention. In this embodiment, a mobile device (e.g. mobile device 10 of the embodiment described above) determines that a state transition has occurred, and in particular may determine when the mobile device has transitioned from a known state to an unknown state. The mobile device may then identify the unknown state, thereby rendering it a known state.

[0082] In step 21, an internal clock in the mobile device advances one timestep forwards. An arbitrary time unit may be used, such as ten seconds. Thus, the mobile device may perform method 20 every timestep, for example every ten seconds.

[0083] In step 22, the mobile device takes a motion reading from a motion sensor (e.g. an accelerometer). The received data is a vector describing component-wise intensity of motion. If the mobile device is stationary, for example, then the motion sensor reads a motion vector of zero intensity for all three components. If the mobile device is moving at a constant velocity (constant magnitude and direction), then the motion sensor may read the corresponding intensity of motion.

[0084] In step 23, the mobile device classifies whether the device is in a `static` or a `dynamic` state, given the current motion vector. The mobile device may use a low-pass filter in series with a pre-trained binary classifier, together with a moving average filter (which stores a short history of previous binary classifier outputs). Further details of this step are described in the Annex especially with reference to FIG. 2 of the Annex.

[0085] In step 24, the mobile device determines whether the output state type at this timestep is equivalent in {0,1} to the previous timestep's output state type. If yes, no transition is classified, and the next iteration may begin. If no, a transition is classified, triggering the inference process and beginning the next timestep iteration.

[0086] Determining the state of a mobile device starts at step 25. The new context state type (static or dynamic) may have been determined at step 23. If so determined, the mobile device 10 may obtain, acquire or take a set of data samples from that particular type's sensors or from any or all of the sensors. The mobile device 10 may then derive a fingerprint or vector representation of the obtained sensor data. A determination may be made as to whether the present or initial state of the mobile device 10 matches a previous state or a state that has previously been observed or encountered. If no match is made then the initial state may be determined to be a new, previously unvisited state. The determination or match may be carried out on vector representations of the data preferably using statistical inference including frequentist and Bayesian or Hotelling's T.sup.2 distribution.

[0087] Example inference techniques are described in the Annex under "Inference and Classification" on page 10.

[0088] If the state is a previously unvisited state, then the mobile device may assign a different label to the classified or initial state (step 26). If the state is a previously visited state, the mobile device may assign the label of the identified previously visited state to the newly classified state (step 27). This state may now be an instance of the previously visited state and may be stored in database 19, preferably within the mobile device 10. In order to classify a new state, the mobile device may assign a new, unique label to the newly classified state. This state is now the first instance of the newly labelled state. In step 28, the inference process terminates.

[0089] FIG. 3 illustrates a method of determining a state of a mobile device, in accordance with a preferred embodiment of the present invention. A state may be described by a set of codebook vectors or fingerprints of the sensor data. Once a state has been identified, the user may assign a human-readable label to the state. Once assigned, the label may be displayed to the user on future classifications of the state (e.g. in FIG. 3, state #1234). Before this label is applied, the state may be identified only by a unique ID assigned by the identification process. Through an interface, the user may label the state and, upon labelling, all instances of that state (both past and future) may be associated with this label unless re-labelled.

[0090] FIG. 4 illustrates a method of user context creation. The user may correct the system identification which, in turn, may affect future system outputs. There are three types of corrective action:

[0091] Add: The user creates a state that partially overwrites (in the database or other storage facility within or external to the mobile device 10) one or more identified states. The states that are partially overwritten by this new state may be used to create the codebook vectors for the new state, and the user's new label is assigned to it. Furthermore, it is assigned a unique ID by the system.

[0092] Edit: There are two types of edit for an identified state: i) the user re-labelling the identified state as a previously labelled state (Case 1); and ii) the user re-labelling the identified state as a new, previously unidentified state (Case 2).

[0093] Delete: The user removes an identified state. If there is only one instance of this state, it is removed entirely. If not, this instance alone is removed and previous updates to the codebook vectors are undone.

[0094] In FIG. 4, at step 42, the state with the label `Desk` exists, and so, upon user correction, the sensor data from the incorrect instance of `Meeting` may be used to update the codebook vectors for the state `Desk`. At step 44, the state with the label `Cafe` does not exist, and so a new state is created with a unique ID and label `Cafe`. The sensor data from the incorrect instance of `Meeting` are used to create the codebook vectors for the state `Cafe`.

[0095] 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.

[0096] For example, the database may be external to the mobile device, with data being transferred across a mobile network. The previous data may have been acquired from a different mobile device or may be synthetic data.

[0097] 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

1. A method of determining a state of a mobile device, the mobile device having one or more sensors, the method comprising the steps of: obtaining sensor data from the one or more sensors of the mobile device in an initial state; and determining if the initial state matches a previous state by comparing the obtained sensor data to previous sensor data acquired with the mobile device in the previous state, wherein the comparison of the obtained sensor data to the previous sensor data is carried out on vector representations of both data.

2. The method of claim 1, wherein the comparison uses, statistical inference, frequentist inference, Bayesian inference, or Hotelling's T.sup.2.

3. The method according to claim 1, wherein the previous sensor data is retrieved from a database of sensor data acquired with the mobile device in different states.

4. The method of claim 3 further comprising the step of storing the obtained sensor data of the mobile device in the first state in the database when no matches are found.

5. The method according to claim 1, wherein the previous sensor data is stored in a database as vector representations.

6. The method according to claim 1 further comprising the step of selecting a previous state to compare with the initial state based on a nearest-neighbour search of the sensor data.

7. The method according to claim 1 further comprising the step of selecting a previous state to compare with the initial state by determining the most commonly matched previous states.

8. The method according to claim 1, wherein the sensors of the mobile device are one or more selected from the group consisting of: an accelerometer, a digital compass, a GPS receiver, a microphone, an ambient light sensor, a thermometer, a radio receiver, a proximity sensor, a Bluetooth receiver and a Wi-Fi receiver.

9. The method according to claim 1 further comprising the step of receiving a state identifier for the initial state and/or the previous states.

10. A mobile device comprising: one or more sensors; and logic configured to: obtain sensor data from the one or more sensors of the mobile device in an initial state; determine if the initial state matches a previous state by comparing the obtained sensor data to previous sensor data acquired with the mobile device in the previous state, wherein the comparison of the obtained sensor data to the previous sensor data is carried out on vector representations of both data.

11. The mobile device of claim 10, wherein the comparison uses, statistical inference, frequentist inference, Bayesian inference, or Hotelling's T.sup.2.

12. The mobile device according to claim 10 further comprising a database configured to store sensor data acquired with the mobile device in different states.

13. A computer program comprising program instructions that, when executed on a computer cause the computer to perform the method of claim 1.

14. A computer-readable medium carrying a computer program according to claim 13.

15. A computer programmed to perform the method of claim 1.