Patent Description:
The Internet of Things (IoT) is a network of devices that allow the direct integration of the physical world with computer-based systems and networks. The devices are generally considered to be physical devices that have unique identifiers and are in most cases embedded with electronic sensors and/or actuators to monitor specific kinds of data. The devices are typically connected with private and/or public networks, which allow the live transfer and exchange of data with other connected devices and servers. A primary application of the loT is an automated system whereby information from the physical world can be stored, accurately monitored and processed for real time decisions.

The key to loT implementation is the interconnectedness of devices. Existing loT frameworks provide a software platform that can automatically organise communication between devices and networks as well as manage security, privacy, data storage and bandwidth available for the connected devices. These requirements are generally met by predefined protocols in each loT framework. In practice, this means that an loT system can comprise millions of devices that communicate between themselves and other networks. Some examples of existing loT frameworks include RTI™, Microsoft Azure™ loT, Cisco™ loT Cloud and the like.

Integrating or initialising several devices for connection to an loT network requires a significant amount of manual work by an individual for each device, generally for security reasons. This manual work typically includes manual input of device credentials, network passwords, authentication codes and other security parameters and can be an arduous process, especially when involving an initial connection or appropriation of a large number of devices, for example dozens of devices. Some large scale loT frameworks with many servers and loT enabled devices attempt to streamline this process or remove human involvement from the registration of devices to increase time efficiency and avoid human error. These frameworks usually may require a physical connection to specific servers or mainframes in a fixed location. However, such largescale models may not be suitable for smaller loT hubs or networks, for examples those associated with a user's household. The present disclosure provides techniques for overcoming existing drawbacks in integrating one or more loT enabled devices with an IoT network, in particular where the loT network is set up or maintained by a private individual, as can often be the case in a home or office loT networking providing in home or in office integration of devices.

<CIT> discloses a Wi-Fi network and Wi-Fi + NFC capable device which is provisioned with authentication information to access the Wi-Fi network, whereby this authentication information is received via NFC from another device in the Network.

Aspects and embodiments of this disclosure are now described by way of example for the purpose of illustration and with reference to the accompanying drawings, in which:.

In overview, methods and devices in accordance with the disclosure relate to provisioning one or more loT devices with connectivity to a user network. A portable token is associated with a user network, such as a home or office network. The token can enable one or more devices that are in proximity with it to connect to the user network. Therefore, the token herein described is understood to represent, or act on behalf of the user network, or one or more computing devices or server in the user network, to ensure that the device has all the information and/or permissions and/or settings required for it to establish a connection to the user network. Thus, the token acts as or represents the user network for provisioning a device to connect to the user network, so that such provisioning need not be done by the user network and is done by the token instead. The token being capable of representing the user network can be understood to mean the token being capable of association with the user network to facilitate connection of a device to the user network. Consequently, the token representing the user network can be understood to mean being associated with the user network to facilitate connection of a device to the user network. For example, the token may be associated with the user network by receiving configuration information for passing on to a device to be connected so that the configuration information need not be provided to the device by the user network but can instead be provided to the device by the token to enable the device to connect to the user network.

In a first aspect, a wireless token capable of representing a user network is disclosed. The token comprises one or more processing modules. The processing modules are configured to authenticate the token with the user network. To authenticate the token, the processing modules may be configured to provide data specific to the token to the user network. The data may comprise identifiers, passwords or the like that are transmitted to the user network, so that the user network can verify the identity of the token. In some embodiments, the user network performs one or more checks to establish that the token in question is authorised to have access to the user network. The user network to be represented by the token, once authenticated, may comprise a plurality of other loT devices that are communicatively coupled with each other and share data with each other to operate in the user network. The processing modules are further configured to, responsive to said authentication, obtain and store configuration information for enabling the token to communicatively couple with the user network one or more devices that are located at or within a defined proximity to the token. In some embodiments, the obtained configuration information from the token comprises executable instructions to configure a given device among the one or more devices to communicate and share data with the plurality of IoT devices that are already part of the user network. For example, the configuration information may include network security permissions and/or access codes etc. In another preferred embodiment, the defined proximity is a defined distance or distance range, for example a distance in the range of less than <NUM> (<NUM> to <NUM>), or less than <NUM> (<NUM> to <NUM>), between the token and the one or more devices. The processing modules are also configured to, responsive to a wireless signal received from a device among the one or more devices, establish a temporary secure communication channel between the given device and the token, and provide the configuration information from the token to the given device using the temporary secure channel. The configuration information may comprise settings, parameters and the like and/or executable instructions, to enable the given device to establish a connection with and operate in the user network based on the obtained configuration information. Finally, in some embodiments the token may be configured to register the given device with the user network.

