GB2514546A

GB2514546A - Communication system

Info

Publication number: GB2514546A
Application number: GB1309342.2A
Authority: GB
Inventors: Olivier Dong
Original assignee: NEC Corp
Current assignee: NEC Corp
Priority date: 2013-05-23
Filing date: 2013-05-23
Publication date: 2014-12-03
Also published as: WO2014188827A1; GB201309342D0

Abstract

A communication device 3 is described, which controls interaction between applications 47 and another communication device 2-1, 2-2, 2-3, 2-4 accessible via said communication device. The communication device obtains information identifying the other communication device, and information identifying each (or a list of local or remote) application(s) authorised to interact with that other communication device. When a request is received from an application to interact with the other communication device, the communication device determines 49, using said obtained information, whether or not said requesting application is authorised to interact with the other communication device; and allows or rejects the interaction in dependence on a result of said determination. One embodiment is such that only particular application(s) can access data from a particular sensor 2-3, 2-4 with e.g. application specific access. When the device is embodied as a smartphone or tablet 3 the authorisations may be obtained from a Open Mobile Alliance Device Management (OMA DM) entity or SIM card/UICC 38 which may be updated by a provisioning server 55 by way of Universal SIM Application Toolkit (USAT) refresh message. The other communication device(s) may, for example, be sensor(s) in a Machine-Type Communication (MTC) arrangement. Devices/sensors may be identified by Bluetooth or MAC addresses and used in conjunction with a list of associated authorised applications (e.g. application names). Data obtained from the external device(s) and stored at the device may be access controlled such that the data is only accessible by authorised applications.

Description

tM:;: INTELLECTUAL .*.. PROPERTY OFFICE Applieslion No. (3BI309342.2 RTM Dale:15 November2013 The following terms are registered trade marks and should be read as such wherever they occur in this document: 3GPP

LTE

UMTS

Bluetooth Zigbee Android Intellectual Properly Office is an operaling name of Ihe Patent Office www.ipo.gov.uk Communications System The present invention relates to a communications system. The invention has particular but not exclusive relevance to wireless communications systems and devices thereof operating according to the 3rd Generation Partnership Project (3GPP) standards or equivalents or derivatives thereof. The invention has particular although not exclusive relevance to the control of access to Machine-Type Communications devices.

The latest developments of the 3GPP standards are referred to as the Long Term Evolution (LTE) of EPC (Evolved Packet Core) network and E-UTRAN (Evolved UMTS Terrestrial Radio Access Network). Under the 3GPP standards, a NodeB (or an eNB in LTE) is the base station via which communications devices connect to a core network and communicate to other communications devices or remote servers. For simplicity, the present application will use the term base station to refer to any such base stations. Communications devices might be, for example, mobile communications devices such as mobile telephones, smartphones, user equipment, personal digital assistants, laptop computers, tablet computers, web browsers, e-book readers and the like. Such mobile (or even generally stationary) devices are typically operated by a user. However, 3GPP standards also make it possible to connect Machine-Type Communications (MTC) devices (sometimes also referred to as Machine-to-Machine (M2M) communications devices) to the network, which typically comprise automated equipment, such as various measuring equipment, telemetry equipment, monitoring systems, sensor devices, tracking and tracing devices, in-vehicle safety systems, vehicle maintenance systems, digital billboards, point of sale (POS) terminals, remote control systems and the like. M2M devices can be implemented as a part of a (generally) stationary apparatus such as vending machines, roadside sensors, POS terminals, although some M2M devices can be embedded in non-stationary apparatus (e.g. vehicles) or attached to animals or persons to be monitored/tracked.

For simplicity, the present application refers to sensors in the description but it will be appreciated that the technology described can also be implemented using any type of M2M devices other than sensors. It will also be appreciated that the technology described can be implemented on any (mobile and/or generally

I

stationary) communications device that can connect to a communications network for sending/receiving data, regardless whether such communications device is controlled by human input or software instructions stored in memory.

The so-called M2M gateway and the M2M device are architectural entities defined by the European Telecommunications Standards Institute (ETSI). An M2M gateway is an M2M device which also supports proxy functionality (i.e. it is capable of aggregating data to/from other M2M devices). Both the M2M gateway and the M2M device are able to connect to the network directly and they may also include local applications.

Recently it has been suggested to allow user equipment (e.g. smartphones and/or tablet computers) to function as M2M gateways and thus facilitate the communication between M2M devices and other devices. In this case, communication between M2M devices (e.g. sensors collecting healthcare data) and user equipment configured as M2M gateways may be carried out using standardised (wired or wireless) communication technologies. Examples of such communications technologies include, for example, the Bluetooth (BT) and Bluetooth Low Energy (BLE or Bluetooth 4.0) technologies defined by the Bluetooth Special Interest Group (SIG).

M2M applications are becoming increasingly widespread and it is foreseen that the evolution of the M2M ecosystem will address at least two main usage categories: i) professional oriented and U) personal oriented.

Professional oriented use cases comprise, for example, smart grids, smart meters, fleet management, smart buildings, etc., which currently include the majority of deployed M2M solutions.

