Patent Description:
<CIT> describes publish/subscribe messaging systems in which the spoke systems can vary the member of the hub collective that it attaches to. The spoke systems do not have to have a long lasting attachment to a specific hub system. Instead, it is described that the spoke systems can be redistributed when new spoke systems are added or removed. Child nodes can automatically change parent nodes if a parent node is modified or removed.

<CIT> describes a networked system for managing a physical intrusion detection/alarm including tiers devices and a rules engine and router to interact with the rules engine and rule engine results, where the router is configured to feed inputs to and receive outputs from the rules engine, and the router further configured to programmatically route results of rule execution by the rules engine to a hierarchical structure stored in computer storage for access by subscriber devices.

<CIT> describes a computer implemented method for server coverage of a publish-subscribe cluster comprising using one or more hardware processors to execute one or more shared subscriptions hubs each adapted to retrieve shared subscriptions information from a cluster comprising multiple servers executing multiple messaging engines of a publish-subscribe service for forwarding messages to a plurality of subscribing clients, each message is associated with one or more of a plurality of topics, receive shared subscriptions requests for subscribing for one or more of the topics from distributed subscriptions client(s) applying shared subscriptions for the topic(s) through subscription group(s) comprising a subset of the subscribing clients, connect to preferred messaging engine(s) selected according to the shared subscriptions information to serve each of the plurality of shared subscriptions requests and forward messages associated with the topic(s) received from the selected messaging engine(s) to the subscription group(s).

The same numbers are used throughout the drawings to reference like features and components. Moreover, the figures are intended to illustrate general concepts, and not to indicate required and/or necessary elements.

According to an object of the invention, there is provided a method of operating a device in a network as defined in claim <NUM>. According to another object of the invention, there is defined a device as defined in claim <NUM>. Preferred embodiments are covered by the appended dependent claims.

The disclosure describes techniques for providing a fully connective mesh network, including both inter device communication (e.g., between devices in the mesh network) and intra device communication (e.g., between "containers" and/or "virtual machines" within one or more devices). In an example, the necessity of past networks to provide a pathway between each device and/or process (e.g., software running on a device) and all other devices and/or processes is obviated by the use of hubs. Each hub relays data, information, messages, etc., in a two-way manner between processes associated with that hub and with other hubs. The other hubs may be on remote devices or within "containers" or virtual machines on the same device as the hub.

In an example, each device on the network may be a utility meter (e.g., electricity, gas, or water meter), a computer (e.g., at a utility company headend), a smart transformer, an electrical substation, gas valves, water valves, water or gas pumps, electrical switching, gas storage and/or routing devices, or any other network device. Each device may have a hub (e.g., a "device hub"), which could be a software process configured to relay data between other processes (e.g., container hubs) operating on the device and other hubs on other devices. Each of the processes could be a software application, and could be configured to operate metrology devices, sensors, switches, valves, alarms, user interfaces, radios, powerline communications modems, etc. Each device may also include one or more containers or virtual machines. Each container may include a container hub and one or more processes associated with the container hub. In examples, each container may be associated with a customer, a metrology device, a task, etc. By putting such functionality in a container or virtual machine, security is enhanced, the likelihood of software incompatibility errors is reduced, software update functions are simplified, etc..

In example operation, a process in a container may send a message to the container hub. The container hub may relay the message to the device hub, and the device hub may relay the message to either: a process associated with the device hub; or a device hub on a second device. The device hub on the second device may relay the message to either: a process running on the second device; or a container hub of a container on the second device. The second container hub may in turn relay the message to an appropriate container process.

Some processes may generate or consume (or both) data. For example, a process associated with a switch or sensor may receive a command to change or confirm switch state, or report a sensor reading, or change a frequency of sensor readings. A process associated with a metrology device may report data at intervals, and a process associated with a radio may consume data in a transmission mode and generate data in a reception mode. A process associated with a valve may receive a command to open or close the valve (e.g., by operation of a motor) and may then report success or failure of the operation. Accordingly, processes may be associated with devices and may generate and/or consume data.

Such data may be published by one process and subscribed-to by another process. In this document, schemes of two general types are presented for the publication of data. The first scheme reduces overhead caused by subscription management, while the second scheme reduces network bandwidth consumption.

