GB2542383A

GB2542383A - Device management

Info

Publication number: GB2542383A
Application number: GB1516488.2A
Authority: GB
Inventors: Hussain Azhar
Original assignee: HANHAA Ltd
Current assignee: HANHAA Ltd
Priority date: 2015-09-17
Filing date: 2015-09-17
Publication date: 2017-03-22
Also published as: GB201516488D0

Abstract

A device management system has a processing node 102, which is connected to remote devices 101 via a wireless interface 106. A simplified coding interface 103 is used to generate code to allow the processing node to interact with the devices. The interface may use a graphical programming language. It may be a Web interface 108 accessible by a remote computer 107. The simplified code is converted to executable code by a compiler 109. The code may send instructions to the devices and may receive outputs from them. The devices may interact only with the node via a private communications channel or gateway. An authorisation unit 110 may authorise a user to execute the code and the code may present the user with the outputs. The system may count the number of times the code is executed and bill the user accordingly.

Description

DEVICE MANAGEMENT

This invention relates to a device management system and a method for managing a plurality of devices.

Application Programming Interfaces (APIs) provide a way for one software program to talk to another. Often APIs are used to allow one program to interrogate another for certain outputs, which it may then process for its own purpose. An API can allow a software program executing on one device to interrogate a software program that is executing on a different, physically separate device. An API can also allow a software program to interrogate a web service. Typically APIs are written by experienced programmers. APIs are also useful for allowing machines to talk directly to each other, without need to human interaction. Interest in machine-to-machine networks, which underpin the so-called Internet of Things, has increased massively over the last few years. There are many individuals and small businesses or organisations that would find it helpful to have a network of small, distributed devices at their disposal but who lack the experience or resources to implement such a network on their own.

Therefore, there is a need for a device management system that can make the benefits of having a network of distributed devices more accessible, so that a wider variety of people can make use of such devices for their own purposes.

According to a first aspect, there is provided a device management system comprising a plurality of devices, a processing node that is remote from the plurality of devices and a simplified coding interface that is configured to receive simple-form code, convert it into complex-form code and provide that complex-form code to the processing node, the processing node being configured to execute the complex-form code and thereby interact with the plurality of wireless devices via a wireless link.

Other aspects may include one or more of the following:

The processing node may be configured to send instructions to the plurality of devices in dependence on the complex-form code. The processing node may be configured to process output data received from the plurality of devices in dependence on the complex-form code. The processing node may be configured to provide one or more outputs from the processing to a user associated with the plurality of devices.

The plurality of devices may be configured to only interact with the processing node. The device management system may comprise a gateway connected to the processing node via a private communication channel, the processing node may be configured to interact with the plurality of devices via the gateway. The plurality of devices may be configured to communicate wirelessly with the gateway. The plurality of devices may be configured to only transmit their output data to the gateway. The plurality of devices may be configured to only act on instructions that they receive via a wireless link if those instructions are transmitted to them by the gateway. The plurality of devices may be configured not to be accessible via a public wireless infrastructure. The plurality of devices may not be IP addressable.

The plurality of devices may each comprise one or more sensors configured to generate output data.

The simplified coding interface may be configured to convert the simple-form code into an Application Program Interface (API).

The processing node may be configured to, before executing the complex-form code, authorise a user associated with the simple-form code as being permitted to execute that code. The processing node may be configured to count a number of times that it executes complex-form code associated with a particular user and provide this count to a billing agent.

The processing node and the plurality of devices may be configured to exchange data and/or instructions via a bidirectional wireless link.

The simple-form code forms a single program, the processing node may be configured to execute the complex-form code generated from that single program to thereby interact with the plurality of devices via the wireless link.

According to a second aspect, there is provided a method for managing a plurality of devices comprising receiving, at a simplified coding interface, simple-form code, converting the simple-form code into complex-form code, providing the complex-form code to a processing node that is remote from the plurality of devices and executing the complex-form code, at the processing node, to thereby interact with the plurality of wireless devices via a wireless link.

According to third and fourth aspects, there is provided machine readable code and machine readable storage medium having encoded thereon non-transitory machine-readable code for implementing one or more aspects of the described method.

The present invention will now be described by way of example with reference to the accompanying drawings. In the drawings:

Figure 1 shows an example of a device management system;

Figure 2 shows an example of a method for remotely managing a plurality of devices; and