On the other hand, it is also expected that M2M devices will be deployed on a large scale for at least the following personal oriented use cases: -Body Area Network: body sensors such as glucose meters, heart rate monitors, peacemakers, and the like.

-Personal Area Network: activity monitors such as footpods, bike speed/ cadence sensors, and the like.

-Home Area Network: temperature/humidity sensors, presence detectors, etc. In accordance with the above described personal use cases, compatible user equipment (e.g. a mobile telephone, a smartphone, a tablet computer and the like) can be used as an M2M gateway. In this case, some M2M sensors (e.g. sensors collecting healthcare data) may be connected to the user equipment using an appropriate wireless connection, e.g. a Bluetooth connection.

However, the Bluetooth implementation is mainly bound to standard profiles' defined by the Bluetooth SIG. This ensures that communications devices implementing the same profile can interwork together seamlessly and hence it makes developing and/or deploying a Bluetooth based ecosystem easier and less costly than a system which uses proprietary interfaces (or proprietary profiles).

The standard profiles also ensure that data collected using one of such standard profiles (e.g. data collected by a heart rate belt using the standardized Bluetooth Low Energy Heart Rate Monitor BLE HRM' profile) is accessible by any application supporting the profile used by that application. Although it might have certain benefits for the user of the communications device wishing to process the collected data (e.g. the user has more flexibility in analysing/displaying the data), there is a potential risk that sensitive data (e.g. personal health data, house monitoring data, and the like) can be accessed by other users and/or other communications devices without the owner's knowledge and/or consent. Such privacy issues may soon become more serious considering that smartphones/tablets will be more and more likely to be used as M2M gateways (or M2M devices) in personal oriented M2M use cases. Therefore, there is a need to prevent unauthorised access to potentially sensitive data handled (e.g. collected and/or stored) by such M2M devices and gateways.

In the past, this issue has been addressed by implementing proprietary profiles for specific use cases (e.g. an M2M service provider can decide to provide its own application(s) and/or sensor(s) that support a proprietary profile that is not understood by any application/sensor other than their own). However, such a solution does not conform to the general trend for collaborative/standardised approaches to provide better interoperability, is likely to create fragmentation and may result in a poor user experience due to the relative inflexibility and/or incompatibility of their user equipment with the proprietary profiles.

Accordingly, preferred embodiments of the present invention aim to provide methods and apparatus which address or at least partially deal with the above needs.

Although for efficiency of understanding for those of skill in the art, the invention will be described in detail in the context of a 3GPP system (UMTS, [TE), the principles of the invention can be applied to other systems in which communications devices or User Equipment (UE) access MTC devices using a (wired or radio) communications technology.

In one aspect, the invention provides a communication device for controlling interaction with another communication device accessible via said communication device, the communication device comprising: means for communicating data with said other communication device; means for obtaining: i) information identifying said other communication device, and U) information identifying each application authorised to interact with said other communication device; means for receiving a request for an application to interact with said other communication device, wherein said request is configured to identify said application; means for determining, using said obtained information, whether or not said requesting application is authorised to interact with said other communication device; and means for controlling interaction between said application and said other communication device in dependence on a result of said determination.

The communication device may further comprise means for storing data obtained from said other communication device by said data communicating means, in which case the controlling means may be operable to control access to said obtained data by said requesting application in dependence on said result of said determination.

The obtaining means may be operable to obtain said information identifying said other communication device based on a Bluetooth and/or Media Access Control (MAC) address associated with said other communication device. The obtaining means may be operable to obtain information identifying each respective application based on a name associated with that particular application.

The request to interact may comprise at least one of a request to establish a data connection with said communications device, a request to access data associated with said communications device, and a request to obtain information on said other communication device.

The controlling means may be operable to allow said request if said determining means determines that said requesting application is authorised to interact with said other communication device. The controlling means may be operable to reject said request if said determining means determines that said requesting application is not authorised to interact with said other communication device.

The obtaining means may be operable to obtain said information by communicating with an Open Mobile Alliance Device Management (OMA DM) entity. The obtaining means may also be operable to obtain said information by communicating with subscriber identity module (SIM), for example, a universal integrated circuit card (UICC). In this case, the SIM/UICC may be operable to provide said information by sending at least one message, for example, a universal SIM application toolkit (USAT) refresh message. The SIM/USAT may be operable to obtain said information from a provisioning server entity.

The communication device may further comprise means for providing gateway functionality for said other communication device.

The communication device may further comprise means for executing said requesting application and wherein said requesting application is installed locally on said communication device.

The other communication device may be connected to said communication device via at least one further communication device.

The other communication device may comprise a machine-type communication (MTC) device, for example, a sensor.

The communicating means may be operable to use at least one of a Bluetooth communication technology, a Bluetooth Low Energy (BLE) communication technology, a Zigbee communication technology, and an ANT-'-communication technology.

The communication device may comprise a mobile communication device. For example, the communication device may comprise at least one of a mobile telephone, a tablet computer, and user equipment in accordance with the Long Term Evolution ([TE) standard.

In one aspect, the invention provides a universal integrated circuit card (UICC) for use with a communication device, the UICC comprising: means for holding information identifying: i) at least one communication device other than said communication device, and H) a respective set of at least one application authorised to interact with said at least one other communication device; and means for communicating said information to said communication device for use, by said communication device, in controlling interaction between said at least one other communication device and at least one application associated with said communication device.

