Patent Description:
Further, computing system functionality can be enhanced by a computing system's ability to be interconnected to other computing systems via network connections. Network connections may include, but are not limited to, connections via wired or wireless Ethernet, cellular connections, or even computer to computer connections through serial, parallel, USB, or other connections. The connections allow a computing system to access services at other computing systems and to quickly and efficiently receive application data from other computing systems.

Interconnection of computing systems has allowed for the development and proliferation of so called Internet of Things (IoT) networks. In particular, physical devices can have computer hardware, software, and sensors implemented on the physical devices which allows the physical devices to communicate with each other in a networked fashion.

IoT networks are often controlled by a service provider that provides some type of service for the various devices in the IoT networks. As can be imagined, many service providers provide services to a number of different tenants, in a number of different locations, and/or at a number of different service-level agreements. Thus, a service provider may implement a number of different IoT solutions for the different locations, different tenants, and/or different service-level agreements. This may be done for certain optimization reasons.

For example, a localized solution can reduce network latency when data is passed between a device and the solution. In particular, a device may receive configuration information from a solution, collect data from sensors on the device and provide that collected data to the solution, and/or receive control information from the solution. If the solution is not within some proximate distance to the device, there may be an unacceptable amount of network latency in transferring data between the device and the solution.

Different solutions may be implemented for different tenants of a service. In particular, tenants may demand that a service provider keep their data on separate hardware and use separate software. Each solution is implemented using separate hardware and software. Thus, different solutions are often implemented to ensure data segregation between different tenants of the service.

Different solutions may implement different hardware and software having different capabilities. Thus, a service may be able to meet service level agreement for certain tenants by hosting devices for those tenants on solutions capable of meeting the agreed-upon service-level agreement. Additionally or alternatively, service providers, in the interest of efficiency, will want to use the minimum amount of hardware and software capabilities to meet a service-level agreement. Therefore, various devices for various tenants can be hosted by different solutions based on efficiency and based on meeting service-level agreements.

However, a given device may move between solutions for different reasons. For example, consider the case where a device is a vehicle or shipping container. As the device moves, a different location-based solution may be more appropriate for the given device. In an alternative example, the device may be transferred between different tenants of a service. Thus, this may cause the device to be more appropriately managed by a different solution than it was originally managed by when the device was provisioned. Alternatively, the service-level agreement for a given device may change, thus requiring the device to be serviced by a different solution.

As a result of devices moving between different solutions, a number of complexities are introduced into the system. One such complexity is the need to add and remove devices from the various registries of the solutions. Another complexity is that it can be difficult to query for devices. In particular, to find a particular set of devices, it may be necessary to query a number of different solutions. For example, there may be a desire to update all devices that are shipping container devices. However, different shipping container devices may be managed by different solutions. To update all the devices that are shipping container devices, it may be necessary to search across a number of different solutions to identify where those devices are located.

<CIT> discloses that upon an loT device first being powered on by a customer, an identification message may be communicated from the loT device to the provisioning service. In some examples, the loT device communicates the identification message directly to the provisioning service. In other examples, the identification message is communicated from the loT device to the provisioning service through one or more intermediary devices. In some examples, re-provisioning of an loT device may be performed as follows. First, a determination is made as to which new loT hub the loT device should be attached to (in base data). Next, the loT device is provisioned in the new loT hub. Then, the new connection information is returned. The loT device is then deleted from the registry of the old loT hub. <CIT> discloses a device to support mobility behind a gateway. Due to mobility, the device may change its parent gateway. In this example, the M2M device is a standard compliant device. Gateway <NUM> and <NUM> perform registration with the RADAR in the M2M core network. The M2M device is currently connected to gateway <NUM>, and performs registration with the RADAR in the core network via gateway <NUM>. As the devices are registered, device information, (e.g., registration information, device capability, sleep cycle, reachability status, device address, or the like), may be stored in the RADAR in the core network. The M2M device performs application registration with the RADAR in the core network via gateway <NUM>. The device moves behind gateway <NUM> and may tear down and reestablish device/application registration, and performs a procedure to register the device via the gateway <NUM>. When the RADAR in the core network receives device registration for the device via gateway <NUM>, the RADAR de-registers all applications of the device and signals it to gateway <NUM>. The device performs application registration(s) via gateway <NUM>. It is the object of the present invention to provide an improved method and system for managing devices in an loT environment. This object is solved by a computer system for managing devices in an loT environment according to claim <NUM>, and by a method of managing devices in an loT environment according to claim <NUM>.