Figure 3 shows an example of a device.

An example of a device management system is shown in Figure 1. The system comprises a plurality of devices, shown generally at 101, a processing node 102 and a simplified coding interface 103. A user may be able to indirectly gather and process data from the plurality of devices via simplified coding interface 103. The simplified coding interface may be configured to receive simple-form code, convert it into complex-form code and provide that complex-form code to the processing node. The processing node is preferably configured to execute the complex-form code. Executing the code will usually cause the processing node to interact with the plurality of devices. The term “interact” refers to some form of direct involvement of the processing node with the device. For example, the device may act on instructions received from the processing node or the processing node may process data received from the device. The data/instructions that the receiving party acts on (whether that is the processing node or one of the plurality of devices) thus originate with the other party (i.e. the other of the processing node or one of the plurality of devices)

Communication of data could occur in either direction, i.e. data could be sent from the processing node to the plurality of devices or from the plurality of devices to the processing node. The processing node is therefore preferably connected to each of the plurality of devices via a bidirectional wireless link to enable bidirectional transfer of data and/or commands between the processing node and the plurality of devices.

In a practical sense, it is envisaged that one organisation may manufacture and sell the devices and also run the processing platform that implements the processing node and the simplified coding interface. The devices and the processing platform may form a closed environment so that the devices are only accessible via the processing platform. The processing platform may, however, be readily available to users who own the devices through an online environment. The simplified coding interface allows users to create their own applications for interacting with their devices, which may number just one or two devices or could run to many hundreds.

The device management system may provide several advantages.

First, a user wishing to program many devices can do so by writing just one program, which the processing node will then use to exchange data with many devices. The user is thus saved from having to program each of the devices individually: a single program can configure multiple devices via an over-the-air update.

Second, the user has the ability to program the devices remotely.

Third, the user is able to program the devices using a simple-form code that does not require knowledge of a programming language.

Fourth, the complex-form code is executed by the processing node rather than the devices themselves so the devices can be simple and cheap to manufacture, meaning that they can be realistically deployed in high numbers. It also allows for forward hardware compatibility. The complex form code is able to be executed even with changes to the hardware and/or machine-level code of the devices. Changing the hardware does not impact the code or the deployment.

And finally the user does not need to provide any of the infrastructure for implementing what is effectively a distributed machine-to-machine network. All the user has to do is obtain one or more devices, write a program in simple-form code via the simplified coding interface and deploy the devices as he wishes.

The processing node is preferably remote from the plurality of devices, as shown in Figure 1. Therefore, it is convenient for communication between them to take place at least partially over a wireless communication network. Thus, the plurality of devices are suitably capable of wireless communication. The processing node may also be capable of wireless communication. Alternatively the processing node may be connected to a separate communicator 106, via which the processing node is capable of exchanging data with the plurality of devices. The communicator may include components such as an antenna, transmit/receive chain and baseband processor, as would be understood by the skilled person. The plurality of devices and the processing node may be capable of exchanging data via any suitable wireless communication protocol (whether they communicate directly or via an intermediary such as communicator 106). Suitable protocols might include, for example, Wi-Fi, RF, GSM, Weightless, LTE, 3G, 4G, 5G, Satellite and Bluetooth.

The simplified coding interface 103 may be configured to receive the simple-form code directly from a user. This code capture may be achieved by any suitable means. In one implementation, the simplified coding interface implements a web interface 108 that enables the user to enter simple-form program code via a web browser. The web interface is preferably accessible via any device that is capable of accessing the internet (represented generally at 107 in Figure 1), so that the user can enter simple- form code using a wide range of devices including a PC, laptop, smart phone, tablet etc.

The structures shown in Figure 1 (and indeed all block apparatus diagrams included herein) are intended to correspond to a number of functional blocks in an apparatus. This is for illustrative purposes only. Figure 1 is not intended to define a strict division between different parts of hardware on a chip or between different programs, procedures or functions in software. In some embodiments, some or all of the algorithms described herein may be performed wholly or partly in hardware. In many implementations, the processing node, simplified coding interface and communicator (and their respective functional parts) will be implemented by a processor acting under software control. The same is true of the authorisation unit 110, which is described in more detail below. In some implementations, the processor may form part of a distributed computing network (i.e. it may be implemented by the cloud, as shown at 105 in Figure 1). It may be implemented by a server running the appropriate software. Any such software is preferably stored on a non-transient computer readable medium, such as a memory (RAM, cache, hard disk etc) or other storage means (USB stick, CD, FLASH, ROM, disk etc).