In a first scheme, data is transmitted from a data-generating process to the device hub of that process (either directly, or by way of the container hub of the process), and from that device hub, to all other device hubs. In the first scheme, each data-receiving device hub would determine if any process directly associated with the data-receiving device hub, or any process associated with any container of the device, had subscribed to the received data. If so, the device hub would forward the data to the appropriate hub and/or process. If not, the device hub would delete the data.

In a second scheme, data is transmitted from a data-generating process to the device hub of that process (either directly, or by way of the container hub of the generating process). The receiving device hub sends the data only to hubs (device hubs of other devices and/or container hubs on the device of the device hub) that have subscribed to the data.

<FIG> shows an example system or network <NUM> having both intra device and inter device hub and spoke structures to provide publication and subscription data exchange techniques. Within the system or network <NUM>, two example devices <NUM>, <NUM> are shown as representatives of a plurality of devices that might be present in networks configured using the techniques discussed herein. The example network may be configured as a mesh network <NUM>, utilizing radio frequency (RF) spectrum, powerline communication techniques, fiber optics, etc..

Device <NUM> may be a utility meter or other device in a utility or non-utility network of devices. A device hub <NUM> is in communication with processes A-D shown as <NUM>-<NUM>. The device hub <NUM> and processes <NUM>-<NUM> are typically software-defined processes, but could be fixed in the hardware of an integrated circuit, such as an application specific integrated circuit (ASIC). Each process may be dedicated to a particular task, such as: operating a radio; operating a valve or switch; operating a utility metrology device; operating sensor(s) (earthquake detection, tamper detection, temperature sensing, etc.), etc. The device hub <NUM> is configured to communicate with each process, and to provide data to which the process subscribes (e.g., a command to close a valve) and to receive data to be published by the process (e.g., metrology consumption data, sensor data, etc.). The device hub <NUM> may also be configured to communicate with other hubs and to exchange data as needed.

The device <NUM> includes two containers <NUM>, <NUM> for purposes of illustration. The use of containers (e.g., virtual machines) may enhance security, reduce software compatibility errors, simplify software update functions, etc. Container <NUM> is shown in an enlarged view to better illustrate its components. A container hub <NUM> is configured to communicate with the device hub <NUM> and with process(es) operating inside the container <NUM>. In the example shown, processes E-H <NUM>-<NUM> are configured to operate within the container <NUM>. Each process may be configured to do a particular job(s), such as the operation of sensors, switches, metrology units, valves, radios, modems, etc..

Within the mesh network <NUM>, each network device (e.g., device <NUM>) may be in direct communication with one or more other network devices (e.g., device <NUM>) using, for example, low power radio frequency (RF) device(s). To send information from the first network device <NUM> to the second network device <NUM> (assuming for a moment that they are not in direct communication), information is relayed by one or more other network devices in the mesh network <NUM>. In an example communication, container process <NUM> may send a message indicating that a valve was successfully closed. The message will be transmitted from the container process <NUM> to the container hub <NUM>. The container hub <NUM> will relay the message to the device hub <NUM>. The device hub <NUM> will relay the message to another device hub of another device within the mesh network <NUM>. In the relay process, one or more device hubs will receive the message and transfer it to an appropriate device hub so that the message reaches its destination (e.g., an upstream server at a utility company that is concerned with the valve closure confirmation of the message).

<FIG> shows additional example devices, configurations and techniques of the system or network <NUM>. The containers <NUM>, <NUM> are not shown for clarity and space. In the example shown, the networked device <NUM> (e.g., a utility meter or utility system component) includes a processor <NUM> and a memory device <NUM>. Actions taken by the device hub <NUM>, processes <NUM>-<NUM> and the objects in the containers <NUM>, <NUM>, etc., may be performed by actions taken by the processor in response to execution of statements contained in the memory device <NUM>. In an example, the processor executes a modern real-time multi-tasking operating system (e.g., based on Linux or similar) and the hubs (device hub and container hubs), processes associated with those hubs, and the containers and included processes (seen in <FIG>) are thereby operational.