IoT devices of a given type may be connected to different cloud solutions for data collection/aggregation/processing, but it can be desirable to manage all the identities through a single interface. For example, a geo-sharded solution (where devices are managed by special-purpose solutions based on physical proximity to the special-purpose solutions) may wish to apply a configuration to all devices across per-geo solutions from a single management interface. Some embodiments illustrated herein implement a central identity service, illustrated herein as a unified registry.

Embodiments illustrated herein include an improved system which includes a number of different special-purpose solutions each managing a number of different devices along with a unified registry that registers the devices across the various different special-purpose solutions. The unified registry stores an enumeration of the various devices controlled by a service amongst all of the different special-purpose solutions along with a correlation correlating each device to the special-purpose solution managing each device. This allows for a centralized location where information about all the different devices can be discovered. Alternatively or additionally, in some embodiments the unified registry can be used to push configuration information to various devices controlled by a service.

Reference is now made to <FIG> illustrates a service <NUM>. The service <NUM> is a distributed service that includes a number of different elements. In the particular example, the service <NUM> is a service for managing networks of devices. In some embodiments, the devices may be IoT devices or other smart devices.

Smart devices include various pieces of smart technology. The availability of compact smart technology has enabled virtually any device to be a smart device. For example, smart technology can be included in large smart devices such as shipping tankers, planes, cars, etc. However, miniaturization of smart technology also allows even small devices, such as watches, writing implements, coins, insect sized drones, etc. to be smart devices.

A smart device typically includes one or more processors. A smart device typically includes computer readable media, which may be, for example, computer readable memory. The computer readable media can store instructions that can be executed by the one or more processors. This gives the smart device the ability to perform digital data processing tasks. For example, the smart device can perform various computations, analyze data, generate data, generate communication data, etc..

The smart device also typically includes communication hardware. The communication hardware allows the smart device to communicate with other smart devices and/or with other digital entities. For example, the smart device may communicate with other smart devices in a network of smart devices. For example, the smart devices may be able to send and receive data generated and/or collected at the smart devices. For example, the smart device may be able to collect data from sensors included on the smart device. This sensor data can be shared among the various devices in the network of devices, and/or with solutions, for various uses.

Alternatively or additionally, smart devices may include controls. The controls may be configured to control equipment. The equipment may be items such as motors, blowers, heaters, chillers, lights, radios, etc. The smart devices may communicate with each other to cause the equipment to be controlled.

Alternatively or additionally, the smart device may be able to communicate with other digital entities, such as a special-purpose solution or other entity. For example, the smart devices may be able to communicate with the solutions for management. For example, a solution may include functionality for provisioning devices and/or controlling access to device data.

<FIG> illustrates a device management service <NUM>. The device management service includes computer hardware and software configured to manage devices for the service <NUM>. In particular, the device management service can cause devices to be updated, manage data collection from devices, manage device controls, etc..

The device management service <NUM> may include the ability to interface with various users of the service <NUM>. For example, the device management service may include functionality to connect with an app <NUM>. The app <NUM> may be implemented on a user device, such as a smart phone, tablet, computer, or other device. This allows a user to provide data to the device management service <NUM> to allow a user to request certain control over devices managed by the device management service <NUM>. For example, tenants of the service <NUM> may use an instance of the app <NUM> to request certain actions be performed on behalf of the tenant.

