WO2007036884A2

WO2007036884A2 - General and specific policies in a networked system

Info

Publication number: WO2007036884A2
Application number: PCT/IB2006/053514
Authority: WO
Inventors: Robin J. Blackwell; Philip A. Rudland
Original assignee: Koninklijke Philips Electronics N.V.
Priority date: 2005-09-29
Filing date: 2006-09-27
Publication date: 2007-04-05
Also published as: WO2007036884A3

Abstract

A service gateway (60) controls devices (111 -113). A service registry (110) registers device services (121 -123). Each device service represents a device (111 -113) connected to the gateway (60) and has a class name and at least one registered property. The registry responds to queries, made by applications (70), to access registered device services (121 -123). A policy enforcement mechanism (115) restricts access of an application (70) to a device service (121 -123) on the basis of policy data (116) which specifies at least one registered property of a device service (121 -123). Properties can include a per-device identifier; device manufacturer; device model name; device feature; device location; device domain. Policy enforcement can use AND/OR combinations of properties. Policy data (116) can be generated remotely from the service gateway (60) and downloaded to the service gateway (60). The service gateway (60) can conform to the OSGi framework.

Description

DESCRIPTION

GENERAL AND SPECIFIC POLICIES IN A NETWORKED SYSTEM

This invention relates to use of policies in a networked system and to a service gateway at which the policies are enforced.

There is considerable interest in networking appliances within the home environment. This typically requires a residential gateway which connects to a network of devices within the area where it is installed and supports applications to control those devices. The residential gateway also connects to an external server to allow external control of the network and to allow software on the gateway to be updated. A major standard for residential gateways is that from the OSGi Alliance (Open Services Gateway initiative). Information about OSGi can be found at www.osgi.org.

Part of the OSGi specification describes how household devices might be connected to, and controlled via, a residential gateway (RG). A collaborative project known as TEAHA (The European Application Home Alliance) will provide extensions to make the OSGi framework better suited to business and consumer needs.

One aspect of residential gateways is policies. Stakeholders (such as device manufacturers) are only willing to allow their products to be connected to a common gateway if suitable assurances can be made about who will be allowed to discover and control the products. The policies directly supported by the current OSGi specification are very limited, and can only be of the form: allow a specified [set of] application^] to discover and control a certain type of (device) service. Some very limited flexibility can be provided by specifying two policies related to the same application, creating an additive (OR) functionality, e.g. {Allow App to control TVs} + {Allow App to control Cameras} results in the App being able to control anything that is registered as either a TV or a Camera. This use of policies is very limited, and does not support many of the demands of stakeholders. A typical approach to enforcing policies is to have a secure database including references to all devices (and/or applications), and also a record, typically stored in a file, of the declared policies. The secure database is arranged so as to only allow permitted targets to be discovered, based on the information in the policy record. Java™ has a format for expressing policies, and OSGi adds to this to give some device specific extensions.

The present invention seeks to improve the use of policies at a service gateway, such as a gateway conforming to the OSGi framework.

Accordingly, a first aspect of the present invention provides a service gateway for control of devices, the service gateway comprising: a registry for registering device services, each device service representing a device connected to the gateway and having a class name and at least one registered property; the registry being responsive to queries, made by applications, to access registered device services; and a policy enforcement mechanism for restricting the access of an application to a device service, wherein the policy enforcement mechanism is operable to restrict access of an application to a device service on the basis of at least one registered property of a device service.

The gateway has an advantage of allowing various policy use cases which will be useful, but which cannot be accommodated by the current mechanisms and policy records. With a policy enforcement mechanism of this kind service providers can safely allow devices to be connected to a gateway. Some advantages are service security, user security (user privacy and protecting users against malicious code) and safe interoperability by ensuring that only device combinations that have been tested together are able to communicate with one another. It also allows a domain split, where the devices in one domain (e.g. home security system) cannot interfere with devices in another domain (e.g. home entertainment).

Preferably, one of the registered properties is a per-device identifier. This per-device identifier should be unique at least within the set of devices connected to the service gateway and preferably is a globally unique identifier of the device. The per-device identifier can be used to distinguish one device from another apparently identical device and allows applications to have different levels of access to two or more apparently 'identical' devices, i.e. two devices which are of the same type, manufacturer and model. As an example, if all of the lights in a house are of an identical type and are connected to a common gateway, the system can be configured to allow a service provider's application to be able to control one of the lights, but not the others. The per- device identifier can comprise a unique serial number of the device, or a combination of identifiers which include fields such as network type, an identifier of the hardware interface to which the device is connected and the allocated network address.