Advantageously the token can provision an loT device with configuration information that the loT device requires to connect to a user network, when the token is proximate to the loT device. In this way, a secure, fast and efficient technique for automatically establishing a connection with a user network is enabled. In some embodiments, the configuration information that is to be transferred from the token to the device are in the form of executable instruction. This means that once transferred and installed on the device, the instructions are configured to run or be executed on the device to perform a function, or series of functions that cause the device to operate in a manner dictated by such functions. In some embodiments, the executable instructions are configured to perform such functions irrespective of the type of device, i.e. the executable instructions will perform the functions irrespective of the device that they are installed in.

According to the invention, the configuration information comprises executable instructions to configure the given device to be unresponsive to any further configuration information received from one or more devices representing networks other that the user network that is associated with the token. For instance, the executable instructions may include updating one or more setting in the device or setting a flag once the configuration information from the token has been successfully installed. This setting or flag may be set to identify the token and/or user network, and thereby prevent running configuration information from devices or token that are not associated with the user network. <NUM> Therefore, advantageously the loT device that is provisioned by the token is prevented from connecting to a network other than the user network. This increases security for the loT device and the user network by preventing unauthorised access by other networks.

In some embodiments, the configuration information from the token comprises executable instructions to configure the given device to respond to further or updated configuration information received from the same token, when the token is at or within the defined proximity. The executable instructions may further be configured to configure the given device to operate in the user network based on the received further or updated configuration information. Therefore, advantageously an loT device provisioned by the token can be reconfigured for the user network by the same token at or within the defined proximity (and only by the same token where configuration by other tokens is prevented). This allows for secure updating of user network credentials, and other information such as setting, parameters or firmware updates, for the loT device.

In some embodiments, the configuration information from the token comprises executable instructions that require the given device to be reset in the presence of the token at the defined proximity, prior to configuring the given device to operate based on further or updated configuration information from the user network or new configuration information from any other network. Furthermore, the configuration information may also configure the given device to be unresponsive to the device reset if the token is not present within the defined proximity of said one or more devices. Therefore, in such embodiments, an IoT device provisioned by the token can be reset to enable it to be configured for a different network and/or reconfigured for the same user network, but only when the token is in proximity of the loT device. This secures the loT device against unauthorised configuration or reconfiguration requests by requiring the device to be reset only when the token is proximate to it. Furthermore, the additional security of allowing a reset to take place only when the token is in proximity of the device prevents an unauthorised reset which may erase any earlier settings for a user network.

In some embodiment, the token is configured to communicate with the one of more devices using a short-range communication protocol such near -field communication (NFC) or Bluetooth™. In some embodiments, the token may be wearable by a user and may take the form of a ring, armband, necklace, key card or fob or other wearable device, or may be embedded in a device such as a mobile phone, smart phone, tablet computer, smart watch, or the like.

In a second aspect, a device capable of wireless communication is disclosed. The device comprises one or more processing modules configured to operate to detect a token as described above proximate to it. The one or more processing modules are configured to obtain configuration information from the token for registering the device with the user network represented by the token to
establish a connection with the user network, and to operate in the user network based on the obtained configuration information.

For example, to operate based on or on the basis of configuration information is understood herein to mean that the device can operate in the user network using the configuration information directly or indirectly.

In some embodiments, the device is capable of communication with a plurality of tokens as described above, each representing the same user network. This device is thus capable of obtaining configuration information that is specific to each of said plurality of tokens for operating in the user network when the device is activated by one token among the plurality of token. Therefore, advantageously the device can be configured to operate in a user network in a certain manner based on the configuration information of the token that activates the device. This provides for applications where one or more tokens have one or more different permissions associated with the same user network, such as multiple personalised key cards for a system of locks in a building.

In some embodiments, the device is an loT enabled device, wherein the user network is an IoT network including a plurality of other loT devices registered to the network.

In a third aspect, a user network represented by at least one token as described above is disclosed. The user network comprises at least:
a plurality of devices, for example as described above, that are communicatively coupled with each other and share data with each other to operate in the user network. The user network also comprises a router or a control module for connecting the user network with one or more external wireless networks and a database storing information relating to each of plurality of devices and data exchanged between them in the user network.