<FIG> illustrates a number of special-purpose solutions. In particular, <FIG> illustrates special-purpose solutions <NUM>-<NUM>, <NUM>-<NUM>, through <NUM>-n. The ellipses illustrated in the figure indicate that a configurable number of special-purpose solutions can be implemented in the service <NUM>. Typically, a special-purpose solution is a collection of hardware and software configured to interface with a set of devices for configuring the devices, transmitting control information to the devices, collecting data from the devices, etc. Typically, the hardware and software in a special-purpose solution are segregated from hardware and software in other special-purpose solutions.

For example, hardware and software for one special-purpose solution may be located in a particular location to service devices in that particular location. The hardware and software for that special-purpose solution is segregated by distance from hardware and software for different special-purpose solutions located in a different location for servicing a different set of devices in a different location.

In an alternative or additional example, hardware and software for a special-purpose solution may be segregated by a tenant of the service <NUM>. In particular, each tenant of the service is often a different enterprise or different entity that desires that their data be kept separate from other tenants of the service <NUM>. These different tenants may require the service <NUM> to maintain their data on different hardware and software than other tenants. Thus, the service will maintain different special-purpose solutions, including different hardware and software, for different tenants of the service <NUM>.

In an alternative or additional example, there may be a desire to segregate devices based on service level agreements for different devices. More capable hardware or software may be used for devices having a higher service level than other devices having a lower service level. Thus, special-purpose solutions may be specifically implemented based on service level agreements for devices such that appropriate hardware and software is utilized to comply with the service level agreements.

As discussed previously, each special-purpose solution interfaces with a plurality of devices. For purposes of example, attention is directed to the set <NUM> of devices. The set <NUM> of devices includes devices <NUM>-<NUM>-<NUM>, <NUM>-<NUM>-<NUM>, <NUM>-<NUM>-<NUM>, through <NUM>-<NUM>-m. Note that the ellipses illustrated indicate that a configurable number of different devices can be implemented in the set <NUM>-<NUM> of devices. Similarly, <FIG> illustrates a set <NUM>-<NUM> of devices and a set <NUM>-n of devices.

Note that the special-purpose solution <NUM>-<NUM> includes a registry <NUM>-<NUM>. The registry <NUM>-<NUM> includes an enumeration of the various devices in the set <NUM>-<NUM> of devices correlated with metadata for the devices.

When a device is brought on-line, the device management service will typically coordinate connecting the device to a particular special purpose solution. In particular, the registry at the special purpose solution will be updated to indicate that the new device can connect to the special purpose solution.

The special-purpose solution <NUM>-<NUM> also includes functionality for provisioning the various devices in the set <NUM>-<NUM> of devices. Provisioning may include, for example, setting access requirements for the device, provisioning authentication for the device, assigning endpoints for the device, configuring the device to communicate (for obtaining data and/or providing sensor readings) with certain other devices, installing executable instructions into memory of the device, defining property values for the device, configuring sensors for the device, etc..

As noted previously, special-purpose solutions may be implemented for a number of different reasons including location-based reasons, tenant isolation reasons, service level agreement reasons, etc. Also, as noted previously, the devices in the sets <NUM>-<NUM> through <NUM>-n, may be moved between sets such that different special-purpose solutions manage different devices over time.

A unified registry <NUM> is implemented. The unified registry includes an enumeration of all the devices managed by the service <NUM> correlated with the special-purpose solutions that manage the devices. Thus, for example, the unified registry <NUM> might contain an entry indicating that the device <NUM>-<NUM>-<NUM> is managed by the special-purpose solution <NUM>-<NUM>. Similarly, the unified registry <NUM> may include an entry that indicates that the device <NUM>-<NUM>-<NUM> is managed by the special-purpose solution <NUM>-<NUM>.