An example of a method for remotely managing a plurality of devices is shown in Figure 2. The steps of the method are described below with reference to the system shown in Figure 1.

In step 201 the simplified coding interface 103 receives simple-form code. In most implementations this code is likely to be received via a web interface 108. The simple-form code represents a program to be run by the processing node 102. The term “program" is used herein to refer to any set of instructions from the user for running against his or her devices, irrespective of whether those instructions are expressed in simple- or complex-form code. The program will typically be aimed at causing the programming node to control one or more aspects of the devices’ behaviour and/or process one or more outputs generated by each device.

The simple-form code preferably embodies a very high level of abstraction. Typical high-level programming languages, such as C++ and Prolog, are strongly abstracted from the details of the computer. They are not device-specific, so they can be used to write programs that can be run on different devices. They are still difficult for nonprogrammers to use, however, since a good understanding of the language’s commands and structure is required. The simple-form code is preferably in a language that provides a level of abstraction that is higher still. Preferably the simplified programming interface provides the user with a series of preset operators that allow a user with no programming experience or knowledge of the programming language to straightforwardly write a program in simple-form code that represents an API for interacting with that user’s devices. Each operator may represent an action that is either to be performed by the device or, more commonly, performed by the processing node on an output of the device. The simplified coding interface could provide the user with a “drag and drop” interface where preset operators are selected and “dragged” into a list that represents the user’s program in simple-form code. The simple-form code could, for example, be written in a visual programming language such as Scratch or Catrobat. The simple-form code may allow users to use event driven programming.

The simplified programming interface may also allow users to write their own operators. Those operators will then form part of the simple-form code language that the user can use to write future programs. The simplified programming interface may also embed existing APIs from other sources into the simple-form code program. This enables experienced programmers more scope to tailor their programs.

In step 202 the simplified coding interface 103 converts the simple-form code into complex-form code that is capable of being executed by the processing node 102. In the example of Figure 1 this function is performed by compiler 109. At least some of the simple-form code may have been converted to complex-form code previously, e.g. where the simple-form code includes preset operators, in which case the compiler may access appropriate, pre-generated complex-form code as part of the conversion.

The complex-form code is suitably in a lower-level programming language than the simple-form code. Preferably the complex-form code implements an API that enables the processing node to interact with multiple ones of the devices 101. The processing node and/or the simplified programming interface may save the complex-form code as an API so that it can be retrieved for repeated use. In some implementations the complex-form code may be platform-specific. For example, the complex-code may be in a language that has a strong relationship with the architecture of the processing node. It follows from this that the simplified coding interface may be configured to control the compiler to generate the complex-form code to be in a language that is appropriate to the specific processor or group of processors that will be implementing the processing node for a specific execution of the user’s program. This enables the processing node to be implemented by different processors at different times and for implementation of the processing node to be potentially split across several processors. If the processor implementing the processing node changes, the compiler may reconvert the simple-form code into whichever complex-form code is appropriate for the new processor.

In step 203 the complex-form code is provided to the processing node 102. The processing node executes this code in step 204. As an initial step in the execution process, the processing node may interrogate device database 111 to identify which devices the program is to be executed against. That may be all of the devices associated with a particular user or it may be a subset of those devices. For example, the device database may sub-divide a group of devices that are associated with a particular user into a number of categories. Those categories could, for example, be associated with the device (such as a device type) or may have been designated by the user. For example, a user might want to group devices by their purpose, by a particular customer type they have been distributed to, by the location they were first deployed in etc. The web interface may be configured to allow users to designate which of their devices they want a program to be run against. This designation could be made on an individual or a group basis.