A registered property can be an attribute which is shared by a group of devices, such as: device functionality, device manufacturer; device model name; device feature; device location or device domain.

The policy enforcement mechanism can optionally restrict access of an application to a device service on the basis of at least two registered properties and supports policies which use a logical 'AND' or 'OR' combination of the properties. The properties can be a combination of a group-based property (such as manufacturer, domain etc.) and a per-device identifier. The policy enforcement mechanism can also restrict access of an application to a device service on the basis of one or more registered properties and the class name of a device service.

The service gateway can be implemented on a variety of processing platforms, such as a general purpose PC, a dedicated processing unit or it can be hosted by another device such as a broadband router, television, mobile phone or personal digital assistant (PDA).

Another aspect of the invention provides a method of enforcing a policy at a service gateway for control of devices, the service gateway comprising a registry for registering device services, each device service representing a device connected to the gateway and having a class name and at least one registered property, the method comprising, at the service gateway: receiving a query, made by an application, to access a registered device service; using a policy enforcement mechanism to restrict the access of an application to a device service, wherein the policy enforcement mechanism is operable to restrict access of an application to a device service on the basis of at least one registered property of a device service.

Another aspect of the invention provides a policy enforcement mechanism for a registry of a service gateway for the control of devices, the registry being operable to register device services, each device service representing a device connected to the gateway and having a class name and at least one registered property, wherein the policy enforcement is operable to restrict the access of an application to a device service on the basis of at least one registered property of a device service.

A further feature is the ability to support a complex, multi-input policy on a very simple residential gateway implementation as can arise where a service gateway provider accepts devices from a large number of manufacturers. It is preferable that assessment of a new device against all relevant policies is performed remote from a gateway, using the resources of a server, and without the restrictions of a simple policy file format or storage limitations. A policy can then be downloaded to the gateway for use by the policy enforcement mechanism. Accordingly, a further aspect of the invention provides a method of generating a policy file for use at a service gateway which supports applications, the service gateway registering device services which each represent a device connected to the gateway and have a class name and at least one registered property, the method comprising: receiving a set of policy requirements at a server, remote from the gateway; generating a policy file at the server which specifies an application, or set of applications, and permissions for the application in terms of properties of a device service and values which the properties must have for that application to be permitted to access the device service; and, sending the policy file to the gateway for use at the gateway. The functionality described here can be implemented in software, hardware or a combination of these. The invention can be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed processing platform. Accordingly, another aspect of the invention provides a computer program product carrying instructions for implementing the method. The software may be stored on an electronic memory device, hard disk, optical disk or other machine-readable storage medium. The software may be downloaded directly to the processing platform via a network connection.

Embodiments of the present invention will now be described, by way of example only, with reference to the accompanying drawings, in which:

Figure 1 shows an overall model for a residential service gateway;

Figure 2 schematically shows the OSGi framework which is supported by the service gateway of Figure 1 ;

Figure 3 shows an implementation of the service gateway using a service factory;

Figure 4 shows creation of a policy file at a remote server;

Figure 5 shows steps which occur when a new device is connected to a network served by the service gateway;

Figure 6 shows steps which occur when a user of the service gateway subscribes to a new service application;

Figure 7 shows steps which occur when a stakeholder wishes to allow a new service provider to access an existing device in a network connected to the service gateway;

Figure 8 shows an example of a processing platform which can implement the framework of Figure 2.

Figure 1 shows a simplified overall model for an Open Services Gateway Initiative (OSGi) residential gateway. A service gateway (residential gateway, RG) 60 is located within a home, office, car or similar. The service gateway 60 provides a service platform 65 which supports the OSGi framework. Applications 70, which provide various services within the home, are executed by the platform 65 to control target devices 20-23. Applications 70 can have a variety of purposes, including control of appliances, such as consumer electronics, white goods, heating and ventilation, lighting etc. The target devices 20-23 can include lamps 20, electrical appliances 21-23, or any other electrical devices. The gateway 60 connects to the target devices 20-23 using the conventional local networking protocols of networks 40, 45. A typical home will include target devices which operate according to a range of target network protocols, such as ZigBee, X10, UPnP, EHS, KNX and Echelon. The physical network layer to each hardware device may be wireless (e.g. IEEE 802.15.4 in the case of ZigBee, IEEE 802.11 or similar) or wired (e.g. serial bus, Ethernet cabling or electrical cabling). In Figure 1 , network 40 is a ZigBee network and network 45 is an X10 network. Although not shown in Figure 1 , devices can also be directly connected to the service gateway 60 without the intermediate local networks 40, 45. A remote server 50, outside of the home, can communicate with the gateway 60. Services may be delivered to the gateway by the server 50 for local execution by the gateway 60 or, in some circumstances, applications 55 on server 50 can remotely control target devices 20-23 within the home. The remote server 50 can also be used for network management and to provide new services or updated services 55 to the gateway 60. Services can also be loaded onto the gateway 60 by a user from local media, such as an installation disc supplied with a new device.