When a device moves between special-purpose solutions, unified registry <NUM> can simply update the entry for the device in the unified registry <NUM> to so indicate. For example, if the device <NUM>-<NUM>-<NUM> was to be moved from the special-purpose solution <NUM>-<NUM> to the special-purpose solution <NUM>-<NUM>, the device management service <NUM> could cause the unified registry <NUM> to simply update the entry for the device <NUM>-<NUM>-<NUM> in the unified registry <NUM> to indicate that the special-purpose solution <NUM>-<NUM> is now managing the device <NUM>-<NUM>.

Note that by implementing the unified registry <NUM>, which special-purpose solution is managing a particular device can be quickly identified. For example, the device management service <NUM> can simply query the unified registry <NUM> to find the special-purpose solution that is managing a device, rather than needing to query several of the special purpose solutions until it can be determined which special purpose solution is managing a device.

Note that in some embodiments, the unified registry <NUM> may further include additional metadata information about each device. For example, unified registry <NUM> may include information identifying model number, firmware version, initial app set for installation, location tags, desired use-cases, desired frequency of telemetry connections, and/or other information. This may allow entities to search and locate devices having certain characteristics by searching against the unified registry <NUM>, rather than needing to search each of the individual special purpose solutions <NUM>-<NUM> through <NUM>-n.

When a given device needs to provide data collected or generated at the device, or to receive information from other devices or services, this is coordinated through the appropriate special-purpose solution. However, in some embodiments, the device will query the unified registry <NUM> to discover the appropriate special-purpose solution. The unified registry <NUM> can notify the device which special-purpose solution it should connect to for sending and receiving information.

In one illustrative example, a device may be provisioned by a first special-purpose solution and may be connected to the first special-purpose solution for sending and receiving data. However, at a subsequent time, the device may be moved to a different special-purpose solution. For subsequent provisioning and/or data communication, the device will first query the unified registry <NUM> to determine which special-purpose solution the device should be communicating with. The device can then connect to the appropriate special-purpose solution as indicated in the unified registry <NUM>.

In some embodiments, the unified registry <NUM> synchronizes appropriate portions with various registries in special-purpose solutions. For example, as a device is moved between special-purpose solutions, the unified registry <NUM> will change the information that should be maintained by the various registries in the special-purpose solutions. In some embodiments, the unified registry <NUM> contains the authoritative record of which devices are managed by which special-purpose solutions. Thus, the unified registry <NUM> may include computing processes which are able to identify enumerations of devices for a particular special-purpose solution. All devices in the unified registry for a particular special-purpose solution can be identified, and a replacement registry can be created based on the identification. The replacement registry can then be pushed to the special-purpose solutions to replace the registry at the special-purpose solution. This can be done on a periodic basis.

Alternatively or additionally, this may be an event-based process such that any time a change is made to the unified registry changing the special-purpose solution correlated to a particular device, a new replacement registry is created for that special-purpose solution and pushed to the special-purpose solution. Alternatively or additionally, in some embodiments, when changes are made to the unified registry <NUM> changing the special-purpose solution correlated to a device, updates can be made to the affected special-purpose solution registries. For example, when a device moves from one special-purpose solution to another special-purpose solution, the change will be made in the unified registry <NUM>. The unified registry will then push the changes to the registries of the affected special-purpose solutions. In particular, the unified registry <NUM> will direct that an entry be removed from the registry of the special-purpose solution that the device is moving from. The unified registry <NUM> will also be directed that a new entry be made in the registry for the special-purpose solution to which the devices moving to. This will allow the registries in the special-purpose solutions to be accurately maintained.

Referring now to <FIG> an additional or alternative embodiment is illustrated. In some embodiments, each of the special-purpose solutions may include a shadow copy of the unified registry <NUM>. In some such embodiments, each special-purpose solution will include its own special-purpose registry, as illustrated previously, along with a shadow copy of the unified registry <NUM>. For example, <FIG> illustrates that the special-purpose solution <NUM>-<NUM> includes the registry <NUM>-<NUM> along with a shadow copy <NUM>-<NUM> of the unified registry <NUM>. The shadow copy typically includes a copy of all of the information in the unified registry <NUM>. Although, in some embodiments, the shadow copy may include only a correlation of devices with special purpose solutions, while excluding other metadata stored at the unified registry.