Thus, the above-mentioned router, control modules, data base etc. are part of the same user network that is associated with the token. In some embodiments, the token may be communicatively coupled with all devices in the user network to share. For instance, the token will be able to connect to the database or one or more registers in the network to share details of one or more devices that has recently been provisioned with configuration information from token.

In a fourth aspect, a method for provisioning connectivity with a user network for one or more devices capable of wireless communication is disclosed. The method comprises detecting, by the one or more devices, a token proximate to the one or more devices, the token having been previously authenticated for managing communication of the one or more devices with the user network. The token then establishes.

In a fifth aspect, a system for implementing the method of the fourth aspect is disclosed. The system comprises at least a user network as set out in the third aspect; at least one token as set out above in the first aspect for representing the user network; and one or more devices as set out above in the second aspect, to be connected to the user network.

Some specific components and embodiments are now described by way of illustration with reference to the accompanying drawings, in which like reference numerals refer to like features.

With reference to <FIG>, for the purpose of illustration, the user network will be described in the following as an loT network that allows transfer of data between connected devices. Typically, devices that connected within an loT network include routers for directing communication within and outside the loT network, control panels and/or servers to control data transfer, one or more databases to store information, one or more computing devices using the data transferred etc. <FIG> illustrates an example of an loT network. It will be appreciated that the present description is not limited to the user network being an loT network.

With reference to <FIG>, a token <NUM> is seen for <NUM> representing a user network <NUM>, as explained above, and be used for connects one or more loT enabled devices <NUM> to the user network <NUM>. The token <NUM> can be a mobile phone, an application running on a mobile phone, a smartwatch, or any wearable device that is to be authenticated for association with an existing user network <NUM>, before the token <NUM> can represent the user network <NUM>. For example, the user network <NUM> may be a trusted or private user IoT network within a home or office space etc. The user network <NUM> may be one or an IoT network, home network or office network.

The authentication of the token <NUM> with the loT network <NUM> can be established by known wireless communication protocols and/or using a secure and reliable end-to-end session <NUM> for such authentication. As part of the authentication process, transfer of one or more of security credentials of the user network <NUM>, permissions specific to the token <NUM> in question, data verification codes, passwords and the like and other security information takes place using one or more known device authentication techniques. Once the token <NUM> is authenticated, the device becomes a trusted device for representing the user network <NUM>.

Once authentication of the token <NUM> with the user network <NUM> is successful, the token <NUM> is provided with data and/or generic device credentials for securely provisioning one or more devices <NUM> to connect with the user network <NUM>. Thus, provisioning is understood as the process by which the one or more devices <NUM> can be enabled by the token to connect to the user network <NUM>. Such data and/or generic device credentials is preferably transferred to the token via the same secure communication link <NUM>. Some examples of this may be executable instructions to implement unique network and device security permissions, executable instructions to set up network and device credentials for communication, unique identifiers, access codes etc., which are collectively referred to herein as configuration information. The configuration information may preferably be encrypted during the transfer, to ensure secure connectivity and transfer of configuration information between the user network <NUM> to the token <NUM>. Preferably, one or more processing modules or a control system or server within the user network <NUM> is responsible for providing such configuration information from the user network <NUM> to the token <NUM>.

Once the configuration information, which is specific to the token <NUM> from user network <NUM>, is installed in one or more processing and/or storage modules of the token <NUM>, the token is then enabled to provision one or more devices <NUM> to be connected to or associated with the user network <NUM>. When the configuration information from the token <NUM> is installed on a device <NUM>, as will be explained in more detail below with reference to <FIG>, the device <NUM> will then be enabled to automatically join or connect to the user network <NUM> without any further action required to be taken. The device <NUM> is not part of the user network <NUM> prior to provisioning by the token <NUM>, as depicted in <FIG>, and is thus yet to be integrated or connected with the user network <NUM>. The provisioning of the device <NUM> with configuration information may also be carried out when the token in not within a location boundary associated with the network or network range, e.g. if the user network <NUM> is a network in a user's home, the token can preferably enable a new device <NUM> to be provisioned for connectivity with the user network <NUM> outside of the user's home location or outside a pre-defined network perimeter of the user network <NUM> or out of range of the user network <NUM>.