The held information may comprise at least one record for each one of said at least one other communication device and each record may include said information identifying said other communication device and respective applications that are authorised to interact with said other communication device.

The holding means may be operable to hold said information as elementary file (FE) data.

In another aspect, the invention provides a communication device for controlling interaction with another communication device accessible via said communication device, the communication device comprising a transceiver and a processor. The transceiver is configured to communicate data with said other communication device; the processor is configured to obtain: i) information identifying said other communication device, and H) information identifying each application authorised to interact with said other communication device. The transceiver is configured to receive a request for an application to interact with said other communication device, wherein said request is configured to identify said application. The processor is configured to determine, using said obtained information, whether or not said requesting application is authorised to interact with said other communication device, and control interaction between said application and said other communication device in dependence on a result of said determination.

The invention also provides corresponding methods and a system comprising the above communication devices.

A further aspect of the present invention provides a computer program product comprising computer implementable instructions for causing a programmable computer device to become configured as a communication device as described above. The computer software products may be provided on a carrier signal or on a recording medium, such as a CD, DVD or the like.

Embodiments of the invention will now be described, by way of example, with reference to the accompanying drawings in which: Figure 1 illustrates schematically a communications system to which embodiments of the invention may be applied; Figure 2 is a block diagram of a mobile telephone forming part of the system shown in Figure 1; Figure 3 illustrates schematically the components and interfaces using which embodiments of the invention may be implemented; and Figure 4 is an example timing diagram illustrating a method carried out by components of the communications system shown in Figure 1.

Overview Figure 1 schematically illustrates a communications network 1 in which MTC devices 2, a gateway mobile device 3 (in this example a mobile telephone), and other communications devices can communicate with each other and/or other communications devices via a wired and/or a wireless connection. Figure 1 corresponds generally to the M2M architecture agreed by the ETSI. As shown, the communications network 1 includes an application domain' part, a network domain' part, and a device domain' part. In this specific example, the mobile telephone 3, acting as an M2M gateway, provides access to the network domain (and hence to other parts of the communications network 1) for a number of MTC devices 2 (e.g. sensor devices) located in the device domain. The mobile telephone 3 is referred to as gateway mobile telephone' 3 in the following when it is operating as an M2M gateway.

Communication between the devices may be carried out via a base station 5 (e.g. eNB) and/or a wired communication node 6 (e.g. a server, a router, or the like) provided in the network domain, which may also include a positioning satellite 7, such as a satellite forming part of a Global Navigation Satellite System (GNSS).

Applications in the application domain may thus exchange data with the MTC devices 2 via the base station 5 and/or the wired communication node 6 and the gateway mobile telephone 3. Although not shown, some MTC devices 2 may also connect to the base station 5 and/or the wired communication node 6 directly, i.e. without involving the mobile telephone 3.

As those skilled in the art will appreciate, whilst one mobile telephone 3, one base station 5, and ten MTC devices 2 are shown in Figure 1 for illustration purposes, the system, when implemented, will typically include other base stations and other mobile telephones and/or MIG devices.

In this exemplary system, the MTC devices 2 beneficially use standard interfaces (e.g. standard Bluetooth profiles) to communicate with the mobile telephone 3.

Data generated/collected by these MTC devices 2 may thus be exchanged with the mobile telephone 3 (or other devices connected to it) and/or stored in its non-volatile memory without necessitating the mobile telephone 3 to implement specific interfaces/profiles for each type of MTC device 2.

The MTC devices 2 are also able to communicate data to the gateway mobile device 3 by hopping' the data, node-to-node, via MTC device nodes 2 of an ad hoc mesh network 4 (e.g. provided using a communication protocol of the Zig Bee ® standard or the like).

Various applications may be installed on the mobile telephone 3 by its user (although applications may also be hosted externally and accessed via the mobile telephone 3). Using one or more of such applications, the user of the mobile telephone 3 can thus access his/her connected MTC devices 2 and/or the data provided by these MTC devices 2.

The gateway mobile telephone 3 shown in Figure 1 also includes a so-called MTC access controller which ensures that data provided by each MTC device 2 is only made available to those applications that are authorised to do so. This is achieved by the MTC access controller managing the setting up of communication links between each application and each respective MTC device 2 connected to the gateway mobile telephone 3. Although by default each MTC device 2 may be made accessible to any application installed on (or accessed through) the gateway mobile telephone 3, in this case, the use of some MTC devices 2 is restricted to certain applications only. Therefore, at least those MTC devices 2 that are restricted to selected applications are added to a list maintained by the MTC access controller along with an identification of any application that is authorised to access that particular MTC device 2.