Figure 2 shows the aspects of the OSGi framework, executed by the gateway 60, that are relevant to the present invention. The OSGi framework exists to support 'services', which are OSGi based software components. Some services are applications, one of which is shown as 70. An application can include a billing service or a computation service. Each target device 111- 113 (similar to devices 20-23 shown in Figure 1 ) which exists in the local network is represented in the OSGi framework by a device service 121-123. This is a representation, in software, of the actual physical device 111-113. Each service 70, 121 -123, is registered with the OSGi Service Registry 110. Applications (services) can search for other services by querying the registry 110. Each service is registered with a class name (service type) and a number of properties, which will depend on the type of service. Queries to search the registry can also specify values for a given property. A service may be registered with more than one class name. Stakeholders require assurances that their products will only be used in ways that they are happy with, e.g. in order to ensure they only work where fully tested and do not interfere with other types of device. One example is to prevent a device forming part of a security system interfering with a device in an audio visual (AV) system. Java™ provides security mechanisms for restricting which software can use which other software. This is configured by specifying permissions. These are stored in a policy file. When an application tries to use methods on another software component the Java™ system first checks that it has been given authority to do so, by looking up all relevant permissions and ensuring that there is a permission which says that the calling class is allowed to use the called class.

OSGi extends the existing Java security permissions, and provides a mechanism whereby information in the policy file determines which applications are allowed to see which other OSGi services. Business policies are agreed by the various parties (e.g. Gateway operator, Device manufacturer, Service operator, user) and securely downloaded to the policy file 116 stored on the gateway. Service registry 110 includes a store 112 of registry data. This store 112 includes details of every service registered with the gateway 60. Links 126, 127 indicate that the services have been registered. An enforcement mechanism 115 receives requests for information about registered services. Typically, these requests are submitted by applications 70 which may need to access a device to control the device or perform some other function. Enforcement mechanism 115 uses the policy file 116 to decide whether the application which submitted the request can access the device service 121 -123 (and hence the physical device 111 -113). The enforcement mechanism 115 makes this decision based on details of the application making the request, and the name and one or more registered properties of registered device services. There are several ways in which the registry and enforcement mechanism can be implemented in an OSGi framework and these are described in more detail later. Although, for clarity, only one application 70 is shown, multiple applications can be registered with a system and one application may act on another application. An application is required to pass a policy enforcement test to discover the existence of a device service (also known as obtaining a 'reference' to the device service) and a further policy enforcement test to acquire the device service.

As noted above, the business policies directly supported by the current OSGi specification are very limited, and can only be of the form: allow a specified [set of] application^] to discover and control a certain type of (device) service. The system described here will allow policies based on both the class name (service type) as at present, and additionally on the values of registered service properties. It will also support policies specific to a given device. The following types of policies are supported:

• Allow a specified [set of] application^] to control a certain type of device service (as is already possible within OSGi framework).

• Allow a specified [set of] application^] to control devices with registered properties meeting certain criteria, (e.g. based on manufacturer, location, time, business domain, detailed device functionality or unique device ID).

• Allow a specified [set of] application^] to control devices meeting more than one of the above requirements (e.g. Manuf="ACMECorp" AND Capabilities=TV) • Allow a specified [set of] application^] to control a restricted subset of available device functionality (e.g. only ACMECorp Application can control "Enhanced TV" functionality).

For illustration, a possible registry record for a device service is suggested: Registered class: com. acmecorp. Device Registered properties: Capabilities = "TV+OnOffDevice" manufString = "ACMECorp" businessDomain = "AV" uniqueDevicelD = "ZB-IF1 -ADD-0xFAB0112233445566"

Some example policies for storing in policy file 116, and corresponding to the above examples, are:

- Allow if class = com. acmecorp. Device

- Allow if manufString = "ACMECorp" - Allow if uniqueDevicelD = "ZB-IF1 -ADD-0xFAB0112233445566" (i.e. allow access to a specified device only, as described more fully below).

- Allow if class = com. acmecorp. Device AND manufString = ACMECorp

- Allow if manufString = "ACMECorp" AND businessDomain = "AV"

- Allow [full access] if manufString = "ACMECorp" AND businessDomain = "AV"

- Allow [limited access] if businessDomain = "AV"

The 'access to a specified device only' policy is an example of a policy based on a registered property, but has some unusual features. By using this a party can specify permissions for an individual device, such as the one that has just been purchased, or one for which a new service contract has been signed.