Using a shadow copy may be useful such that devices do not need to query the actual unified registry <NUM> to determine which special-purpose solution the devices should connect to. For example, if a device is proximate the special-purpose solution <NUM>-<NUM>, the device can query the shadow copy <NUM>-<NUM> of the unified registry <NUM> at the special-purpose solution <NUM>-<NUM> to determine which special-purpose solution the device should connect to. In this example, the device may discover that it should connect to the special-purpose solution <NUM>-<NUM> or that it should connect to a different special-purpose solution.

<FIG> illustrates that each of the special-purpose solutions <NUM>-<NUM> through <NUM>-n include shadow copies <NUM>-<NUM>, <NUM>-<NUM>, through <NUM>-n of the unified registry <NUM>. Thus, devices connecting to any special purpose solution can query the shadow copy at the special purpose solution to identify the appropriate special purpose solution for the device. Note that other entities may query the shadow copies to obtain device information.

The shadow copies may be updated on a periodic basis. Alternatively or additionally, the shadow copies may be updated any time there is a change to the unified registry <NUM>.

Note that embodiments may advantageously implemented over previous solutions, in that devices can be moved between special-purpose solutions even when the devices are not online. In particular, there is no requirement that device be connected to a network to be moved between special-purpose solutions. Rather, an entry can simply made in the unified registry <NUM> to indicate that the change has been made.

When the device has been off-line, the device will connect to the unified registry <NUM> to identify which special-purpose solution the device should connect to. In some embodiments, this may result in additional configuration pushed to the device when the device connects to a new special-purpose solution.

A number of examples will now be illustrated with respect to <FIG> and <FIG>. <FIG> illustrates an initial case where device <NUM>-<NUM>-<NUM> is coupled to the special-purpose solution <NUM>-<NUM>. <FIG> illustrates the system of <FIG> at a subsequent time when the device <NUM>-<NUM>-<NUM> is coupled to a different special-purpose solution, namely special-purpose solution <NUM>-<NUM>.

In this example, the device <NUM>-<NUM>-<NUM> initially connects to the special-purpose solution <NUM>-<NUM>. In this initial connection, the device <NUM>-<NUM>-<NUM> is provisioned by the special purpose solution <NUM>-<NUM> and is added to the registry <NUM>-<NUM> of the special-purpose solution <NUM>-<NUM>. The addition to the registry <NUM>-<NUM> is communicated to the unified registry <NUM> where the device <NUM>-<NUM>-<NUM> is correlated with the special-purpose solution <NUM>-<NUM>.

At a subsequent time, a determination is made to move the device <NUM>-<NUM>-<NUM> from the special-purpose solution <NUM>-<NUM> to the special purpose solution <NUM>-<NUM>. This may occur for a number of different reasons. For example, the device <NUM>-<NUM>-<NUM> may be transferred to a different tenant of the service <NUM>. Alternatively or additionally, the device <NUM>-<NUM>-<NUM> may move to a new physical location that is more proximate the special-purpose solution <NUM>-<NUM> than the special-purpose solution <NUM>-<NUM>. Alternatively or additionally, the device <NUM>-<NUM>-<NUM> may be associated with a different service level agreement.

To affect the change, the unified registry <NUM> is updated with the change. At some point, the device <NUM>-<NUM>-<NUM> identifies a need to identify the appropriate special-purpose solution for the device <NUM>-<NUM>-<NUM>. This may occur, for example, when the device <NUM>-<NUM>-<NUM> goes off-line and then reconnects to the service <NUM>. Alternatively or additionally, the device <NUM>-<NUM>-<NUM> may identify that it has been blocked from the special-purpose solution <NUM>-<NUM> as a result of the changes made to the unified registry <NUM>. The device <NUM>-<NUM>-<NUM> may then access the unified registry <NUM> (or a shadow copy, as illustrated in <FIG>) to identify which special-purpose solution the device <NUM>-<NUM>-<NUM> should connect to.