The networked device <NUM> may include a plurality of data-generating and/or data-consuming devices <NUM>. Data-generating and/or data-consuming devices <NUM> may include valves, valve motors, sensors (temperature, motion, earthquake, pressure, etc.), radios, user interfaces, metrology devices, ultrasonic metrology devices, switches, and others. Each data-generating device and/or data-consuming device <NUM> may be controlled (fully or in part) by one or more processes <NUM>-<NUM>. In examples, each data-generating and/or data-consuming device may send data and/or instructions to one or more processes. This transmission may be performed by dedicated wiring or by connecting the sensors to a bus. Similarly, each process may send data and/or instructions to one or more data-generating and/or data-consuming devices <NUM>. In an example, a motion sensor may send data to a process attempting to detect earthquakes and a process attempting to detect meter tampering. In additional examples, a radio may send and receive data from a plurality of processes. And in a still further example, a process may control a valve, a valve opening/closing motor, and a valve-state sensor.

The example system or network <NUM> also shows incoming-data database <NUM> and an outgoing-data database <NUM>, which may be contained in the device hub <NUM> or may be located elsewhere but are accessible to the hub.

The incoming-data database <NUM> contains data received by the device hub <NUM> from (the outgoing-data databases of) remote device hubs. The incoming data may have been sent in case it is needed by process(es) on the device of the device hub <NUM> or because such processes subscribed to that data.

The outgoing-data database <NUM> contains outgoing data that is either: sent to all remote device hubs in case a process on that device needs that data; or is sent to select remote device hubs because processes on those devices have subscribed to the data.

The device hub <NUM> may receive incoming-data from devices that are different from the device of the hub. The incoming-data may be "buffered" in the incoming-data database <NUM>. A determination is made whether the data was subscribed-to by a process operating on the device of the hub. If there is a subscription, the device hub <NUM> sends the received data to the appropriate process(es). If there is no subscription, the incoming-data is deleted.

The device hub <NUM> may receive data from local processes on the device of the hub that is "buffered" in the outgoing-data database <NUM> until the data is sent to other processes, which may be operating on remotely located devices. In an example, a process (e.g., process <NUM>) may be in communication with an ultrasonic metrology unit (UMU) (i.e., a data-generating device <NUM>). The process <NUM> may send data obtained from the UMU to the device hub <NUM>, which may store the data in the outgoing-data database.

<FIG> shows additional detail of an example incoming-data database <NUM>. The incoming-data database <NUM> stores data-received at a first device from device hubs of other devices-in incoming-data data records <NUM> until the data can and/or should be sent to processes on the first device. The incoming-data database <NUM> may also store data (e.g., in records <NUM>) generated byprocess(es) of the device that is subscribed-to by other process(es) of the device.

The incoming-data data records <NUM> may include data broadcast from a plurality of devices on a mesh network. The broadcasts may include data that is subscribed-to by process(es) on the first device and may include data that has not been subscribed-to. In operation, the device hub <NUM> (as seen in <FIG>) consults a data structure <NUM> that includes data on processes of the device and their respective subscriptions to data. Using the data structure <NUM> and the incoming-data data records <NUM>, the device hub <NUM> determines which processes on the device subscribed to which different parts of the data available in the incoming-data data records <NUM>. The hub then appropriately provides the subscribed-to data (that is available on the incoming-data data records <NUM>) to process(es) on the device. In a first example, copies of the data may be sent to each subscribing process. In a second example, each subscribing process may be sent a link to the data, as located in an incoming-data data record <NUM> of the incoming-data database <NUM>.

Data may be present in the incoming-data database <NUM> that is not subscribed-to by any process, and such data may be deleted. Additionally, subscribed-to data that is no longer needed by any process may be deleted by the device hub <NUM> or the process(es) <NUM>-<NUM>, as indicated by the design of the system, including factors such as how many processes had subscriptions to the data.

<FIG> shows additional detail of an example outgoing-data database <NUM>. The outgoing-data database <NUM> stores data-generated by processes on the first device, which may have originated at one or more of the data-generating devices <NUM>-in outgoing-data data records <NUM> until the data can and/or should be sent to other devices. The outgoing-data database <NUM> may also store data (e.g., in records <NUM>) generated by process(es) of the device that is subscribed-to by other process(es) of the device.

In a first example of the outgoing data transmission, the data in the outgoing-data data records <NUM> is sent to all devices on a network and/or portion of the network. Addresses for the destination devices may be stored in the data structure <NUM>. Some of the destination devices may not need the data. While this example takes up more network and/or RF bandwidth than is required, it reduces the overhead of managing subscriptions.

In a second example, the device hub <NUM> uses data structure <NUM> to obtain addresses of all hubs in the network having subscriptions to data contained in each of the records of the outgoing-data data records <NUM>. The hub then sends appropriate data (i.e., the subscribed-to data) to appropriate (i.e., subscribing) hubs as indicated by the data structure <NUM>. While this action takes up less network and/or RF bandwidth than was required by the first example, it increases the overhead of managing subscriptions.