By executing the program against multiple devices, the device management system implements a common control structure for multiple, distributed devices. The program causes the processing node to interact with the devices. This may take the form of processing data gathered from one or more of the devices. The processing node may trigger the devices to send that data as it executes the program. Alternatively, or in addition, the devices may transmit data to the processing unit (or to its associated communicator) on a regular basis independently of the execution of the program. Incoming data is preferably tagged as originating from a particular device and/or as being associated with a particular user and stored in database 112. The program may then be considered as running against an in-cloud data set (as represented by database 112). The program is runs against the output of the devices, rather than on the devices themselves. The output of the processing may be provided to the user. The output may be provided to the user by simplified coding interface 103, e.g. via web interface 108, or via a different medium, e.g. text, SMS. Executing the program may also cause the processing node to transmit simple instructions from a predefined instruction set to one or more of the devices. Those instructions may trigger the device to send data or to perform other tasks that do not involve the device transferring data over the wireless link. These tasks could, for example, require the device to activate an internal or external actuator. The device might, for example, capture an input from a user, sound a buzzer or display a barcode or text message, or it might activate external switches or capture input from some form of machine to which the device is connected (either via a wired or wireless connection).

Having the processing node run the program rather than the devices separates the program from the devices and thus gives the user the option to update devices or change devices without having to alter the program that he has already written. The user’s program is essentially device agnostic.

In an optional additional step (which is not shown in Figure 2), the processing node may authorise that a user is permitted to run the program before it starts executing the complex-form code. The processing node may perform this step by contacting authorisation unit 110. The authorisation unit may, for example, confirm that the user is entitled to interact with a particular set of devices by requesting proof of identity, such as a user name and/or password. The authorisation unit might also confirm that the user is financially authorised to interact with a particular set of devices. In most instances this will involve checking that a prepaid account associated with the user has sufficient funds to cover the cost of executing the program. If the user is billed in arrears, it may involve checking that the user has no outstanding invoices.

In one implementation, the user may be charged per execution of the program. The user could also be charged per unit of data transferred wirelessly between the user’s devices and the processing node. Charging per execution of the program may be preferred for the following reasons: • It provides a transparent charging model: the user knows in advance exactly what running a program against his devices is going to cost. • The user is in control of costs since he controls the number of times that the program is run. • Charging per execution of the program removes any cost uncertainty associated with the device’s transferring data wirelessly at their particular location (given that they may not be in the possession of the user when they transmit, meaning that the user does not know where they are or the costs of transmitting from there). • Over-the-air costs remain the responsibility of the organisation that runs the processing platform. Such an entity is likely to be able to negotiate better rates for data transmissions than individual users because of the much higher volume of data that will be transmitted by the aggregated devices of many users than the devices of just one user. This entity is also able to control the amount of data that is transmitted over the air interface since the devices can be controlled by the processing node.

One of the advantages of having the processing node execute the user’s program rather than the devices themselves is that it renders it possible to straightforwardly charge per execution of the program. If the devices were to execute the program, charging per execution would require a monitoring agent on the device to count the number of times that the program is executed and report back to a billing agent. While it is certainly possible to implement this, it increases costs and complexity for the device. It is therefore preferable to have the processing node count the number of times that a particular user’s program is executed and report this to a billing agent.

Different rates could be charged per execution of a program depending on the number of devices against which the program is to be executed. Running the program against large numbers of devices is likely to require increased processing power from the processing node and more communications across the wireless link, justifying a higher charge per execution of the program.

An example of one of the plurality of devices is shown in Figure 3. The device comprises a battery 301, a sensor hub 302 and a communicator 303. The battery is preferably rechargeable. The sensor hub may include any sensor that enables the device to determine some quality of its environment. Examples include light sensors, temperature sensors, accelerometers, and humidity sensors. The communicator is configured for transmitting and receiving data over a wireless link. Data transmitted by the device will usually include output data, i.e. data (such as sensor or GPS data) that the device has generated for purposes other than those solely concerned with implementing communication and which is intended for the processing node. The communicator may include components such as an antenna, transmit/receive chain and baseband processor, as would be understood by the skilled person. The communicator is suitably configured to implement one or more wireless communication protocols. Examples include WiFi, Weightless, LTE, 3G, 4G, 5G, RF, GSM, and Bluetooth.

The device may have the ability to determine further information about its situation from data received via the communicator. For example, location unit 304 may be determined to use signals received wirelessly to determine a location of the device. Location unit 304 may, for example, may be capable to locating the device via GPS. In this example, the device also includes a display 305, which may be an e ink display to minimise power consumption. The device in this example does not include any other user interface. Significantly it does not include any means via which the user might instruct the device directly, i.e. there is no keyboard, touchscreen or other user input means. The device does not comprise an interface for directly receiving user input. The user’s only access to the device shown is thus via the simplified coding interface shown in Figure 1.