Referring now to <FIG>, a method <NUM> is illustrated. The method <NUM> may be practiced in an IoT environment. The method includes acts for managing devices in the IoT environment. The method <NUM> includes, as a result of a device being provisioned by a special-purpose solution, storing at a central unified registry a correlation of the device and the given special purpose solution (act <NUM>).

The method <NUM> further includes correlating the device to a different special-purpose solution at the unified registry (act <NUM>). For example, the correlation at the unified registry may be updated to assign a device to a different special-purpose solution.

The method <NUM> further includes causing subsequent configuration of the device to be performed by the different special-purpose solution (act <NUM>). For example, the different special purpose solution will provide additional, updated, or replacement configuration to the device.

The method <NUM> may be practiced where the unified registry allows devices in different locations to be managed by local special-purpose solutions to meet a predetermined latency threshold, while still providing a central location where entities can query for information about the devices.

The method <NUM> may be practiced where the unified registry allows devices for different tenants to be managed by tenant-specific special-purpose solutions to meet a predetermined tenant data isolation threshold, while still providing a central location where entities can query for information about the devices.

The method <NUM> may be practiced where the unified registry allows devices subject to different service-level agreements to be managed by service level agreement specific special-purpose solutions to meet a predetermined service level agreement threshold, while still providing a central location where entities can query for information about the devices.

The method <NUM> may further include storing metadata for the device at the unified registry, the metadata comprising at least one of model number or firmware version of the device.

The method <NUM> may further include providing from the unified registry, a shadow copy of the unified registry to the different special-purpose solution.

The method <NUM> further includes receiving a request from the device for an identification of a special-purpose solution for the device, and as a result, identifying the different special-purpose solution to the device so that the subsequent configuration of the device can be performed by the different special-purpose solution.

Embodiments of the present invention may comprise or utilize a special-purpose or general-purpose computer including computer hardware, as discussed in greater detail below. Such computer-readable media can be any available media that can be accessed by a general purpose or special-purpose computer system.

Physical computer-readable storage media includes RAM, ROM, EEPROM, CD-ROM or other optical disk storage (such as CDs, DVDs, etc.), magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general purpose or special-purpose computer.

When information is transferred or provided over a network or another communications connection (either hardwired, wireless, or a combination of hardwired or wireless) to a computer, the computer properly views the connection as a transmission medium. Transmissions media can include a network and/or data links which can be used to carry desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general purpose or special-purpose computer.

Computer-executable instructions comprise, for example, instructions and data which cause a general purpose computer, special-purpose computer, or special-purpose processing device to perform a certain function or group of functions.

Claim 1:
A computer system for managing devices (<NUM>) in an loT environment (<NUM>), the system comprising:
one or more processors; and
one or more computer-readable media having stored thereon instructions that, when executed by the one or more processors, configure the computer system to perform at least the following:
as a result of a device (<NUM>-<NUM>-<NUM>) being provisioned by a special-purpose solution (<NUM>-<NUM>), store (<NUM>) at a central unified registry (<NUM>) a correlation of the device and the given special purpose solution;
correlate (<NUM>) the device to a different special-purpose solution (<NUM>-<NUM>) at the unified registry, wherein each of the special-purpose solution and the different special-purpose solution is a collection of hardware and software configured to interface with a set of devices for configuring the devices;
receive a request from the device for an identification of a special-purpose solution for the device, and as a result, identify the different special-purpose solution to the device so that the subsequent configuration of the device can be performed by the different special-purpose solution; and
as a result, cause (<NUM>) subsequent configuration of the device to be performed by the different special-purpose solution.