In some examples of the techniques discusses herein, the methods of operation may be performed by one or more application specific integrated circuits (ASIC) or may be performed by a general-purpose processor utilizing software defined in computer readable media. In the examples and techniques discussed herein, the memory <NUM> may comprise computer-readable media and may take the form of volatile memory, such as random-access memory (RAM) and/or non-volatile memory, such as read only memory (ROM) or flash RAM. Computer-readable media devices include volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules, or other data for execution by one or more processors of a computing device. Examples of computer-readable media include, but are not limited to, phase change memory (PRAM), static random-access memory (SRAM), dynamic random-access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disk read-only memory (CD-ROM), digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transitory medium that can be used to store information for access by a computing device.

As defined herein, computer-readable media does not include transitory media, such as modulated data signals and carrier waves, and/or signals.

<FIG> shows example techniques <NUM> by which incoming and outgoing data is efficiently received and sent by a network-connected device and by which incoming-data and outgoing data databases are maintained on the network-connected device.

At block <NUM>, an outgoing-data database is maintained. In the example of <FIG>, the outgoing-data database <NUM> may include data to be sent (e.g., in the form of outgoing-data data records <NUM>). In an example, the maintained database may include addresses of the remote hubs and/or remote devices, without information on the data subscriptions of each device (e.g., data structure <NUM>).

In the version of the techniques <NUM> seen at block <NUM>, a subscription to data by a remote device hub of a remote device may be added to the outgoing-data database. In the second version, the maintained database may include addresses of the remote hubs and/or remote devices, along with information on the data subscriptions of each device (e.g., data structure <NUM> of <FIG>).

At block <NUM>, first data from a first process operating on the device is received. In the example of <FIG>, the process <NUM> may send data (e.g., data the process has generated) to the container hub <NUM>. The container hub may send the data to the device hub <NUM>, where it is received. Similarly, the process <NUM> may generate and send data directly to the device hub <NUM>, where it is received. In the example of <FIG>, the data may be stored in a record <NUM> of the outgoing-data database <NUM>.

At block <NUM>, the first data is sent to a first remote device hub associated with a first remote device and associated with an entry in the outgoing-data database. In the example of <FIG>, the data may be sent by the device hub <NUM> of device <NUM> to device <NUM>. In the example of <FIG>, the data is obtained from a record <NUM> of the outgoing-data database <NUM> and is sent after reference to either of data structures <NUM> or <NUM>.

In the version of the techniques <NUM> seen at block <NUM>, the first data may be sent to the first remote device hub based at least in part on the subscription in the outgoing-data database. In the example of <FIG>, the data structure <NUM> includes addresses of remote device hubs (e.g., a device hub (not shown) of device <NUM>) and a description and/or identification of the data to which each remote hub is subscribed. Accordingly, using the data structure <NUM> the data may be sent to a remote device hub, e.g., for relay by the device hub of the remote device to a container hub and/or process operating on the remote device.

At block <NUM>, an incoming-data database is maintained. The incoming-data database is configured to associate processes operating on the device with data to which the processes subscribe. In the example of <FIG>, processes <NUM>-<NUM> and <NUM>-<NUM> may have subscriptions to particular data. To assist the device hub <NUM> in properly forwarding the desired data to the appropriate process, the incoming-data database <NUM> is maintained. In an example of the maintenance, incoming data is added to incoming-data data records <NUM> of the database <NUM>, and when the data is no longer needed, it is removed/deleted.

At block <NUM>, second data is received from a second device hub associated with a second device. In the example of <FIG>, the data may be stored in a record of the incoming-data database <NUM>.

At block <NUM>, by reference to the incoming-data database, it is determined that the second data is data subscribed-to by a second process operating on the device. In the example of <FIG>, the device hub <NUM> (of <FIG> and <FIG>) may reference the data structure <NUM> to determine processes operating on the device and their respective subscriptions to data. The data structure would indicate that the second data was subscribed-to by the second process. Accordingly, at block <NUM>, the second data is sent to the second process.