Whenever an application tries to set up a communication channel to an MTC device 2 using the mobile telephone's 3 standard (e.g. Bluetooth) communication protocol, the application's request is routed via the MTC access controller, which verifies that the requesting application is allowed to do so. If the requesting application is included in the list of authorised applications (for that particular MTC device 2) held by the MTC access controller (or not included in the list of unauthorised applications), then it will be able to connect to that MTC device 2. An application's attempt to set up a communication link with an MTC device 2 that it is not authorised to use will be rejected by the MTC access controller. For example, the MTC access controller may determine that an application is not allowed to use a particular MTC device 2 if that application is not included in the list of authorised applications for that MTC device 2 (or it is included in a list of unauthorised applications). In a similar manner, the MTC access controller also controls each application's access to data from connected MTC devices 2 stored locally at the gateway mobile telephone 3 (e.g. in a non-volatile memory). Therefore, it is possible for MTC devices 2 (e.g. sensors) to generate and send data to the gateway mobile telephone 3 even if no authorised applications are run on the mobile telephone 3 whilst the data is being generated.

By using a list of connected MTC devices 2 and respective authorised applications by the MTC access controller, access to potentially sensitive user data from an MTC device 2 (e.g. a medical device, such as a heart rate sensor and the like) is granted to the selected application(s), without requiring the mobile telephone 3 (and/or the MTC device 2) to rely on proprietary communication techniques.

Mobile Telephone Figure 2 is a block diagram illustrating the main components of the mobile telephone 3 shown in Figure 1. As shown, the mobile telephone 3 has a transceiver circuit 31 that is operable to transmit signals to and to receive signals from a base station 5 and to transmit signals to and to receive signals from an MTC device 2 via one or more antenna 33. The mobile telephone 3 has a controller 37 to control the operation of the mobile telephone 3 and a removable and replaceable subscriber identity module which, in this embodiment, comprises a Universal Integrated Circuit Card (UICC) 38. The controller 37 is associated with a memory 39 and is coupled to the transceiver circuit 31. The mobile telephone 3 might of course have all the usual functionality of a conventional mobile telephone 3 (such as a user interface 35) and this may be provided by any one or any combination of hardware, software and firmware, as appropriate. Software may be pre-installed in the memory 39 and/or may be downloaded via the telecommunications network or from a removable data storage device (RMD), for

example.

The controller 37 is configured to control overall operation of the mobile telephone 3, and interaction with the UICC 38, by, in this example, program instructions or software instructions stored within memory 39. As shown, these software instructions include, among other things, an operating system 41, a communications control module 43, a UICC module 45, an applications module 47, and an MTC access controller module 49.

The communications control module 43 controls the communication between the mobile telephone 3 and other communications devices, such as MTC devices 2, other mobile telephones 3, or the base station 5.

The UICC 38 has its own processing capability (not shown) and comprises a local memory 48 that holds a list of applications and respective authorised MTC devices 2 that can be used by each application. The UICC 38 obtains and updates this list by communicating with a provisioning server entity, which may be either a remote (e.g. network based) entity or a local entity provided on or via the mobile telephone 3. The UICC 38 provides the list of MTC devices 2 and authorised applications to the MTC access control module 49.

The UICC module 45 manages the interaction with the UICC 38 and access to the information stored in the local memory of the UICC 38 via interfaces defined by 3GPP and/or ETSI.

The applications module 47 manages applications installed on the mobile telephone 3 and controls their access to the other modules of the mobile telephone 3. When an application initiates communication with an MTC device 2 (or attempts to read data provided by an MTC device 2), the applications module 47 routes the application's communication via the MTC access controller module 49.

The MTC access controller module 49 controls each application's access to the MTC devices 2 (e.g. sensors) in dependence on the information stored on the UICC 38. The MTC access controller module 49 maintains information identifying each (known) MTC device 2 and associated privileges for applications that are authorised to communicate with a particular MTC device 2. The MTC access controller module 49 obtains a list (and possible updates) of applications and respective authorised MTC devices 2 from the UICC 38.

In the above description, the mobile telephone 3 is described for ease of understanding as having a number of discrete modules (such as the communications control module and the MTC access controller module). Whilst these modules may be provided in this way for certain applications, for example where an existing system has been modified to implement the invention, in other applications, for example in systems designed with the inventive features in mind from the outset, these modules may be built into the overall operating system or code and so these modules may not be discernible as discrete entities. These modules may also be implemented in software, hardware, firmware or a mix of these.

Operation A more detailed description will now be given (with reference to Figures 3 and 4) of the scenario discussed above where a mobile telephone 3 acting as an M2M gateway controls the access of applications to an MTC device 2.

Figure 3 illustrates schematically the components and interfaces using which embodiments of the invention may be implemented.