More than one token <NUM> may be authenticated to represent the user network <NUM>. For instance, in a household with four inhabitants, each inhabitant may each have their own token <NUM> that may be enabled to provision one or more device <NUM> to connect to the user network <NUM>, for example based on configuration information that is specific to each token <NUM>. In some embodiments, when one or more tokens <NUM> are authenticated by user network <NUM>, a register of such tokens <NUM> may be generated or updated within the user network <NUM>, and any new or further authenticated tokens <NUM> can be added to the register. More than one device <NUM> can be connected to the user network <NUM> by a token <NUM>. For instance, a household with several loT devices such as smart lights and heating systems, set top boxes, alarm systems, smart kitchen appliances, stereo systems etc. is envisioned. A register of all such loT enabled devices connected to the user network <NUM> may be generated, and any new devices <NUM> that are successfully connected to the user network <NUM> by one or more tokens <NUM> are then added to this register.

Registers with information in relation to token(s) <NUM> or connected device(s) <NUM> may be stored and accessed from a database or a secure storage module, which may be a device that is part of the user network <NUM>; or the registers may be stored at and accessed from a cloud storage platform via a gateway or router that is within the user network <NUM>.

With reference to <FIG>, using a token <NUM> that has already been authenticated by a user network <NUM> for provisioning a device <NUM> to connect with the user network <NUM> is now described. The token <NUM>, user network <NUM> and device <NUM> in <FIG> are understood to be the same as the token <NUM>, user network <NUM> and device <NUM> in <FIG>. Establishing connectivity or initialising a communication session using a private or home WiFi network is a common method for connecting devices to an access point for the user network <NUM>. However, when there are many of potential devices in the range of WiFi connectivity, this causes difficulty in selecting a device for connection. Additionally, secure communication with a new device, not previously connected to the user network <NUM> is presently possible with the individual input of user IDs, passwords, etc or a manual action in relation to activating a WiFi button or the like within the user network <NUM>, that can detect and register new devices. This process is time consuming and involves repeating the same timeconsuming process for each new device that requires to be connected to other devices in the user network <NUM>.

For the token <NUM> to provision a device <NUM> to connect to an associated IoT network, which the token represents, the token <NUM> establishes a connection with the device <NUM>. Such connection between the device and token is established using methods such as near-field communication (NFC), radio-frequency identification (RFID) or any other proximity-based communication methods that both, the token <NUM> and the device <NUM> are enabled for. In a preferred implementation, the communication link <NUM> in <FIG> for authentication may be closed, or indeed replaced by a further communication link <NUM> so that the user token <NUM> after authentication may still be connected to the user network <NUM>.

The connection between a token <NUM> and a device <NUM> in a preferred implementation is possible when the device is at or within a predefined proximity or distance, for example <NUM> to <NUM> centimetres, or in some cases less than <NUM> centimetres, from the token. For example, NFC a range of <NUM> centimetres, and Bluetooth™ can have different ranges depending on emission power of a device, i.e. class <NUM> has a range of <NUM> meter and class <NUM> has a range of less than <NUM> meters. Although a predefined proximity or distance is not to be limited to the above-mentioned distances, ideally it is a preference that the distance is not more than <NUM> meter, away. In some embodiments, the defined proximity may be the same as the distance dictated by the short-range communication method that is used between the token <NUM> and the device <NUM> that is to be provisioned. In other embodiments, the defined proximity may be a set distance which may be enforced on the token <NUM>, for instance a setting for the token <NUM> that prevents the token <NUM> from connecting to a device, such as device <NUM> that is not already part of the user network <NUM> unless it is at or within the set distance.

In some implementations, a feature such as a button on the device <NUM> that is to be connected may need to be activated to search and detect a token <NUM> proximate to it. Such detection may be performed by the same known short range and proximity based wireless methods as explained above. This ensures that only the device <NUM> and the token <NUM> that is within the defined proximity of each other are connected for further provisioning. This prevents other undesired tokens or devices from provisioning the device to work with or connect to a different loT network.

In some embodiments, the token <NUM> only functions when activated by the user, for example by fingerprint recognition, password input, face recognition, etc. This ensures that only the owner of the token <NUM> can activate it for connecting to one or more devices <NUM>.