<FIG> shows additional example techniques <NUM> by which the network-connected device-aspects of whose operation was described in <FIG>-are performed. In an example, data is generated, labeled and sent at the network-connected device. In a first example, the data is sent to remote devices that have not subscribed to the data, thereby saving the overhead of subscription management. In a second example, the data is sent only to remote devices that have subscribed to the data, thereby reducing the use of radio bandwidth. In the example of <FIG>, data may be sent from networked-device <NUM> to remote device <NUM> because device <NUM> sent device <NUM> a subscription, to thereby reduce the use of radio spectrum. Alternatively, data may be sent even if no subscription was sent, to save the overhead of subscription management. Accordingly, the techniques <NUM> provide additional examples of the techniques of block <NUM> of <FIG>, wherein the first data is sent to a first remote device hub associated with a first remote device and associated with an entry in the outgoing-data database.

At block <NUM>, the first data is tagged, labeled and/or identified with a globally unique identifier (GUID) prior to sending the first data. By tagging, labeling and/or identifying data, which may be stored in the outgoing-data database <NUM> of <FIG>, it is easier to send appropriate data to a remote device.

In the alternative of block <NUM>, using addresses from the outgoing-data database, the first data is sent to a first plurality of remote hubs having at least one process that has subscribed to the first data.

In the alternative of block <NUM>, using addresses from the outgoing-data database, the first data is sent to a second plurality of remote hubs having no process that has a subscription to the first data.

Accordingly, blocks <NUM> and <NUM> are representative of two data transmission strategies. In the strategy of block <NUM>, data is sent by a device to devices that have subscribed to that data (e.g., using data structure <NUM> of <FIG>). In the strategy of block <NUM>, data is sent to all networked devices, and used or discarded as appropriate (e.g., using data structure <NUM> of <FIG>).

<FIG> shows example techniques <NUM> by which data is received, identified as being of no use by any process associated with hub(s) of a device, and is deleted. Thus, the example techniques are consistent with block <NUM> of <FIG>, wherein data is sent to all networked devices-including those that do not have a use for the data-and is therefore deleted.

At block <NUM>, third data is received from a third remote hub associated with a third remote device. At block <NUM>, by referring to the incoming-data database, the third data is identified as data not subscribed-to by any process operating on the device. At block <NUM>, the third data is deleted.