As can be seen, a number of applications (e.g. App 1' to App N') are provided locally via the applications module 47 of the mobile telephone 3. Remote applications (e.g. App X' operated by a remote user/operator) may also be connected to the mobile telephone 3, for example, via the transceiver circuit 31.

The communications control module 43 supports a number of communication technologies, such as Bluetooth, ANT+, Zigbee, and so on. Using one or more supported communication technologies, MTC devices 2-1 to 2-4 (denoted Sensor 1' to Sensor 4' respectively) can connect to the mobile telephone 3 (and possibly to other communication devices if the mobile telephone 3 is acting as an M2M gateway).

There is a standard (e.g. operating system specific) application programming interface (API) provided between the applications and the other modules of the mobile telephone 3. Thus using the API, each application can also communicate with the MIC devices 2 (via the MTC access controller module 49 and the communications control module 43).

The MTC access controller 49 holds information relating to which applications are authorised to use which MTC device 2 via this mobile telephone 3. Preferably, such authorisation information' is stored in the form of a list, although it may also be stored as a table or in any suitable format understood by the MTC access controller 49.

In this example, Sensors 1 and 2 (i.e. MTC devices 2-1 and 2-2) can be accessed by any compatible application. For example, if MTC device 2-1 is a Bluetooth enabled sensor using a particular (standard) Bluetooth profile, any application which supports that profile can access that MTC device 2-1 (and/or read data provided by this sensor). Therefore, whenever an application requests to form a data connection to such a regular' (or non-restricted) MTC device 2, the MTC access controller 49 (after carrying out a verification using the stored authorisation information) allows them to connect and exchange data with each other. In this example, the authorisation information may comprise an (explicit or implicit) indication that the given MTC device can be used by any application.

However, some MTC devices (in this example, MTC devices 2-3 and 2-4) are restricted for use by specific applications only. In this case, since communication between the applications and the sensors / MTC devices 2 is carried out via the MTC access controller 49, access to such application specific MTC devices can be provided according to each application's access privileges.

For example, if MTC device 2-3 (denoted Sensor 3') comprises a Bluetooth enabled sensor using a particular (preferably standard) Bluetooth profile and only one application (e.g. App 1') is allowed to use that MTC device 2-3, the MTC access controller 49 (through which communication is effected) grants access to the authorised application (App 1') only and rejects/discards any communication attempt by other, non-authorised applications (e.g. App 2'). The MTC access controller 49 allows/rejects communication with the MTC device 2-3 in accordance with the authorisation information applicable for that MTC device I application pair.

The mobile telephone 3 also has an UICC 38 which is coupled to the MTC access controller 49 (via the UICC module 45). The UICC 38 provides information to the MTC access controller 49 on applications installed on (or used via) the mobile telephone 3. This information comprises the authorisation information used by the MTC access controller 49 in managing the connection between respective applications and connected MTC devices 2. For example, the UICC 38 may provide (or update) the authorisation information whenever a new application is allowed (by the M2M Service Provider) to access a particular MTC device 2 and/or whenever a new MTC device 2 (or a new type of MTC device 2) is deployed by the M2M Service Provider (but preferably before the MTC device 2 is connected to the mobile telephone 3 for the first time). Therefore, before any communication is attempted between an application and an MTC device 2, the MTC access controller 49 is able to obtain the applicable authorisation and allow/reject the communication attempt accordingly.

As mentioned above, the MTC access controller 49 also controls the applications' access to data already obtained from the MTC devices 2 (and possibly stored in memory of the mobile telephone 3). For example, such stored data may comprise data obtained from an MTC device 2 before the user started an application trying to communicate with that MIC device 2. In this case, although the data (or part of it) is stored locally on the mobile telephone 3, it is treated as data belonging to that MIC device 2 and hence it is only made accessible for authorised applications.

Figure 4 is an example timing diagram illustrating a method carried out by components of the communications system 1 shown in Figure 1. In particular, Figure 4 illustrates how the MTC access controller 49 allows/rejects establishing communication between applications and MTC devices 2 in dependence on the applicable authorisation information. In this case, the exemplary MTC device 2-4 comprises a sensor (Sensor 4').

As illustrated generally at steps 5400 and 5402, the MTC access controller 49 initially obtains information identifying a particular sensor (or sensors) and associated applications that are authorised to use that sensor (or sensors). In order to do so, the MTC access controller 49 reads data from the UICC 38, in step 5400. In this example, the data returned by the UICC 38, at step 5402, identifies MTC device 2-4 (Sensor 4') and that one application (identified by a suitable identifier, e.g. an associated unique application ID), App 1' is allowed to use (e.g. communicate with) this MTC device 2-4. Although not shown in step S402, the data from the UICC may list further MTC device(s) and respective applications that are allowed to use each further MTC device.

As generally shown at step S404, the mobile telephone 3 obtains data, in this example, from the MTC device 2-4 using its MTC access controller 49. The MTC access controller 49 stores any obtained data in memory 39. Although step S404 is shown to take place after step S402, it will be appreciated that it may take place any time, e.g. before step S400. Further, it will be appreciated that data may be received from the MTC device 2-4 in more than one step, e.g. using periodical/segmented transmissions and/or using a substantially continuous transmission. Further, step 5404 may be preceded by a request (not shown).

When in step 5406 an application identified as App 2' requests to be connected to the MTC device 2-4, the MTC access controller 49 compares the identifier provided by this application to the list of authorised applications and finds that this application is not allowed to use that particular MTC device 2-4 (since only App 1' has been authorised by the UICC at step 5402). Therefore, in step S408, the MTC access controller 49 rejects the unauthorised application's request and possibly indicates the reason for rejection as well (i.e. in this case, App 2' is not allowed to use Sensor 4'). The App 2' application may also display a warning/error message to the user of the mobile telephone 3 informing the user that this application is not authorised to use the selected sensor.

However, when in step S41 0 a different application (identified as App 1') requests to be connected to the MTC device 2-4, the comparison by the MIC access controller 49 indicates that the identifier provided by this application is included in the list of authorised applications. Therefore, this application is allowed to use the MIC device 2-4 (since App 1' has been authorised by the UICC at step 5402).

Therefore, in step S412, the MTC access controller 49 accepts the application's request and sets up a communication path between App 1' and the MTC device 2-4. As generally shown in step S414, the authorised application (App 1') and the MIC device 2-4 (Sensor 4') are now connected and are able to exchange data using the communication path provided between them. The MTC access controller 49 also grants the authorised application access to any data previously obtained from this MTC device 2-4 (e.g. in step S404) that is stored in memory 39.

If the authorised App 1' application no longer needs to use the MTC device 2-4, it terminates the connection between them, as shown in step S416. However, if App 1' needs to exchange further data with the MTC device 2-4, it can send a new request to the MTC access controller 49 (e.g. by returning to step 5410) and a new communication path will be set up between them as long as the App 1' application is authorised to use that MTC device 2-4. In other words, steps S410 to 5414 can be repeated whenever the App 1' application needs to exchange data with Sensor 4'.

As indicated generally at step 5420, a provisioning server entity 55 can update the list of authorised applications by sending data to the UICC 38, which in turn informs the MTC access controller 49 to refresh the stored authorisation information (if any). In order to do so, the UICC 38 generates and sends, in step S422, a universal SIM application toolkit (LJSAT) Refresh' command to the MTC access controller 49, which causes the MTC access controller 49 to read new/updated data from the UICC 38, as indicated in step S424. In this example, the data returned by the UICC 38, at step 5426, identifies the same MTC device 2- 4 (Sensor 4') and that two applications (identified by their suitable identifiers, e.g. an associated unique application ID), App 1' and App 2' are allowed to use (e.g. communicate with) the MTC device 2-4 identified as Sensor 4'. Although not shown in step S426, the data from the UICC may list further MTC device(s) and respective applications that are allowed to use each further MTC device.

The MTC access controller 49 updates the authorisation information it holds and grants/rejects each applications access to MTC devices 2 accordingly.

For example, if the App 2' application subsequently requests, in step S430, to be connected to the MIC device 2-4, the MIC access controller 49 compares the identifier provided by this application to the list of authorised applications and finds that this application is now allowed to use the MTC device 2-4 (since App 1' and App 2' have been authorised by the UICC at step S426).

Therefore, in step 5432, the MTC access controller 49 accepts the application's request (in accordance with the updated authorisation data) and sets up a communication path between App 2' and the MTC device 2-4. As generally shown in step S434, the authorised application (App 2') and the MTC device 2-4 (Sensor 4') are now connected and are able to exchange data using the communication path provided between them. The MTC access controller 49 also grants the authorised application access to any data previously received from this MTC device 2-4 (e.g. in step S404) that is stored in memory 39 regardless that this application has been rejected access previously (i.e. before the currently applicable authorisation was obtained).

If the newly authorised App 2' application no longer needs to use the MTC device 2-4, it terminates the connection between them, as shown in step S436. However, App 2' may request a new connection be set up with Sensor 4' as long as it remains authorised to do so.

Authorisation information A more detailed description will now be given of an exemplary implementation of authorisation information that may be used by a mobile telephone 3 to control the access of applications to MTC devices 2. In particular, the exemplary authorisation information is based on the following features.

Unique identifiers assigned to M2M devices Each MTC device (e.g. Bluetooth sensors) is given a unique identifier (e.g. by an M2M service provider, the device manufacturer, or the MTC access controller 49).

This identifier may be based on the M2M device's Bluetooth / Media Access Control (MAC) address and/or other data specific to the MTC device (or the M2M service provider associated with that MTC device), although this identifier may be selected arbitrarily for each connected MTC device 2. The identifier (or information from which such an identifier can be derived) may be included in e.g. the Bluetooth Advertising (if Bluetooth technology is used) or similar message received by the mobile telephone 3 prior to pairing / establishing a connection with the MTC device 2.

Creating an Elementary File (EF) in the U/CC (in accordance with the ETSI TS 102221 standard) for storing authorization related data Using a standardised format as EF (or similar), an M2M service provider can provide the relevant authorization data for the UICC 38 to configure its desired access solution. For example, sensors (albeit using standard profiles) can be deployed in a particular M2M service provider specific solution such that the sensors are accessible by the M2M service provider's own applications only (and/or by applications that are licensed to use that M2M service provider's sensors).