Once connected, a temporary secure communication channel <NUM> is established between the token <NUM> and the device <NUM>. The secure channel <NUM> is a temporary one, defined by the same defined proximity as set out above, and functions for to ensure that configuration information, which is specific to a token <NUM>, as described above in <FIG>, is successfully transferred. Hence, once the token <NUM> transfers configuration information to provision the device <NUM> to connect to the user network <NUM> represented by the token <NUM>, the secure channel <NUM> is closed or disconnected as this channel <NUM> between the device <NUM> and the token <NUM> is no longer required. This is because after the transfer of the configuration information, the device <NUM> will be able to connect to the user network <NUM> and other devices in the user network <NUM> based on the data in the configuration information. If the configuration information transfer is not completed and the communication channel <NUM> is broken, for example if the token <NUM> is out of range, the device <NUM> may in some implementations returns to an original state. In some implementations, a signal may be sent from the user network <NUM> to the token <NUM> to validate that the configuration information is transferred to the device <NUM>. In other implementations, such a signal can be initiated from the device <NUM> through the user network <NUM> to the token <NUM>. In some implementations, the token <NUM> may be configured to provide a visual or audible notification of successful transfer of configuration information to a user.

When the secure channel <NUM> is established, the token 104b is configured to automatically provide the configuration information to the device <NUM>. Once the configuration information from the token <NUM> is installed on the device <NUM>, the device <NUM> can now communicate with, and function as part of, the user network <NUM>. Thus, by installing configuration information for the user network <NUM> using the token <NUM>, the user network <NUM> no longer needs to send its credentials each time a new device is required to be registered to the user network <NUM>, and no manual input of credentials is needed. This reduces available bandwidth usage within the user network <NUM>, and enables an easier, secure and automatic provisioning of connectivity with the user network <NUM>.

In some implementations, once the secure channel <NUM> within the defined proximity is closed and the device <NUM> has been provisioned with configuration information, there may be a communication link present between the device <NUM> and the token <NUM>, which may the function in the same manner as a communication link <NUM> that may exist between the network <NUM> and token <NUM> in <FIG>. The link <NUM> is not limited to short range or proximity-based protocols and is not intended for the transfer of configuration information. The link for example may merely indicates that the token <NUM> and/or the device are part the user network <NUM> and can be communicatively coupled with other devices that are part of the user network <NUM>.

With reference to <FIG>, the operation of the device <NUM> that has now been provisioned with configuration information for connecting to a user network <NUM> using a token <NUM> is described. The configuration information that is sent from the token <NUM> to the device <NUM> comprises at least one set of executable instruction that perform one or more of the below functionalities of the device <NUM> to operate in the user network <NUM>.

To implement a first functionality, the configuration information comprises executable instructions to configure the device <NUM> to establish a connection to the user network <NUM>, as depicted by communication link <NUM> in <FIG>, without any further action or input required from the user network <NUM> or the device <NUM>. This connection <NUM> with the user network is automatically established once the configuration information is installed in the device <NUM>. As mentioned above, the configuration information comprises the required access codes, and permissions etc. required for the link <NUM> to be established.

To implement a second functionality, the configuration information comprises executable instructions to configure the device <NUM> to be unresponsive to any further configuration information received from one or more devices or token representing one or more networks other that the user network <NUM> that is associated with the token <NUM> that installed the configuration application. Thus, once provisioned by the token <NUM>, the device <NUM> is prevented from connecting to a token or device or a network other than the user network <NUM>, and connected devices and tokens associated with the user network <NUM>. This increases security for the loT device <NUM> and the user network <NUM> by preventing unauthorised assess by other networks.

To implement a third functionality, the configuration information from the token <NUM> comprises executable instructions to configure the device <NUM> to respond to additional configuration information received from the token <NUM>, only when the token <NUM> is at or within the defined proximity. This is so that the device can then operate in the user network <NUM> based on the additional or new configuration information for the same network <NUM>. This is to allow for a secure and easy update of user network <NUM> permissions specific to the configuration information from the token <NUM>. This update can only be done using the same token <NUM>, when in the defined proximity. In a preferred implementation, this process will require a further temporary secure channel, like channel <NUM> in <FIG> to be established.

To implement a fourth functionality, the configuration information from the token <NUM> comprises executable instructions that require a device reset for a given device <NUM> in the presence of the token <NUM> at the defined proximity, prior to configuring the device <NUM> to operate based on further or updated configuration information from the user network <NUM> or indeed any other network. Furthermore, the configuring information also configures the device <NUM> to be unresponsive to the device reset if the token <NUM> is not present within the defined proximity of the device <NUM>. Thus, the device <NUM> provisioned by the token <NUM> can be reset to enable it to be configured for a different network and/or reconfigured for the same user network, with updated credentials, only when the token is within the defined proximity to the device <NUM>. This secures the device <NUM> against unauthorised configuration or reconfiguration requests by requiring the token <NUM> to be present during any device reset, within the defined proximity.