<FIG> shows example techniques <NUM> that assist a hub of a device to efficiently send subscribed-to data to other hubs of other devices. The techniques describe example creation and/or maintenance of an outgoing-data database (e.g., outgoing-data database <NUM> of <FIG>. The techniques describe receiving subscriptions, identification of the subscribed-to data, and managing addresses of remote networked devices that have subscribed to particular data. Accordingly, the techniques <NUM> show an example by which blocks <NUM> and/or <NUM> of <FIG> may be performed. In example use of the outgoing-data database <NUM>, data may be sent to a remote networked device based at least in part on reference to the subscription, desired data, and recipient device address found in the outgoing-data database.

At block <NUM>, a subscription for data is received. In the example of <FIG>, the subscription may be received by the device hub <NUM> of the device <NUM>. The subscription may be received from a device hub on a remote device (e.g., the remote device <NUM>). The subscription may be related to a process operating on the device <NUM>. The process may operate on device <NUM> in a manner similar to processes <NUM>-<NUM> of device <NUM>. Alternatively, the process may be in a container of device <NUM> (similar to processes <NUM>-<NUM> of container <NUM> of device <NUM>).

At block <NUM>, the subscription and an address of the first remote device are added to the outgoing-data database, e.g., the outgoing-data database <NUM> of <FIG>. The subscription may indicate the type, kind, identification number and/or alphanumeric string, etc., that identifies the subscribed-to data. In the example of <FIG>, because the subscription and address are available in the outgoing-data database <NUM>, the device hub <NUM> of the device <NUM> is able to send the desired data to the desired location in a mono-cast or multicast manner (i.e., without broadcasting the data).

<FIG> shows example techniques <NUM> usable by a hub (or other structure) of a device to efficiently subscribe to data in the possession of other networked devices. The techniques describe example creation and/or maintenance of an incoming-data database to receive incoming-e.g., subscribed-to-data. Information from the incoming-data database (e.g., incoming-data database <NUM> of <FIG> and <FIG>) may also be used to relay incoming data to appropriate processes operating on the device.

At block <NUM>, a request to subscribe to data is sent to a device hub of a remote networked device. In the example of <FIG>, a networked device (e.g., device <NUM>) may send a request to subscribe to data to a hub of the networked device <NUM>.

At block <NUM>, an incoming-data database is maintained in a manner that associates processes operating on the device (and in examples, their addresses) with data to which the processes have subscribed. In the example of <FIG>, each incoming-data data record <NUM> of the incoming-data database <NUM> associates a process of the device <NUM> with data to which it has subscribed. Accordingly, when the data arrives at the device hub <NUM>, that hub will know (by referencing the database) to which process(es) to send each item of the data.

At block <NUM>, data is received from the device hub associated with the remote networked device. In an example, the data is received based at least in part on the request to subscribe and/or the subscription.

<FIG> shows example techniques <NUM> by which data is transmitted inter-device and intra-device, such as by using a two-hop technique, a relay technique involving a hub as a relay point, and techniques for moving data intra-device to virtual machines. Accordingly, the techniques <NUM> are an example method to perform blocks <NUM> and <NUM> of <FIG>. In the example of <FIG>, the device hub <NUM> sends data to, and receives data from, each process <NUM>-<NUM>. Additionally, the device hub <NUM> sends data to, and receives data from, container hub <NUM>. Similarly, container hub <NUM> sends data to, and receives data from, each process <NUM>-<NUM>. Accordingly, data moving from process <NUM> to process <NUM> passes through container hub <NUM> and device hub <NUM> using an intra-device and/or two-hop technique.

At block <NUM>, actions seen in blocks <NUM> and <NUM> of <FIG> are revisited. In a first action, second data is received from a device hub associated with a second device. In <FIG>, the "first data" was outgoing data sent from the networked device to a remote networked device (e.g., in the example of <FIG>, from device <NUM> to device <NUM>). In <FIG>, the "second data" was incoming data sent from a remote networked device to the networked device. In a second action, the second data is sent to the second process. Accordingly, the data discussed in <FIG> is incoming data from a remote networked device (e.g., device <NUM> of <FIG>) that must be relayed to an appropriate process on the receiving device (e.g., device <NUM> of <FIG>). Blocks <NUM>-<NUM> describe three example techniques by which data may be relayed.

At block <NUM>, data is transmitted between the first process and a second process operating on the device using a two-hop process. Referring to <FIG>, the relay location may the device hub <NUM>, or the container hub <NUM>. In a three-hop data transmission, both the device hub <NUM> and the container hub <NUM> could relay the data from a process in communication with the device hub to the container hub, which could relay the data to a process in the container.

At block <NUM>, data may be transmitted between the first process and a second process operating on the device using the hub as a relay point. In an example, a first process may control operation of a radio, and would receive the incoming data. In a two-hop process, the data moves from the first process to a device hub, and is then transferred to the second process.

At block <NUM>, data is sent to a container hub of a virtual machine operating on the device, wherein the container hub relays the data to a process operating within the virtual machine. In a further example, the data sent to the container hub could have been sent by a process operating within the container and/or virtual machine.

<FIG> shows example techniques <NUM> by which data is received at a device hub of a device. The device hub identifies the data as subscribed-to by a process operating within a container and/or virtual machine operating on the device. The data is then sent to the container hub within the container.

At block <NUM>, third data is received. At block <NUM>, by referring to the incoming-data database, the third data is identified as data subscribed to by a container hub operating on the device. At block <NUM>, the third data is sent to the container hub.

<FIG> shows example techniques <NUM> by which incoming and outgoing data is efficiently received and sent by a network-connected device, and showing example techniques for managing subscribed-to data and data that was not subscribed-to.

At block <NUM>, first data is received from a first process operating on the device. In the example of <FIG>, a process (e.g., one of processes <NUM>-<NUM>) is operating on the device <NUM>. The process may be gathering data from a data-generating device <NUM>. The process sends the data to the device hub <NUM> where it is received. The hub device <NUM> may store the data in the outgoing-data database <NUM>.

At block <NUM>, the first data is sent to a first remote device hub associated with a first remote device. In the example of <FIG>, the first data is obtained (e.g., from the outgoing-data database <NUM> and is sent to a device hub of a remote device (e.g., device <NUM>).

At block <NUM>, second data is received from a second remote device hub associated with a second remote device. In the example of <FIG>, incoming data may be saved in the incoming-data database <NUM>.

At block <NUM>, the second data is identified as data subscribed-to by a second process operating on the device. In the example of <FIG>, the device hub <NUM> may periodically or continuously check the incoming-data database <NUM> to identify data that may be needed, or subscribed-to, by a process operating on the device.

At block <NUM>, the second data is sent to the second process. In the example of <FIG>, the device hub <NUM>, having identified data as subscribed-to by a process (operating on device <NUM>), sends the data to the process. After confirmation of receipt, the data may be deleted from the incoming-data database <NUM>.

At block <NUM>, third data is received from a third remote device hub associated with a third remote device. In the example of <FIG>, incoming data may be saved in the incoming-data database <NUM>.

At block <NUM>, the third data is identified as data not subscribed to by any process operating on the device. In the example of <FIG>, the device hub <NUM> checks the incoming-data database <NUM> but fails to identify data that may be needed, or subscribed-to, by any process operating on the device.

Accordingly, at block <NUM>, the third data is deleted.

<FIG> shows example techniques <NUM> by which data transmission is based at least in part on reference to database(s) that may be maintained by hubs.

At block <NUM>, a subscription to data is received from a second process. In the example of <FIG>, a process (e.g., process <NUM>) subscribes to data by sending a subscription to the device hub <NUM> on the device <NUM>.

At block <NUM>, the subscription is recorded in an incoming-data database. In the example of <FIG>, the subscription may be added to data structure <NUM> of the incoming-data database <NUM>. That is, the data to which process <NUM> has subscribed may be coming from a different device (e.g., device <NUM>).

At block <NUM>, the second data is sent to the second process based at least in part on a reference to the incoming-data database. In the example of <FIG>, the device hub <NUM> consults the incoming-data database <NUM> and recognizes that the second data was subscribed to by the second process. The recognition may be based on a data identification number, a type of data, or another factor.

<FIG> shows example techniques <NUM> by which data subscriptions are managed. In an example, a process sends a subscription request to its device hub. If the process is within a container, the container hub relays the subscription request to the device hub. In anticipation of incoming data resulting from the subscription, the device hub saves the subscription request in the incoming-data database. The device hub then sends the subscription request to a remote device. At the remote device, the device hub puts the subscription request in the outgoing-data database of the remote device. Accordingly, the data needed by the process and the address of the device of the process are available to the device hub of the remote device, which will result in data transmissions to the process.

At block <NUM>, a subscription is received from the second process. In the example of <FIG>, the device hub <NUM> may receive a subscription (i.e., a subscription request) from a process (e.g., process <NUM> or <NUM>). Referring to <FIG>, the device hub <NUM> may store the subscription in the incoming-data database <NUM>, so that when the data arrives the hub may identify the data as subscribed-to, and by which process.

At block <NUM>, the subscription is sent to a device hub of a remote device. In the example of <FIG>, the subscription may be sent to a hub of the remote device <NUM>.

At block <NUM>, the subscription (or data related to, or obtained from, the subscription) is added to an outgoing-data database at the second device. In the example of <FIG>, the structure of device <NUM> may be similar to the structure of device <NUM>. Accordingly, the device hub of device <NUM> may store the subscription (or data related to, or obtained from, the subscription) in the outgoing-data database of that device.

Claim 1:
A method of operating a device (<NUM>) on a network (<NUM>), comprising:
maintaining (<NUM>) an outgoing-data database (<NUM>) comprising addresses of device hubs (<NUM>) on respective devices remote to the device;
wherein a device hub is configured to relay data between one or more processes operating on its respective associated device and/or one or more device hubs associated with other devices on the network (<NUM>);
receiving (<NUM>) first data from a first process (<NUM>) operating on the device;
sending (<NUM>) the first data to a first device hub associated with a first device (<NUM>) remote to the device and associated with an entry in the outgoing-data database (<NUM>);
maintaining (<NUM>) an incoming-data database (<NUM>) to associate processes operating on the device (<NUM>) with data to which the processes subscribe;
receiving (<NUM>) second data from a second device hub associated with a second device;
determining (<NUM>), by reference to the incoming-data database (<NUM>), that the second data is data subscribed-to by a second process (<NUM>) operating on the device (<NUM>); and
sending (<NUM>) the second data to the second process (<NUM>);
receiving (<NUM>) third data from a third device hub associated with a third device;
identifying (<NUM>), by reference to the incoming-data database (<NUM>), that the third data is not data subscribed-to by any process operating on the device (<NUM>); and
deleting (<NUM>) the third data.