For example, an EF for specifying a particular access authorisation configuration may include the following information: -Record 1: (sensorl_ID, allowed_appi_ID, allowed_appl 1_ID) -Record 2: (sensor2 ID, allowed_app2_ID) -RecordN:[..j [. .1 where: "sensorX_ID" is an identifier that uniquely identifies a particular sensor denoted X' (or other type of MTC device 2); "allowed_appY_ID" is an identifier that uniquely identifies an application denoted Y' that is allowed to exchange data from the sensor mentioned in the same record. For example, in the Android operating system, an application's unique identifier may be based on the name of the application package (since each application has a unique package name in the Android system). If an application is to be authorised to either read or write data to a particular sensor, such read/write authorisation may also be included in the corresponding record for that sensor.

Therefore, using the above exemplary EF configuration: applications associated with the unique identifiers appl' and appi 1' are allowed to exchange data with the MTC device associated with the unique identifier sensorl'. Further, the application associated with the unique identifier app2' is allowed to exchange data with the MTC device associated with the unique identifier sensor2'.

Advantageously, the EF can be read by the mobile telephone 3 during the power up stage. However, the content of the EF may be updated by the M2M service provider over the air at anytime (for example, via the provisioning server 55 using an Over-The-Air (OTA) update mechanism). Once the update is completed, the UICC 38 sends a Refresh command (part of the SIM Toolkit feature) to the MTC access controller 49 requesting it to re-read the content of this EF and thereby obtain the latest authorisation data.

MTC access controller As discussed above, the MTC access controller 49 checks whether or not a given application has the authorization to interact with a particular sensor.

For example, the MTC access controller 49 can be implemented as a Wireless Sensor Controller' module on a smartphone and/or a tablet computer (and/or other similar user equipment). In this case, the MTC access controller 49 may be configured to perform one or more of the following actions: -store unique identifiers of sensors that are paired with the

smartphone/tablet;

-read authorization data from the UICC (during the power up stage and each time when receiving a Refresh command from the UICC); -perform a filtering when an application requests information on paired devices (e.g. by calling the Android GetBondedDevices() method or the like) such that only those sensor devices are returned that the particular application is authorised to use (based on the EF); -(regardless of any preceding filtering) verify authorisation each time an application attempts to interact with a sensor.

Modifications and Alternatives Detailed embodiments have been described above. As those skilled in the art will appreciate, a number of modifications and alternatives can be made to the above embodiments whilst still benefiting from the inventions embodied therein. By way of illustration only a number of these alternatives and modifications will now be described.

It will be appreciated that the data sent at step S420 of Figure 4 may include any of the following: information relating to all currently authorised applications per MIC device, information relating to newly authorised applications per MTC device, information relating to applications no longer authorised to use an MTC device (or devices), and information relating to MTC devices that are authorised (and/or not authorised) to use a certain application (or applications). The information may be sent by the provisioning server periodically, whenever there is a change in authorisation, and/or upon request. For example, the UICC and/or the MTC access control module may request the provisioning server to update the information held on the authorised applications whenever a new application is installed and/or a new MTC device is connected to the mobile telephone.

In the above embodiments, the MTC access controller is described to obtain the authorisation information by communicating with a UICC. However, it will be appreciated that the MTC access controller may also obtain the authorisation information by communicating with an Open Mobile Alliance (OMA) device management (DM) entity (or any other remote' entity) provided e.g. in the network domain or in the device domain.

In the above embodiments, the M2M devices are automated sensor devices. It will be appreciated that the above embodiments might be implemented using other devices than automated equipment such as, for example, mobile telephones, personal digital assistants, laptop computers, web browsers, e-book readers, etc. It will be appreciated that whilst embodiments of the invention have been described with particular reference to machine-type data transmissions (e.g. transmission of data acquired from sensors and the like), the data sent may comprise any form of data depending on the application in which the communications device is being used. For example, the above embodiments may be applicable for transmitting other data such as user data, backup data, synchronisation data, diagnostic data, monitoring data, usage statistics, error data and/or the like.

In the above description the mobile telephone is explained as having an M2M gateway functionality. However, it will also be appreciated that the above embodiments are also applicable to user equipment coupled to MIC devices without providing such a gateway functionality.

In the above description, an exemplary implementation is given for sensors connecting to a smartphone/tablet using Bluetooth (or Bluetooth Low Energy) communications technology. However, it will also be appreciated that the above solution may also be implemented using other communications technologies such as ANTi-, Zigbee, Wi-Fi, and the like. The above embodiments are also applicable to non-mobile' or generally stationary user equipment.

Some examples of machine-type communication applications are listed in the following table (source: 3GPP 15 22.368, Annex B). This list is not exhaustive and is intended to be indicative of the scope of machine-type communication applications.

Service Area MTC applications Surveillance systems . Backup for landline ecuri y Control of physical access (e.g. to buildings) Car/driver security Fleet Management Order Management Pay as you drive Asset Tracking Tracking & Tracing Navigation Traffic information Road tolling Road traffic optimisation/steering Point of sales Payment Vending machines ___________________________ Gaming machines Monitoring vital signs Health Supporting the aged or handicapped Web Access Telemedicine points Remote diagnostics Sensors Lighting Pumps Remote Maintenance/Control Valves Elevator control Vending machine control Vehicle diagnostics Power Gas Water Metering Heating Grid control Industrial metering Digital photo frame Consumer Devices Digital camera e Book In the above description, the mobile telephone is described for ease of understanding as having a number of discrete functional components or modules.

Whilst these modules may be provided in this way for certain applications, for example where an existing system has been modified to implement the invention, in other applications, for example in systems designed with the inventive features in mind from the outset, these modules may be built into the overall operating system or code and so these modules may not be discernible as discrete entities.

In the above embodiments, a number of software modules were described. As those skilled in the art will appreciate, the software modules may be provided in compiled or un-compiled form and may be supplied to the mobile telephone as a signal over a computer network, or on a recording medium. Further, the functionality performed by part or all of this software may be performed using one or more dedicated hardware circuits. However, the use of software modules is preferred as it facilitates the updating of the mobile telephone in order to update it functionalities.

Various other modifications will be apparent to those skilled in the art and will not be described in further detail here.

Claims

CLAIMS1. A communication device for controlling interaction with another communication device accessible via said communication device, the communication device comprising: means for communicating data with said other communication device; means for obtaining: i) information identifying said other communication device, and H) information identifying each application authorised to interact with said other communication device; means for receiving a request for an application to interact with said other communication device, wherein said request is configured to identify said application; means for determining, using said obtained information, whether or not said requesting application is authorised to interact with said other communication device; and means for controlling interaction between said application and said other communication device in dependence on a result of said determination.
2. The communication device according to claim 1, further comprising means for storing data obtained from said other communication device by said data communicating means and wherein said controlling means is operable to control access to said obtained data by said requesting application in dependence on said result of said determination.
3. The communication device according to claim 1 or 2, wherein said obtaining means is operable to obtain said information identifying said other communication device based on a Bluetooth and/or Media Access Control, MAC, address associated with said other communication device.
4. The communication device according to any of claims 1 to 3, wherein said obtaining means is operable to obtain information identifying each respective application based on a name associated with that particular application.
5. The communication device according to any of claims 1 to 4, wherein said request to interact comprises at least one of a request to establish a data connection with said communications device, a request to access data associated with said communications device, and a request to obtain information on said other communication device.
6. The communication device according to any of claims 1 to 5, wherein said controlling means is operable to allow said request if said determining means determines that said requesting application is authorised to interact with said other communication device.
7. The communication device according to any of claims 1 to 6, wherein said controlling means is operable to reject said request if said determining means determines that said requesting application is not authorised to interact with said other communication device.
8. The communication device according to any of claims 1 to 7, wherein said obtaining means is operable to obtain said information by communicating with an Open Mobile Alliance Device Management, OMA DM, entity.
9. The communication device according to any of claims 1 to 8, wherein said obtaining means is operable to obtain said information by communicating with subscriber identity module, SIM, (for example, a universal integrated circuit card, UICC).
10. The communication device according to claim 9, wherein said SIM is operable to provide said information by sending at least one message, for example, a universal SIM application toolkit, LJSAT, refresh message.
11. The communication device according to claim 9 or 10, wherein said SIM is operable to obtain said information from a provisioning server entity.
12. The communication device according to any of claims 1 to 11, further comprising means for providing gateway functionality for said other communication device.
13. The communication device according to any of claims 1 to 12, further comprising means for executing said requesting application and wherein said requesting application is installed locally on said communication device.
14. The communication device according to any of claims 1 to 13, wherein said other communication device is connected to said communication device via at least one further communication device.
15. The communication device according to any of claims 1 to 14, wherein said other communication device comprises a machine-type communication, MTC, device (for example, a sensor).
16. The communication device according to any of claims 1 to 15, wherein said communicating means is operable to use at least one of a Bluetooth communication technology, a Bluetooth Low Energy communication technology, a Zigbee communication technology, and an ANT+ communication technology.
17. The communication device according to any of claims 1 to 16, comprising a mobile communication device.
18. The communication device according to claim 17, comprising at least one of a mobile telephone, a tablet computer, and user equipment in accordance with the Long Term Evolution, LTE, standard.
19. A universal integrated circuit card, UICC, for use with a communication device, the UICC comprising: means for holding information identifying: i) at least one communication device other than said communication device, and H) a respective set of at least one application authorised to interact with said at least one other communication device; and means for communicating said information to said communication device for use, by said communication device, in controlling interaction between said at least one other communication device and at least one application associated with said communication device.
20. The IJICC according to claim 19, wherein said held information comprises at least one record for each one of said at least one other communication device and wherein each record includes said information identifying said other communication device and respective applications that are authorised to interact with said other communication device.
21. The UICC according to claim 19 or 20, wherein said holding means is operable to hold said information as elementary file, EF, data.
22. A communication device for controlling interaction with another communication device accessible via said communication device, the communication device comprising a transceiver and a processor, wherein: the transceiver is configured to communicate data with said other communication device; the processor is configured to obtain: i) information identitying said other communication device, and H) information identifying each application authorised to interact with said other communication device; the transceiver is configured to receive a request for an application to interact with said other communication device, wherein said request is configured to identify said application; the processor is configured to determine, using said obtained information, whether or not said requesting application is authorised to interact with said other communication device, and control interaction between said application and said other communication device in dependence on a result of said determination.
23. A system comprising said communication device and said other communication device according to any of claims 1 to 18, and 20, and said universal integrated circuit card according to any of claims 19 to 21.
24. A method performed by a communication device for controlling interaction with another communication device accessible via said communication device, the method comprising: obtaining: i) information identifying said other communication device, and H) information identifying each application authorised to interact with said other communication device; receiving a request for an application to interact with said other communication device, wherein said request is configured to identify said application; determining, using said obtained information, whether or not said requesting application is authorised to interact with said other communication device; and controlling interaction between said application and said other communication device in dependence on a result of said determination.
25. A computer implementable instructions product comprising computer implementable instructions for causing a programmable communication device to perform the method according to claim 24.