In some implementations, after a secure channel for transfer of configuration information within the defined proximity, such as secure channel <NUM> in <FIG>, is closed, there may be a further communication link <NUM> generated between the device <NUM> and the token <NUM>, which may then function in the same manner as a communication link <NUM> that may exist between the network <NUM> and token <NUM>. The link <NUM> is not limited to short range or proximity-based protocols and is not intended for the transfer of configuration information. Such link may ensure that token <NUM> and the device <NUM>, after being provisioned with configuration information, are part of the user network <NUM>, and can be communicatively coupled with other devices that are part of the user network <NUM>.

In some implementations, the device <NUM> is capable of communication with a plurality of tokens, each representing the user network <NUM>. This device <NUM> is thus capable of obtaining configuration information that is specific to each of said plurality of tokens for operating in the user network <NUM> when the device <NUM> is activated by a token. The device <NUM> may be configured to operate differently, based on the specific configuration information received for each token. Preferably, once the device <NUM> is connected to the user network <NUM> via a first token <NUM> for the user network <NUM>, disconnection from the user network <NUM> or connection to one or more other tokens, each with like functionality as the first token <NUM>, is not envisioned possible without permission from the first token <NUM>. This ensures that if the device <NUM> is stolen, it cannot function in another network without the associated token <NUM> to reset the device <NUM> to connect to a new network. Similarly, other tokens for the same user network <NUM> will also require permission from the first token <NUM>.

In the case where the device <NUM> is a system of door locks in some premises or building and each inhabitant owns a token, which may be the same as token <NUM>; one or more tokens can have full access to all locks/doors on the premises, while other tokens have limited access in varying degrees. For example, only tokens with full access to the all locks/door may have permissions that can open the lock, receive notifications when a lock is opened or closed or connect new tokens to the door lock, while tokens may only be able open the locks/doors in certain locations in the premises.

With reference to <FIG>, a flow diagram summarising the method for provisioning a device with connectivity with a user network is disclosed. <FIG> is to be read and understood in conjunction with <FIG>, <FIG> and <FIG>. The reference to the user network <NUM>, token <NUM> and device <NUM> in the steps of <FIG> explained below, are the same as their respective counterparts explained in <FIG>, <FIG> and <FIG> and include all the same functionality and features as explained above.

At step S302 the device <NUM> is activated so that the device <NUM> can detect a token <NUM> proximate to it, for example within <NUM> of the device, for example as explained above in relation to <FIG>.

At step <NUM> the detected token 204is detected to be in proximity and, at step306, in response to the detection, a temporary secure communication channel, such as the channel <NUM>, for example described above in relation to <FIG>, is set up between the token <NUM> and the device <NUM>.

In step <NUM>, configuration information specific to the token <NUM> for provisioning the device <NUM> with connectivity to a user network represented by the token <NUM> is transferred from the token <NUM> to the device <NUM>. This may, for example, take place in the manner as explained in <FIG>. The secure channel <NUM> is then closed at step <NUM>, for example once the configuration information is installed on the device <NUM>.

In step <NUM>, the device provisioned with the required configuration information, for example in the same manner as explained in relation to the device <NUM> in <FIG>, can establish a connection to a user network <NUM> based on the configuration information that is specific to the token <NUM>.

<FIG> illustrates a block diagram of one implementation of a computing device <NUM> within which a set of instructions, for causing the computing device to perform any one or more of the methodologies discussed herein, may be executed. The computing device <NUM> may be a router or server in the user IoT network or one or more loT enabled devices within the user network. Similarly, the computing device <NUM> may also be implemented to be the device or token described herein. In alternative implementations, the computing device <NUM> may be connected (e.g., networked) to other machines in a Local Area Network (LAN), an intranet, an extranet, or the Internet. The computing device may operate in the capacity of a server or a client machine in a client-server network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The computing device may be a personal computer (PC), a tablet computer, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a web appliance, a server, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single computing device is illustrated, the term "computing device" shall also be taken to include any collection of machines (e.g., computers) that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.