In other examples the device may comprise an interface for directly receiving user input. Any form of user interface may be added to the device, including a touch screen, keyboard etc. In some implementations, since the device is intended to be cheap to manufacture, a suitable user interface might just be a single button.

The device may also include one or more output connectors (not shown) to enable it to be physically connected to external devices, which it may be configured to control and/or gather data from.

Each device is preferably provided with only minimal processing power, as complex processors are likely to increase both the cost and power consumption of each device. The device will usually not be configured to perform any processing on output data it generates (such as sensor data) in the sense of transforming that data into something else. Instead any such transformative processing will be performed by the processing node itself. In some implementations the device may have no processor at all, outside of a processor that is likely to be required in the communicator for handling communications over the wireless link. The device may simply be a collection of one or more sensors that feedback output data to the processing platform to form an incloud dataset against which the processing node executes the user’s programs.

As with Figure 1, the structures shown in Figure 3 (and indeed all block apparatus diagrams included herein) are intended to correspond to a number of functional blocks in an apparatus. This is for illustrative purposes only. Figure 3 is not intended to define a strict division between different parts of hardware on a chip or between different programs, procedures or functions in software. In some embodiments, some or all of the algorithms described herein may be performed wholly or partly in hardware. In many implementations, at least parts of the communicator will be implemented by a processor acting under software control. Any such software is preferably stored on a non-transient computer readable medium, such as a memory (RAM, cache, hard disk etc) or other storage means (USB stick, CD, FLASH, ROM, disk etc).

The devices and the processing node preferably form a closed system. In other words the devices may not be accessible outside of the processing platform described above. This is for security reasons: devices that are generally accessible via APIs and the like are proving to be increasingly vulnerable to hacking and other malicious attacks. The devices may not be addressable by entities outside of the management system. For example, they may be provided only with private IP addresses. In other examples, it may be preferred to use a non-internet based protocol for communications between the devices and the processing node so that the devices are not IP addressable at all.

The devices may be configured not to send data to or act on instructions from any entity other than the processing node. This may require the devices to verify that the identity of the processing node before it acts on instructions or sends data to it. It may also require the devices to transmit data confidentially. Similar requirements may be made of the processing node (or its associated communicator). Any confidentiality and verification requirements may be met by the devices and processing node/communicator encrypting data for transmission over the wireless link. One straightforward way for achieving this is for the devices and processing node/communicator to encrypt communications between them using a shared secret, such as an encryption key. It is envisaged that in most applications the devices will be provided by the same company that runs the processing node, meaning that the shared secret can simply be pre-programmed into each device before it is provided to the user. If a shared secret is unfeasible because there is a risk of it being compromised, the devices and processing node/communicator may be configured to use a public/private key protocol to encrypt communications, including possibly encrypting communications based on a shared secret generated using their respective public/private key pairs.

One method is to have a dedicated gateway linking the processing node with the wireless network via which the processing node and the devices communicate. Communicator 106 could, for example, implement such a gateway. The gateway could be associated with an Access Point Name (APN), which a device wanting to transfer data to the processing node will use to address the transmission over the wireless link. The device will present the APN to the Mobile Network Operator infrastructure so that its output data is routed to the gateway. The gateway may be linked back to the processing node through a private, encrypted channel, such as a leased line. This provides a closed circuit for communication between the processing node and the devices This closed circuit means that the device does not need to be accessible via a public communication infrastructure. In fact the devices are preferably not accessible via a public communication infrastructure, which removes any need for the devices to be IP addressable, for example. If the devices do not communicate on the open internet, this closes a common route of attack by hackers, viruses or similar unauthorised users.