The 'access to a specified device only' policy can be implemented in each of the three architectures described below by creating a new property, such as 'uniqueDevicelD' which is included within the device service in the registry. This property value is different for every device, and its value is generated from some persistent unique identifier. Typically this is obtained from the target device itself via its lower level dhver(s). In the example above, the uniqueDevicelD value "ZB-IF1 -ADD-0xFAB0112233445566" has been constructed by concatenating the network type (ZigBee), some representation of which hardware interface it is connected to (IF1 ) and the device's persistently stored identifier (here an "IEEE address" from the 802.15.4 specifications). This is just an example, and in practice the uniqueDevicelD might be quite different. The uniqueDevicelD can be, or include, the device's unique serial number if the device protocol supports access to this information. Preferably, the uniqueDevicelD is a globally unique identifier of the device. Some simple network types do not have a unique persistent ID, in which cases a semi-persistent code could be used, such as the current network address.

The functionality of a device can be expressed as a list of Capabilities (see example registry record above). The list can be a HUCL list of the type described in International Patent Application number PCT/IB 2005/051670. The functionality of a device can be represented by a hierarchical set of properties, with properties lower in the hierarchy inheriting the properties of those higher in the hierarchy. An example hierarchy can take the form: OnOffDevice (highest level of hierarchy), TV, ComplexTV etc.

Some examples of using the above architecture will now be described.

• Allow Application to view one specific device (and not an adjacent 'identical' one) e.g. two washing machines or lamps, in situations where both devices have the same manufacturer, model etc. Allow control of neither, either or both. User agrees servicing contract with a manufacturer, but would not have done so if it had meant they could see what other products they have, or worse could get control of the other products.

In trying to diagnose a fault, the gateway provider employs a third party monitoring service to study a particular device. The service provider should protect the customer's privacy as far as possible.

A user pays for a third party service to monitor and/or control a specific device. The service provider will wish to restrict the user to precisely what they've paid for, and the user will wish to minimise the risk if a program has bugs or viruses, (e.g. restricting music download to a specified machine) At a low level, this policy can also be used to effect any one of the other policies where necessary. This might be achieved under the control of a trusted application (either at the backend, or in some local management bundle, etc).

The user may pay for a security system that controls some lamps in his home but not others. The service provider will wish to be protected against the user adding more controlled lamps without paying. The user will wish to keep other devices in his home private.

• Allow Application to view all devices with certain functionality, e.g. all TVs e.g. allow it to see: device A : complex TV, TV, PowerControl capabilities and device B: TV, PowerControl but NOT device C: PowerControl

User signs up for a TV content streaming service. Gateway provider signs an agreement to facilitate this over their gateway in return for certain royalties, and enforces collection of these royalties by specifying that this service provider may talk to all TVs connected to a gateway. Media is then delivered via the internet.

User signs up for an electricity tariff where the supplier is given access to all devices implementing a power control capability.

• Allow Application to use only the PowerControl part of any device that implements PowerControl, e.g. allow it use only the functionality for PowerControl where a device actually implements means for controlling both PowerControl and TV functionality. Allowing ACMECorp Applications to access ACMECorp Extensions to a

TV service, but only allow Applications from other vendors to use basic functionality i.e. a product differentiator.

• Allow Application to view all ACMECorp devices, e.g. allow it to see items registering key manufSthng = "ACMECorp". ACMECorp agrees with A.N. OTHER service provider to provide content/diagnostic services. The gateway provider agrees to support this specific arrangement, and enforces it through adding a specific policy.

Gateway provider is able to finance a large scale roll-out of home gateways by taking a royalty from the manufacturers of devices that will be connected to the system, and thus available for interworking with value-added services. This is enforced by adding a policy entry for each manufacturer as they join the scheme. This also allows access by any service that the user signs up for, where the service provider is known to the gateway operator.

• Allow Application to view only ACMECorp TVs (AND/OR combination of policies), e.g. allow it to see items registering key manufString = "ACMECorp" AND having capability "TV" registered.

This example represents the full set of policies which arise from the AND/OR combination of other policies. "OR" type policies can always be implemented as the sum of two separate policies. Some mechanism might be required for "AND" type policies, although it should be noted that High Level policies of arbitrary complexity may be represented as the addition of a specific policy per physical device. Gateway provider is able to finance a large scale roll-out of home gateways by charging manufacturers. ACMECorp agrees a reduced per- manufacturer rate by restricting the agreement to covering only the TV part of its business.

Where a gateway operator has an exclusive agreement with a music provider, it may yet be acceptable for ACMECorp to agree content delivery terms, perhaps for supply of video streams only.