The example computing device <NUM> includes a processing device <NUM>, a main memory <NUM> (e.g., read-only memory (ROM), flash memory, dynamic random-access memory (DRAM) such as synchronous DRAM (SDRAM) or Rambus DRAM (RDRAM), etc.), a static memory <NUM> (e.g., flash memory, static random-access memory (SRAM), etc.), and a secondary memory (e.g., a data storage device <NUM>), which communicate with each other via a bus <NUM>.

Processing device <NUM> represents one or more general-purpose processors such as a microprocessor, central processing unit, or the like. More particularly, the processing device <NUM> may be a complex instruction set computing (CISC) microprocessor, reduced instruction set computing (RISC) microprocessor, very long instruction word (VLIW) microprocessor, processor implementing other instruction sets, or processors implementing a combination of instruction sets. Processing device <NUM> may also be one or more special-purpose processing devices such as an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), network processor, or the like. Processing device <NUM> is configured to execute the processing logic (instructions <NUM>) for performing the operations and steps discussed herein.

The computing device <NUM> may further include a network interface device <NUM>. The computing device <NUM> also may include a video display unit <NUM> (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)), an alphanumeric input device <NUM> (e.g., a keyboard or touchscreen), a cursor control device <NUM> (e.g., a mouse or touchscreen), and an audio device <NUM> (e.g., a speaker).

The data storage device <NUM> may include one or more machine-readable storage media (or more specifically one or more non-transitory computer-readable storage media) <NUM> on which is stored one or more sets of instructions <NUM> embodying any one or more of the methodologies or functions described herein. The instructions <NUM> may also reside, completely or at least partially, within the main memory <NUM> and/or within the processing device <NUM> during execution thereof by the computer system <NUM>, the main memory <NUM> and the processing device <NUM> also constituting computer-readable storage media.

The various methods described above may be implemented by a computer program. The computer program may include computer code arranged to instruct a computer to perform the functions of one or more of the various methods described above. The computer program and/or the code for performing such methods may be provided to an apparatus, such as a computer, on one or more computer readable media or, more generally, a computer program product. The computer readable media may be transitory or non-transitory. The one or more computer readable media could be, for example, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, or a propagation medium for data transmission, for example for downloading the code over the Internet. Alternatively, the one or more computer readable media could take the form of one or more physical computer readable media such as semiconductor or solid-state memory, magnetic tape, a removable computer diskette, a random-access memory (RAM), a read-only memory (ROM), a rigid magnetic disc, and an optical disk, such as a CD-ROM, CD-R/W or DVD.

In an implementation, the modules, components and other features described herein can be implemented as discrete components or integrated in the functionality of hardware components such as ASICS, FPGAs, DSPs or similar devices.

A "hardware component" is a tangible (e.g., non-transitory) physical component (e.g., a set of one or more processors) capable of performing certain operations and may be configured or arranged in a certain physical manner. A hardware component may include dedicated circuitry or logic that is permanently configured to perform certain operations. A hardware component may be or include a special-purpose processor, such as a field programmable gate array (FPGA) or an ASIC. A hardware component may also include programmable logic or circuitry that is temporarily configured by software to perform certain operations.

Accordingly, the phrase "hardware component" should be understood to encompass a tangible entity that may be physically constructed, permanently configured (e.g., hardwired), or temporarily configured (e.g., programmed) to operate in a certain manner or to perform certain operations described herein.

In addition, the modules and components can be implemented as firmware or functional circuitry within hardware devices. Further, the modules and components can be implemented in any combination of hardware devices and software components, or only in software (e.g., code stored or otherwise embodied in a machine-readable medium or in a transmission medium).

Unless specifically stated otherwise, as apparent from the following discussion, it is appreciated that throughout the description, discussions utilizing terms such as "receiving", "determining", "obtaining", "sending," "implementing," , "connecting", "detecting", "establishing" , "authenticating" or the like, refer to the actions and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.

Claim 1:
A wireless token capable of representing a user network, the token comprising one or more processing modules configured to:
authenticate the token with the user network;
responsive to said authentication, obtain and store configuration information for enabling the token to communicatively couple a device within a defined proximity to the token with the user network;
responsive to a wireless signal received from the device, establish a temporary secure communication channel between the device and the token; and
provide configuration information from the token to the device using the temporary secure communication channel, wherein the configuration information enables the device to establish a connection with and operate in the user network based on the obtained configuration information, characterised in that the configuration information comprises executable instructions to configure the device to be unresponsive to configuration information received from another device or token associated with a different user network.