There are many potential practical applications for the device management system described above. A few examples are given below: • The devices could be used as a marketing tool for small businesses. For example, the devices could be configured to act as luggage tags, with the customer writing their name and address on one side of the tag and the other side of the tag having an e-ink display that the business owner can program to display a marketing message for the business via the simplified coding interface. The business owner may then update that marketing message in time, again via the simplified coding interface. The business owner might also distribute devices having a different form from the luggage devices but still with an e-ink display and update the messages on all the displays he has deployed using the same program. • The devices could be used by small businesses as a tracking tool to track goods safely to their destination. The small business owner could write a program to track the location of the devices placed in the same container as the goods and to monitor the outputs from the light, temperature and humidity sensors that might indicate that the container holding the goods has been opened or damaged during transit. • The devices could be used to monitor school children on a hike. Each child could be issued with a device, which, once activated, reports its location periodically to the processing node. The teacher supervising the hike can write a program via the simplified coding interface prior to the hike that will cause the processing node to monitor the periodically reported locations and alert the teacher (via the web interface) if the devices indicate that any children have strayed outside of a permitted area. • The devices could be distributed by a farmer around his land and used to monitor environmental conditions. The farmer can write a program to process the temperature, humidity and light conditions across his land and report back, for example, on which fields are likely to be most suitable for growing particular crops, which fields are likely to be ready for harvesting or which animals may need to be brought into barns because of low temperatures.

The applicant hereby discloses in isolation each individual feature described herein and any combination of two or more such features, to the extent that such features or combinations are capable of being carried out based on the present specification as a whole in the light of the common general knowledge of a person skilled in the art, irrespective of whether such features or combinations of features solve any problems disclosed herein, and without limitation to the scope of the claims. The applicant indicates that aspects of the present invention may consist of any such individual feature or combination of features. In view of the foregoing description it will be evident to a person skilled in the art that various modifications may be made within the scope of the invention.

Claims

1. A device management system comprising: a plurality of devices a processing node that is remote from the plurality of devices; and a simplified coding interface that is configured to receive simple-form code, convert it into complex-form code and provide that complex-form code to the processing node; the processing node being configured to execute the complex-form code and thereby interact with the plurality of wireless devices via a wireless link.

2. A device management system as claimed in claim 1, the processing node being configured to send instructions to the plurality of devices in dependence on the complex-form code.

3. A device management system as claimed in claim 1 or 2, the processing node being configured to process output data received from the plurality of devices in dependence on the complex-form code.

4. A device management system as claimed in any preceding claim, the processing node being configured to provide one or more outputs from the processing to a user associated with the plurality of devices.

5. A device management system as claimed in any preceding claim, the plurality of devices being configured to only interact with the processing node.

6. A device management system as claimed in any preceding claim, comprising a gateway connected to the processing node via a private communication channel, the processing node being configured to interact with the plurality of devices via the gateway.

7. A device management system as claimed in claim 6, the plurality of devices being configured to communicate wirelessly with the gateway.

8. A device management system as claimed in claim 6 or 7, the plurality of devices being configured to only transmit their output data to the gateway.

9. A device management system as claimed in any of claims 6 to 8, the plurality of devices being configured to only act on instructions that they receive via a wireless link if those instructions are transmitted to them by the gateway.

10. A device management system as claimed in any preceding claim, in which the plurality of devices are not configured to be accessible via a public wireless infrastructure.

11. A device management system as claimed in any preceding claim, in which the plurality of devices are not IP addressable.

12. A device management system as claimed in any preceding claim, the plurality of devices each comprising one or more sensors configured to generate output data.

13. A device management system as claimed in any preceding claim, the simplified coding interface being configured to convert the simple-form code into an Application Program Interface (API).

14. A device management system as claimed in any preceding claim, the processing node being configured to, before executing the complex-form code, authorise a user associated with the simple-form code as being permitted to execute that code.

15. A device management system as claimed in any preceding claim, the processing node being configured to count a number of times that it executes complex-form code associated with a particular user and provide this count to a billing agent.

16. A device management system as claimed in any preceding claim, the processing node and the plurality of devices being configured to exchange data and/or instructions via a bidirectional wireless link.

17. A device management system as claimed in any preceding claim, wherein the simple-form code forms a single program, the processing node being configured to execute the complex-form code generated from that single program to thereby interact with the plurality of devices via the wireless link.

18. A method for managing a plurality of devices comprising: receiving, at a simplified coding interface, simple-form code; converting the simple-form code into complex-form code; providing the complex-form code to a processing node that is remote from the plurality of devices; and executing the complex-form code, at the processing node, to thereby interact with the plurality of wireless devices via a wireless link.

19. Machine readable code for implementing a method as claimed in claim 18.

20. A machine readable storage medium having encoded thereon non-transitory machine-readable code for implementing a method as claimed in claim 16.

21. A device management system substantially as herein described with reference to the accompanying drawings.

22. A method substantially as herein described with reference to the accompanying drawings.