• Allow Application to view by location, e.g. allow it to see items registering key "LOCATION" = "Lounge" The user, being nervous of internet based services, signs up for a specific value added service on the understanding that it can monitor and control only those devices that are in a specified location. The user specifies rapidly which of a large set of devices they wish to be involved in an agreement, e.g. all those in one room.

• Allow Application to view by model number, e.g. allow it to see items registering key "MODEL_NAME" = "201 B4"

The user specifies rapidly which of a large set of devices they wish to be involved in an agreement, e.g. all of one type of device.

• Allow Application to view depending on the time, e.g. allow external control only within certain hours, or before or after a given date

The user signs up for a service to monitor the house (e.g. home security system) when they are out, but wants assurances that it cannot be monitored at other times.

ACMECorp wish to offer users a free trial of an upgrade to allow download from arbitrary music content providers, but want to be able to revoke it if the user does not choose to sign up.

• Allow Application to use devices from a given business cluster (domain), e.g. allow a given set of applications to control everything defined by CECED- >WG (white goods), e.g. allow a given set of applications to control everything defined by UPnP->AV equipment, e.g. allow a certain application to control

ZigBee HVAC devices.

Separation of business domains, e.g. ensuring that the home security system and the AA/ system do not disrupt each other. Allow cross-domain interaction under certain conditions, e.g. in order to configure the alarm system from the TV.

Implementation in OSGi framework

Three possible ways of implementing the behaviour described above are presented. Firstly, a preferred implementation is presented which modifies the OSGi Service Registry. Secondly, two implementations are presented which offer a more restrictive implementation with the current, unmodified, OSGi framework.

A preferred solution is to enhance the OSGi Service Registry functionality to directly support the policies described above. A new Java/OSGi "Permission" is created, which is based on the OSGi

"ServicePermission" type but is extended to support permissions based on both the registered class and also on the registered properties.

One possible implementation in the standard format of Java/OSGi policy file is as follows: grant CodeBase "file:../bundle/ABCApp.jar" { permission org.osgi. framework. DevicePermission "manufSthng='ACMECorp"' permission org.osgi.framework. DevicePermission "(manufString='ACMECorp') & (Capabilities=TV)"

The "'codebase' + string" section specifies an application or set of applications to which these permissions relate. A list of permissions follows, including one or more of a new type 'DevicePermission'. Each DevicePermission has a string parameter which expresses this individual policy statement according to some carefully defined format, and specifies both the tests to be applied and AND/OR or other relationships between tests. For example,

"manufSthng='ACMECorp"' might simply require the manufString property to take the given value, whereas

"(manufString='ACMECorp') & (Capabilities='TV')" might grant permission to access only ACMECorp TVs.

Where it is necessary to support different levels of control for different application vendors this mechanism should be used in conjunction with a ServiceFactory, so that an extended object is returned where appropriate. This is schematically shown in Figure 3. A Service Factory 135 represents device services 131 , 132 which relate to the same physical device 112. The two device services 131 , 132 present different views of the same device 112. As an example, device service 131 can allow control of a limited range of functions of the device 112 while device service 132 can allow control of a full range of functions of the device 112. When an application requests to acquire an object the request is forwarded by Service Registry 110 to the Service Factory 135, which returns the appropriate object. The Service Factory 135 can determine the type of object to return based on the caller application e.g. restricted object vs. fully open object based on permissions which are stored in a policy file 134 and enforced 133 at the Service Factory. The two policy files 116, 134 can be separate policy files or separate aspects of a single physical policy file. In addition to fully supporting the requirements for all the policies identified above, this preferred solution enables hiding of devices which an application is not allowed to use, thus ensuring user privacy. Referring again to Figure 2, when the enforcement mechanism 115 of the Service Registry 110 receives requests from an application 70, the mere existence of the device service (and hence device) is hidden unless the policy file 116 indicates that application 70 is allowed to access that device service. This prevents an unsolicited application from discovering information about a device service. As this solution is fully integrated with the registry, it is likely that these security checks will be transparent to the calling application, so that currently existing applications will still be able to work.

Two less preferable solutions will now be described. Firstly, it is possible to essentially bypass the OSGi standard Device Access Specification, and create a new registry or registry-like component. In order to technically 'comply' with the OSGi requirements the new registry would itself be registered in the OSGi Service Registry, but thereafter services wishing to talk to devices would send queries directly to the new registry, rather than to the normal registry. Whilst this should work, it is entirely against the spirit of OSGi and the mechanisms supporting the normal usage would need to be duplicated in the new version. The other proposed solutions are preferred. Secondly, a Service Factory 135 can be used without making any changes to the Registry 110 to support policies based on properties. Instead of registering a device service directly with the Service Registry 110, a driver may choose to register a Service Factory. This acts as a kind of plug-in to the OSGi Service Registry 110, so that when a search is made to the Registry, the Registry calls the Service Factory implementation and asks it to provide the device object which is subsequently returned to the searcher. This mechanism allows the driver to return different objects depending on which application requested it. In this embodiment the conventional OSGi enforcement mechanism 115 will apply policies to the level of granularity conventionally supported by OSGi (i.e. not based on properties of device services) and it is the responsibility of the service factory 135 to implement policies to the finer level of granularity. The drawback with this approach is that all device services 131 , 132 are visible to any application which searches the registry 110, even though those applications will only be able to use those device services that they have suitable permissions for. This is seen as not giving the user enough privacy. Ideally, an application should only be able to discover the existence of device services that it has permission to use.

Using this mechanism, the policies may be specified in the Java Policy File and enforced by the device services using a new permission (e.g. in a similar manner to those described above for the Service Registry). Alternatively, as the implementer has some flexibility in this case, it may be possible to do a less formal implementation which instead of using the standard Policy File mechanisms, checks some standard or non-standard policy record, this perhaps being stored in a proprietary manner.

The types of policies described above can result in a complex policy file, particularly where per-device policies are enforced or where a large number of properties are supported. As shown in Figure 4, it is possible to store, compute and/or record a policy for a gateway 60 on the gateway operator's secure back-end server. A policy engine 205 located at a server (e.g. server 50 in Figure 1 ) compiles a per-device policy statement (of the 'specified device' form) based on the requirements of parties such as the gateway operator 201 , service operator 202 and user 203. The combined policies 206 are downloaded, via a secure link 208, onto the local gateway 60 and stored as policy data 116. This relieves the gateway 60 of significant processing requirements, thus allowing the gateway to be implemented using a more modest processor. This further feature of the invention allows assessment of a new device against all relevant policies to be carried out remotely from the service gateway 60 and without the restrictions of a simple policy file format or storage limitations that may exist at service gateway 60.

The requirements of various stakeholders (gateway user, service operator, gateway operator etc.) can be manually input to the policy engine 205 via a suitable user interface, such as web form or via a (semi-) automated system, involving a combination of existing group-based business policies, user preferences, user-specific modifications, and policy modifications brought into force through contracts with other parties, such as a third party service provider. User preferences may be indicated when subscribing to a service (e.g. verbally or in writing to a service operator), or may be entered manually via a user interface on the service gateway by a user. Alternatively, connecting a new device to a network can automatically trigger an update of the permissions. Stakeholders can communicate with the policy server 210 using a policy language which is open, and can take any format.

The following is one example scenario of the requirements of various stakeholders. For clarity, the permissions given in this scenario are not complete, and can take the form of those described earlier.

A service provider ABCCorp wants to provide a home automation service to a user based on a number of devices provided by ACMECorp (this assumes the service gateway is initially configured so that no service has any permissions). The Gateway operator has an agreement with ACMECorp that only

ACMECorp applications can see ACMECorp devices.

Creates policy CodeBase = ....ACMECorp, DevicePermission "manufString=ACMECorp", "GET, REGISTER"

Service Provider ABCCorp agrees with ACMECorp to let its service see their devices. ACMECorp notifies policy engine 205:

Adds to existing policy CodeBase = ....ABCCorp, DevicePermission "manufSthng=ACMECorp", "GET, REGISTER". A user, when signing up to the service, selects that all camera devices are excluded access from home automation service: Modifies policy CodeBase = ....ABCCorp,

DevicePermission "(manufSthng=ACMECorp) & (Capablities =TV)", "GET, REGISTER"

DevicePermission "(manufString=ACMECorp) & (Capablities = ALARM)", "GET, REGISTER"

DevicePermission "(manufString=ACMECorp) & (Capablities = PVR)", "GET, REGISTER" It can be seen that the overall policy file can become quite large for exceptions. Therefore, a possible optimisation would be to allow the logical operation 'NOT in the expression e.g.:

Modifies policy CodeBase = ....ABCCorp, DevicePermission

"(manufString=ACMECorp) & (Capablities != Camera)", "GET, REGISTER". The expression in the attribute list is interpreted by the policy class, which enforces the device permission. Therefore the expression language used can be arbitrary so long as the implementing policy class understands it.

Therefore either of the above exception examples could be used. The interface name of the service can be included in the expression e.g. a Device Permission which only contained the service interface name would be identical to a current OSGi ServicePermission. Alternatively, the 'NOT operator may be used only in the policy language used to specify requirements between a stakeholder 201-203 to the policy engine 205 and the policy engine 205 translates an expression using the NOT operator into a format understood by the service gateway 60.

Some requirements may be commercial discussions, technical limits e.g. RAM required to support a service, and are assumed to take place before the policies are submitted to the policy compilation engine.

Figures 5 to 7 show steps which occur when a change is made to the system. Figure 5 shows steps which occur when a new device is connected to a network served by the service gateway. At step 202 a user connects a new device to a network 40, 45 connected to the service gateway 60. The local network 40, 45 discovers the new device and a device service for the new device is registered with the OSGi framework at step 203. If the new device service does not match the current policies the gateway 60 assumes the new device is barred from discovery by applications. At step 204 the gateway 60 notifies the policy server of the new device and at step 205 the policy server decides whether policy at the gateway 60 needs to change to accommodate the new device. If a policy change is required, a new policy is compiled at step 206 and is downloaded to the service gateway 60 at step 207. If no policy change is necessary, the method ends. Figure 6 shows steps which occur when a user of the service gateway subscribes to a new service application. At step 212 a user of the service gateway 60 subscribes to a new service, such as by completing a web form via a user interface of the gateway 60. The new service application is downloaded to the gateway 60 at step 213. If the new service does not match the current policies the gateway 60 assumes the new service is barred from discovering device services. At step 214 a service provider (who provided the new service) or the service application notifies the policy server of the new service and at step 215 the policy server decides whether policy at the gateway 60 needs to change to accommodate the new service. If a policy change is required, a new policy is compiled at step 216 and is downloaded to the service gateway 60 at step 217. If no policy change is necessary, the method ends.

Figure 7 shows steps which occur when a stakeholder wishes to allow a new service provider to access an existing device in a network connected to the service gateway. This is similar to the worked scenario described earlier in this section. At step 222 a stakeholder notifies the policy server that a new service provider is allowed to access a specific device type. At step 223 the policy server considers if a policy change is required and, if so, a new policy is compiled at step 224 and is downloaded to the service gateway 60 at step 225. If no policy change is necessary, the method ends.

This invention has so far been described in relation to residential service gateways, such as those conforming to OSGi. The invention is not limited to this and can be applied to other frameworks, such as Microsoft's .NET framework. Within .NET an equivalent concept to Java/OSGi permissions is the "Code Access Permissions" Mechanism.

The gateway described above can be implemented on a variety of processing platforms, such as a general purpose PC, a dedicated processing unit or it can be hosted by another device such as a broadband router, television, mobile phone or personal digital assistant (PDA). Figure 8 shows the main components of the processing platform. A central processing unit 401 executes software, as previously described, to support the OSGi framework and applications. Typically, the central processing unit 401 has a native operating system (e.g. based on Linux) which supports a Java Virtual Machine (JVM). The JVM hosts the OSGi framework and applications. Nonvolatile memory 402 and volatile memory 403, such as a hard disk and RAM, store the operating software and libraries of device services and are used by the processing unit 401. A modem 406 or other digital interface, such as a broadband ADSL, cable modem or wireless link, connects to a communication line 407 which joins the gateway to a remote server (50, Figure 2) on which applications may also be supported. The broadband modem 406 may be external to the gateway 60. Control messages to/from controlled devices are carried by local network connections 415, which use a combination of wired 412 and wireless 411 technologies. Appropriate hardware may be provided to support the particular local network such as: a local area network card; a wireless, infrared or power line (X10) modem. User inputs can be provided directly to the gateway by input devices 410 such as a keypad, keyboard, mouse or tablet. Alternatively, user inputs may be received from a remote control unit which is locally networked with the gateway 60, or from the communication link 407. As an example, if a user is away from their home and wishes to send instructions to the gateway to control appliances within the home, a user will interact with a remote terminal and send instructions, via line 407, to the gateway 60. An output may be directly presented to a user via a display driver 408 and display 409, to a local remote control unit or to a remote terminal via link 407. A bus 405, or combination of buses of different types, connect the above units. The gateway can operate in the manner described in pending International Patent Application number PCT/IB 2005/051670 (PHGB040114GBP).

A wide variety of applications can be executed on the gateway 110, or on a remote server 50. Examples of these include: home control, such as simulating occupancy of a building by turning lamps on and off at predetermined times, control of heating and ventilation, programming a video recorder; control of entertainment and consumer electronics devices; remote monitoring of security of a building or the health of an occupant of a building; remote fault reporting/diagnosis.

It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. The words "comprising" and "including" do not exclude the presence of other elements or steps than those listed in the claim. Where the system/device/apparatus claims recite several means, several of these means can be embodied by one and the same item of hardware. In the description above, and with reference to the Figures, there is described a service gateway 60 which controls devices 111 -113. A service registry 110 registers device services 121 -123. Each device service represents a device 111 -113 connected to the gateway 60 and has a class name and at least one registered property. The registry responds to queries, made by applications 70, to access registered device services 121 -123. A policy enforcement mechanism 115 restricts access of an application 70 to a device service 121 -123 on the basis of policy data 116 which specifies at least one registered property of a device service 121 -123. Properties can include a per-device identifier; device manufacturer; device model name; device feature; device location; device domain. Policy enforcement can use AND/OR combinations of properties. Policy data 116 can be generated remotely from the service gateway 60 and downloaded to the service gateway 60. The service gateway 60 can conform to the OSGi framework.

Claims

1. A service gateway for control of devices, the service gateway comprising: a registry for registering device services, each device service representing a device connected to the gateway and having a class name and at least one registered property; the registry being responsive to queries, made by applications, to access registered device services; and, a policy enforcement mechanism for restricting the access of an application to a device service, wherein the policy enforcement mechanism is operable to restrict access of an application to a device service on the basis of at least one registered property of a device service.

2. A gateway according to claim 1 wherein the registered property is a per- device identifier.

3. A gateway according to claim 2 wherein the per-device identifier comprises a globally unique identifier of the device.

4. A gateway according to any one of the preceding claims wherein the registered property is at least one of: device functionality, device manufacturer; device model name; device feature; device location; device domain.

5. A gateway according to claim 4 wherein the functionality of a device is represented by a list of properties.

6. A gateway according to any one of the preceding claims wherein the registered property is time, and the policy enforcement mechanism restricts access of an application to a device service on the basis of time of day or date.

7. A gateway according to any one of the preceding claims wherein the policy enforcement mechanism restricts access of an application to a device service on the basis of at least a first registered property and a second registered property.

8. A gateway according to claim 7 wherein the policy enforcement mechanism restricts access of an application to a device service on the basis of an AND combination of the first and second registered properties.

9. A gateway according to claim 7 or 8 wherein the policy enforcement mechanism restricts access of an application to a device service on the basis of an OR combination of the first and second registered properties.

10. A gateway according to any one of claims 7 to 9 wherein the at least two registered properties are a group-based property and a per-device identifier.

11. A gateway according to any one of the preceding claims wherein the policy enforcement mechanism is operable to access a store of policy data, the policy data specifying an application, or set of applications, and permissions for the application in terms of properties of a device service and values which the properties must have for that application to be permitted to access the device service.

12. A gateway according to any one of the preceding claims wherein the policy enforcement mechanism, upon receiving a query from an application, only returns information about the existence of a device service to an application if the application is permitted to access that device service.

13. A gateway according to any one of the preceding claims which is operable to interface with a service factory which stores details of a plurality of device services, the service factory being operable to respond to queries about device services.

14. A gateway according to any one of the preceding claims wherein the policy enforcement mechanism is operable to receive a policy which has been generated external to the gateway.

15. A gateway according to any one of the preceding claims wherein the gateway conforms to the OSGi framework.

16. A method of enforcing a policy at a service gateway for control of devices, the service gateway comprising a registry for registering device services, each device service representing a device connected to the gateway and having a class name and at least one registered property, the method comprising, at the service gateway: receiving a query, made by an application, to access a registered device service; using a policy enforcement mechanism to restrict the access of an application to a device service, wherein the policy enforcement mechanism is operable to restrict access of an application to a device service on the basis of at least one registered property of a device service.

17. A policy enforcement mechanism for a registry of a service gateway for the control of devices, the registry being operable to register device services, each device service representing a device connected to the gateway and having a class name and at least one registered property, wherein the policy enforcement is operable to restrict the access of an application to a device service on the basis of at least one registered property of a device service.

18. Software instructions for causing a processor to implement the method of claim 16 or the policy enforcement mechanism of claim 17.

19. A machine-readable data carrier carrying the instructions of claim 18.

20. A method of generating a policy file for use at a service gateway which supports applications, the service gateway registering device services which each represent a device connected to the gateway and have a class name and at least one registered property, the method comprising: receiving a set of policy requirements at a server, remote from the gateway; generating a policy file at the server which specifies an application, or set of applications, and permissions for the application in terms of properties of a device service and values which the properties must have for that application to be permitted to access the device service; and, sending the policy file to the gateway for use at the gateway.

21. A method according to claim 20 wherein the properties include at least one of: a per-device identifier; device functionality; device manufacturer; device model name; device feature; device location; device domain.