Patent Grant
11711745
The number of devices connected to the Internet has grown significantly in recent years. Such devices may include not only computing devices such as laptops, smartphones and tablets, but may also include traditional stand-alone devices and everyday objects. Such networks of connected sensors and devices, also referred to as Internet of Things (IoT) networks, have made large amounts of data available for many consumer, commercial, and industrial applications.
In general, the present disclosure is directed to bi-directional communication in an adaptive route wireless network.
In one example, the disclosure is directed to a wireless sensor network system, comprising a gateway computing device, a plurality of cluster host computing devices, and a plurality of end computing devices, each end computing device including a sensor that detects event data, each end computing device further configured for wireless bi-directional communication with one of the plurality of cluster-host computing devices; the plurality of cluster host computing devices forming a route between each of the plurality of end devices and the gateway, each cluster host computing device storing a next downstream network address; wherein each of the plurality of cluster host computing devices forming part of the route from one of the plurality of end computing devices to the gateway further modifies a downstream network message received from a previous cluster host computing device, and further: appends a network address of the previous cluster host obtained from a source address field of a downstream network message to an appended addresses field of the downstream network message; sets a source address field of the downstream network message to a network address of the current cluster host computing device; and sets the destination address field of the downstream network message to the next downstream network address stored by the current cluster host computing device; and wherein the current cluster host computing device further wirelessly transmits the modified downstream network message to the next downstream network address contained in the destination field of the modified downstream network message.
The downstream network message may further include a message payload field including event data corresponding to an event detected one of the end computing device. The downstream network message may further include a node count field containing a node count corresponding to a number of nodes between the current cluster host computing device and an originating computing device of the downstream network message, and wherein the current cluster host computing device further increments the node count in the node count field of the downstream network message. The downstream network message may further include a message payload field including a factory address of the originating computing device. The wireless network comprises a cluster-tree network.
The system may further include a server computing device configured to receive downstream network messages from the gateway computing device; the server computing device further configured to update a portion of a route table corresponding to an originating end computing device, the portion of the route table including a factory address of the originating end computing device, appended network addresses contained in the appended addresses field of the modified downstream network message, and a node count contained in the node count field of the modified network message.
The server computing device may be further configured to generate an upstream network message to be transmitted to the originating computing device, the upstream network message including a payload field containing the factory address of the originating computing device, an appended addresses field containing the appended network addresses stored in the portion of the route table corresponding to the originating computing device, and a node count field containing the node count stored in the portion of the route table corresponding to the originating computing device.
In another example, the disclosure is directed to a method of wireless communication between a first computing device, a second computing device, and a third computing device in a wireless network, comprising storing, by the second computing device, a network address of a third computing device, the third computing device being a next downstream node along a route through the wireless network from the second computing device to a gateway computing device; wirelessly receiving, by the second computing device, a downstream network message from the first computing device, the downstream network message including a source address field containing a network address of the first computing device, a destination address field containing a network address of the second computing device, and an appended address field; modifying, by the second computing device, the downstream network message, comprising appending, by the second computing device, the network address of the first computing device to the appended addresses field of the downstream network message; setting, by the second computing device, the source address field of the downstream network message to the network address of the second computing device; and setting, by the second computing device, the destination address field of the downstream network message to the network address of the third computing device stored by the second computing device; and wirelessly transmitting, by the second computing device, the modified downstream network message to the network address of the third computing device as contained in the destination field of the modified network message.
The downstream network message may further include a node count field containing a node count corresponding to a number of nodes between the first computing device and an originating computing device of the downstream network message, and wherein modifying the downstream network message further comprises incrementing, by the second computing device, the node count in the node count field of the downstream network message. The downstream network message may further include a message payload field including event data corresponding to an event detected at the originating computing device. The downstream network message may further include a message payload field including a factory address of the originating computing device. The wireless network may include a cluster-tree network.
The method may further include receiving, by a server computing device and from the gateway computing device, the modified network message; updating, by the server computing device, a portion of a route table corresponding to the originating computing device, the portion of the route table including a factory address of the originating computing device, appended network addresses contained in the appended addresses field of the modified network message, and the node count contained in the node count field of the modified network message.
The method may further include generating, by the server computing device, an upstream network message to be transmitted to the originating computing device, the upstream network message including a payload field containing the factory address of the originating computing device, an appended addresses field containing the appended network addresses stored in the portion of the route table corresponding to the originating computing device, and a node count field containing the node count stored in the portion of the route table corresponding to the originating computing device.
The method may further include receiving, by the second computing device, the upstream network message; modifying, by the second computing device, the upstream network message, comprising setting, by the second computing device, the source address field of the downstream network message to the network address of the second computing device; and setting, by the second computing device, the destination address field of the upstream network message to a next hop network address contained in the appended addresses field of the upstream network message, the next hop network address corresponding to the network address of the first computing device; removing, by the second computing device, the next hop network address from the appended addresses field of the upstream network message; and wirelessly transmitting, by the second computing device, the modified upstream network message to the network address of the first computing device as contained in the destination address field of the modified upstream network message.
In another example, the disclosure is directed to a method comprising wirelessly receiving, by a server computing device and from a gateway computing device, a network message originating from one of a plurality of end computing devices, the network message including event data corresponding to an event detected at the originating end computing device, the network message further including a list of one or more appended network addresses corresponding to one or more cluster host computing devices forming a wireless communication route between the originating end computing device and the gateway computing device, the network messages further including a node count corresponding to the number of cluster host computing devices forming the wireless communication route between the originating end computing device and the gateway computing device; and maintaining, by the server computing device, and based on the received network message, a portion of a route table corresponding to the originating end computing device, the portion of the route table including the list of one or more appended network addresses and the node count.
The network message may further include a factory address of the originating end computing device, and the portion of the route table further includes the factory address of the originating end computing device.
The method may further include generating, by the server computing device, an upstream network message intended for a destination one of the plurality of end computing devices, the upstream network message including the list of one or more appended network addresses from the portion of the route table corresponding to the destination end computing device, and including the node count from the portion of the route table corresponding to the destination end computing device.
In another example, the disclosure is directed to a method comprising wirelessly receiving, by a current cluster host computing device and from a previous cluster host computing device, a network message originating from one of a plurality of end computing devices, the network message including event data corresponding to an event detected at the originating end computing device; and wirelessly transmitting, by the current cluster host computing device, the network message, the transmitted network message including the event data, a list of one or more appended network addresses corresponding to one or more previous cluster host computing devices forming a wireless communication route between the originating end computing device and the current cluster host computing device, and a node count corresponding to the number of cluster host computing devices forming the wireless communication route between the originating end computing device and the current cluster host computing device.
In another example, the disclosure is directed to a hand hygiene compliance network, comprising a plurality of end computing devices, each of the plurality of end computing devices associated with a different one of a plurality of hand hygiene product dispensers and configured to detect dispense events; and a server computing device configured to wireless receive, from a gateway computing device, a downstream network message originating from one of the plurality of end computing devices, the downstream network message including dispense event data corresponding to a detected dispense event, the downstream network message further including a list of one or more appended network addresses corresponding to one or more cluster host computing devices forming a wireless communication route between the originating end computing device and the gateway computing device, the downstream network message further including a node count corresponding to the number of cluster host computing devices forming the wireless communication route between the originating end computing device and the gateway computing device, the server computing device further configured to maintain based on the received downstream network message, a portion of a route table corresponding to the originating end computing device, the portion of the route table including the list of one or more appended network addresses and the node count; the server computing device further configured to analyze the dispense event data and to monitor hand hygiene compliance based on the analysis.
The details of one or more examples are set forth in the accompanying drawings and the description below. Other features and advantages will be apparent from the description and drawings, and from the claims.
The present disclosure describes a wireless network topology and bi-directional communication protocol with the ability to support multiple gateways, dynamically discover the best route between an end device and a gateway, dynamically discover a new route between an end device and a gateway if a link is broken, and/or support bi-directional communication between and end device and a gateway. Due to its ability to dynamically adapt to a changing environment, the network and network protocol in accordance with the present disclosure is referred herein to as an adaptive route wireless network (or simply, “network”).
Each computing device along a route to a gateway appends the previous node's network address to downstream messages as they are transmitted along the route from an originating computing device to the gateway. The list of appended network addresses thus records the route taken by the downstream network message through the adaptive route network. A server computing device maintains a route table including the list of appended network addresses received with each downstream message. To send unsolicited upstream messages to any computing device on the wireless network, the server generates an upstream network message that includes the appended network address(es) from the portion of the route table corresponding to the destination computing device. The upstream route to the destination computing device is thus contained in the list of appended network addresses within the network message.
This so-called adaptive route wireless network provides a flexible system that is designed to be easier for users and service technicians to use and maintain. The adaptive route wireless network is a stand-alone network that does not consume network traffic on an enterprise's wired or wireless network(s). The ability to support multiple gateways increases the number of end devices that can be supported as compared to networks that only permit one gateway per building, and thus the size of the customer, and the number of end devices, is not limited in that respect. The bi-directional communication protocol allows information to be transmitted from the end devices to a local or remote computing devices and/or data repository (on or off-site) for analysis, and also allows transmission of information to be transmitted down to the end device(s) from the server, or from local or remote computing devices, such as updates settings or firmware.
The adaptive route network does not require each device or node in the network to maintain large route tables in their own local memory that store routes from itself to every other device in the network, thus simplifying their design and lowering cost. The network also reduces or eliminates the network traffic required to keep such route tables up to date, as route addresses are sent within messages themselves, rather than requiring separate route maintenance messages to be sent throughout the network.
Although a single gateway 12 is shown in this example for simplicity of illustration, it shall be understood that network 10 may include one or more gateways 12, and that the invention is not limited in this respect. In addition, it shall be understood by those of skill in the art that each gateway 12 may include a different number of hubs and end devices, that any number of gateways 12, hubs 14 and end devices 20 may exist on network 10, and that the disclosure is not limited in this respect.
In addition, although network 10 is shown and described herein as a cluster-tree network, it shall also be understood that this is for purposes of illustration only, that the disclosure is not limited in this respect, and that the adaptive route bi-directional communication protocols described herein may also be applied to other network topologies known in the art. For example, the adaptive route network protocol may (by default) support a star network topology composed of a single gateway 12 and a single hub 14 if all end devices are within range of the single hub 14 (i.e., a single cluster). Other network topologies may also be used, and the disclosure is not limited in this respect.
In some applications, wireless network 10 may be subjected to a constantly changing environment of RF noise and multipath interference. Also, one or more of the end devices 20 may be mobile in the sense that they may be moved around from place to place within the environment. To accommodate such interference and physical changes to the network structure itself, each of the devices in network 10 (e.g., gateways, hubs, and end devices) is configured such that end devices may adaptively discover new and/or more efficient routes to a gateway when these movements occur. In addition, it is possible for a hub 14 to unexpectedly lose power or be physically removed. In this way, the routes between an end device 20 to hubs 14 and to gateways 12 that are set up at one moment in time may change, degrade, or completely disintegrate as devices are moved into, around or out of the network environment or experience technical problems. To prevent loss of data, the adaptive route wireless network protocol of the present disclosure may ask some or all devices (including gateways 12, hubs 14 and/or end devices 20) on the network to independently evaluate the quality of their links or routes on a regular basis. In these examples, when the quality of a link or route is below an acceptable threshold, there will be an attempt to establish a new link or route. Attempts will continue until a new link or route of acceptable quality has been established.
In the example of
In some examples, some or all of the gateways 12, hubs 14, and/or end devices 20 may have their 4-byte address programmed by the factory at the time of manufacture. In such examples, this 4-byte factory address is permanent and cannot be changed. In other examples, some or all of the gateways 12, hubs 14, and/or end devices 20 may have their 4-byte addresses programmed at a time when the end device is added to the network, and the addresses may be changed, added or removed as necessary.
The adaptive route network protocol of the present disclosure is a packet-based protocol. Each packet is a self-contained entity without reliance on earlier exchanges as there is no connection of fixed duration between devices. In some examples, all devices residing on an adaptive route wireless network may use an RF transceiver to communicate, such as a Texas Instruments CC1120 (or compatible) narrow band RF transceiver, or any other wireless transceiver.
The Data Field will contain a network message placed there by the transmitting device. Only the message (Data Field) will be passed on to the gateway and server. The other parts of the packet are only for wireless network communication and will be removed.
In the examples shown and described herein, all data is described as binary (no ASCII characters, and the message and all multi-byte structures will be in big-endian format (most significant byte (MSB) first).
The Header includes a 1-byte Message Type value from 0 to 255 that defines the structure and meaning of the payload data, i.e., the type of message being transmitted. Examples of the various message types are described herein below. The Header further includes a Destination Address, which is the address of the device the message is being transmitted to. For example, an end device sending a message to a hub (cluster host) will use the recipient hub's 4-byte factory address. A network hub (route node) sending a message to another network hub (route node) will use the recipient hub's 1-byte network address. The higher order address bytes including the device type will be ooh. In this example, the 1-byte network address is assigned to each hub by the server when a hub joins the network. It is used instead of the 4-byte factory address to reduce the number of bytes (by 75%) per message required to map the route a message takes through the network.
The Source Address is the address of the device the message is being transmitted from. For example, an end device sending a message to a hub (cluster host) will use the transmitting end device's 4-byte factory address. A hub (route node) sending a message to another hub (route node) will use the transmitting hub's 1-byte network address as the least significant byte (LSB). The higher order address bytes including the device type will be ooh.
Nonce is a 1-byte modulo 256 value from 0 to 255 that serves as a message ID. It will start at zero (0) and increment by one (1) with each subsequent message. The receive signal strength indicator (RSSI) is a 1-byte signed value from −128 to 127. It represents the signal strength (measured in dBm) of the last message received by the device transmitting the current message. Payload Length refers to the number of bytes in the Payload section of the message. It will be a value from 0 to 100. 100-bytes is the maximum size for the payload section in this example.
The Payload portion of a network message shown in
The Route Data portion of a network message may be thought of as containing a map of the route (via network devices) a downstream message has taken from an end device to the gateway. The route data therefore also defines the route, in reverse, an upstream message must take from the gateway to a device. Node Count is a 1-byte value from 0 to 10 that is the count of the number of network hubs (route nodes) a message must travel through to reach its destination. For end devices, the node count will always be zero (0) as the end devices are the starting point for a downstream message. Node Addresses includes an ordered list of 1-byte network addresses belonging to the network hubs (nodes) a downstream message must travel through to reach its destination at the respective gateway device. Up to ten (10) network addresses may be listed. Further description of the messaging protocol and generation of the Route Data is described in more detail herein below.
The Checksum portion of a network message includes a 2-byte cyclic redundancy check (CRC-16) used to verify the integrity of the message.
Referring again to
In some examples, end devices 20 are battery-powered. To conserve the finite power available, end device wireless transceivers may be used only when necessary. Conversely, cluster hosts (hubs 14) may be powered externally and their wireless transceivers receiver may be continuously enabled to listen for incoming messages. Therefore, in the examples described herein, end devices 20 initiate all downstream communications with a cluster host hub 14.
Each message from an end device 20 will be addressed to the current cluster host hub factory address. In some examples, each message is transmitted from an end device as events occur or are detected; that is, each message includes the data/information concerning a single event detected or sensed by the end device and is transmitted at the time of the event. In addition, or alternatively, the end device 20 may store one or more messages (such as in a buffer), and the stored messages may be transmitted periodically, after detection of a predetermined number of events, upon request of another computing device (such as the current cluster host hub) and/or upon a request entered by a user from a remote or local computing device. The current cluster host hub 14 will reply to each message received by transmitting an ACK if received successfully or a negative-acknowledgment message (NAK) if the received message is corrupt or incomplete.
As discussed above with respect to
The example cluster host discovery process (40) of
In accordance with example cluster host discovery process (40), to discover a cluster host, an end computing device broadcasts a cluster host discovery message (CHDM) (45). This message may be received by any cluster host within wireless range of the end device.
In some examples, since more than one (1) cluster host may receive the CHDM broadcast at the same time, each cluster host may implement an anti-collision broadcast reply algorithm by randomly selecting a time slot in which to transmit its reply. In the example of
The end device will respond with an acknowledged message (ACK) to the first valid CHDM reply it receives. As per the example cluster host discovery process (40) of
While an end device is executing the cluster host discovery process (40), each CHDM broadcast will have the same message ID (8-bit nonce). When an ACK is received by the cluster host in response to its CHDM reply, the cluster host will store the broadcasting end device's address and message ID in a buffer. The buffer will contain a predetermined number of the most recent unique addresses and message IDs for end devices that have recently transmitted a CHDM. Therefore, when an end device rebroadcasts a CHDM in an effort to locate every cluster host within wireless range, any cluster host that has already replied and received an ACK will ignore any subsequent broadcasts from the same end device.
In
As shown in
In
The CHDM reply from each cluster host will include the host's address, number of hops to the gateway and link quality information including both the link between the end device and host as well as the host's route to the Gateway. Only cluster hosts with a route to a gateway will reply to a CHDM.
Once all replies have been received and acknowledged, amend computing device will evaluate the information returned by each cluster host and select the host which provides the best overall link quality. As shown in
End device X will now address all messages to the selected cluster host B thus forming a link to cluster host B as shown in
In some example adaptive route networks in accordance with the present disclosure, end devices, such as end devices 20 as shown in
Each end device includes one or more sensors for detecting one or more events. The type of event(s) will depend upon the type of application in which the adaptive route network is being used. For example, in a hand hygiene compliance network, one type of end computing device may include a hand hygiene product dispenser, which detects a “dispense event” each time it senses actuation of the hand hygiene product dispenser. Another type of end computing device in a hand hygiene compliance network may include a bed beacon which generates a patient zone around a patient bed and detects an “entry event” each time a healthcare worker wearing an electronic identification badge enters and/or leaves the patient zone. The sensors and devices may include any type of device and/or sensor that could be used in an Internet-of-Things type network. It shall therefore be understood that the sensors for detecting one or more events may encompass a wide range of different type of sensors and devices, and that the disclosure is not limited in this respect.
In the examples described herein, each message from an end device is addressed to the current cluster host's (4-byte) factory address and transmitted as events occur. The cluster host replies to each message received by transmitting an ACK if the message is received successfully or a negative-acknowledgment message (NAK) if the received message is corrupt or incomplete. If a NAK or no reply at all is received by the end device, the end device will retry transmitting the pending message. If all retry attempts have failed to yield a successful message delivery, the end device will assume the current cluster host is unavailable. The end device will then enter the cluster host discovery process (40) and remain there until a cluster host is discovered. All new events that occur, while the end device is searching for a cluster to join, will be stored in its buffer.
There will be times when a cluster host will receive a message from an end device but that end device will not receive an ACK reply from the host due to RF noise or network congestion. The end device will then retransmit its message. This may result in duplicate messages being received by the host. Rather than rely on the host and its limited resources (RAM, ROM, μC etc.) to detect and eliminate duplicate messages, each message is transmitted through the network along the route to a local or offsite server computing device. The server computing device(s) have virtually unlimited resources (at least as compared to the network devices) and is better suited to eliminate duplicate messages.
In another example, the cluster host computing device keeps the source address and time/date stamp of the last 10 messages in a circular queue. If the message is a duplicate, the cluster host computing device sends an ACK, but does not write it to the outgoing message buffer. This may help to reduce network traffic by reducing transmission of duplicate messages.
Cluster maintenance is required to maintain reliable communications between an end device and a cluster host. Each end device is responsible for maintaining its own link with a cluster host. If this link cannot be maintained, the end device must discover a new cluster to join. Factors such as dynamic RF noise levels and end device mobility may result in a need for an end device to discover a new cluster host. For example, in some applications, end devices may be moved around an environment as needed to suit the needs of the application. In a healthcare environment, for example, hospital beds may be moved from one location to another, and thus a bed beacon associated with a particular hospital bed may need to discover a new cluster host if the bed is moved to a new location.
The adaptive route network and protocol as described herein supports mobility of the end devices within the network. Each end device executes the cluster hub discovery process at periodic intervals (e.g., every 30 minutes or other appropriate time interval) to evaluate its link with the current cluster host or identify a better cluster host link if one is available. If a better link is identified, the end device will join that cluster and all messages will then be addressed directly to the new cluster host. Otherwise, it will remain in its current cluster. If an end device discovers that its current cluster host is no longer available, it will execute the cluster hub discovery process until a new cluster host is found.
In
In
Cluster host C that is within range of the relocated end device X replies to the CHDM and the end device X replies back with an ACK message. End device X will then exit the CHDA and transmit a join cluster message, the cluster host C will reply with an ACK message, and the relocated end device X has become a member of a new cluster with cluster host C as shown in
Each time an end device joins a cluster, its join cluster message (JCM) is sent to the server computing device, such as server computing device(s) 30 of
For example, a portion of a route table stored by a server computing device corresponding to the end computing device having the factory address of 1E000905h in the example of
The route table maintained by the server includes similar entries for each computing device in the adaptive route network, including gateway computing devices, cluster host computing devices, and end computing devices. In this way, the server computing device maintains a route to each computing device in the network by which it may transmit downstream messages using the bi-directional communication protocol described herein. In addition, because the routes are updated each time a downstream message is received from an end computing device and/or cluster host computing device, the routes are maintained and updated at the server without having to transmit separate route maintenance messages throughout the network. This greatly reduces network traffic and simplifies the design of the cluster host and end computing devices, while also providing a simplified and highly accurate way to both maintain the route table and transmit upstream network messages from the server to the cluster host and/or end computing devices.
As shown in
The end computing device broadcasts an CHDM (45). The CHDM includes the end device's 255 4-byte factory address and message ID. This message may be received by any cluster host within wireless range of the end device. Cluster hosts that are not currently route nodes (i.e., are not joined to a route to a gateway) will ignore the CHDM. If more than one cluster host is within range, all of the cluster hosts within range will receive the CHDM broadcast. Each cluster host that receives the CHDM (the so-called discovered cluster hosts) will respond to the CHDM with an CHDM reply. The CHDM reply will include the discovered cluster host's 4-byte factory address. The CHDM reply will also include the discovered cluster host's number of hops to the respective gateway for that route (0 if the route node is a gateway), and link quality information including both the link between the end computing device and the discovered cluster host as well as quality information concerning the cluster host's route to the gateway.
If one or more CHDM replies are received (46), the end computing device responds with an ACK message to the first valid CHDM reply it receives (47). The end computing device stores the cluster host information corresponding to the discovered cluster host address received in the CHDM reply (48) and increment the number of route nodes found (49). If the number of cluster hosts found/discovered satisfies a threshold (50) (three in this example), the process (40) is complete (57). If the number of cluster hosts found/discovered does not satisfy the threshold (50) (less than three in this example) the end computing device may further broadcast additional CHDMs, at predefined intervals (56) (1 second intervals in this example), after each CHDM reply is received to determine if any additional cluster hosts are within range. Replies from up to three (3) different cluster hosts will be accepted in this example.
If no replies are received (46) to an CHDM message, the end computing device will determine if the number of cluster hosts found is greater than zero (that is, at least one cluster host within range has been found) (51). If so, the end device will determine whether the broadcast count satisfies a threshold (55) (whether the broadcast count equals three in this example). If the broadcast count satisfies the threshold, the cluster host discovery process is complete (57). This means that the end computing device has found at least one cluster host within range and has tried at least three times to discover additional route nodes.
If the number of cluster hosts found is not greater than zero (that is, no cluster hosts have been found) (51), and the broadcast count does not satisfy the threshold (52) (broadcast count is less than three in this example) the end computing device will delay for a predefined period of time (54) (one second in this example) and then rebroadcast another CHDM with the same message ID (44, 45) in an attempt to discover at least one cluster host.
If the number of cluster hosts found is not greater than zero (that is, no cluster hosts have been found) (51), and the broadcast count satisfies a threshold (52) (broadcast count equals three in this example, meaning that the end computing device has broadcast the same CHDM at least three times with no response) the end computing device will delay for a random period (53) (e.g., between 1 and 128 seconds in this example) and then repeat the cluster host discovery process (40) with a new message ID (41). End computing device repeatedly executes process (40) indefinitely until at least one cluster host has been discovered.
Once all replies have been received and acknowledged, the end computing device exits the example cluster host discovery process (40), evaluates the information returned by each cluster host, and selects the cluster host which provides the best overall link quality as shown in
An end computing device seeking to join a cluster in an adaptive route network evaluates the discovered cluster host information returned by each responding cluster host (61). The end computing device selects the cluster host which provides the best overall link quality (62). End computing device transmits a Join Cluster Message (JCM) to the selected cluster host (63). In
The selected cluster host (cluster host B in the example of
After the end computing device receives the JCM reply from gateway, it stores the cluster host network address (66), and the process is complete (68). The end computing device is now a member of the cluster belonging to the cluster host network address and has become a member of the adaptive route network. As shown in the example of
For purposes of the present description, a “route” in the adaptive route network is composed of “nodes” which link together to form a data path or route from an end computing device to a gateway computing device. The nodes may include hubs/cluster hosts and gateways. For example, in
The example route node discovery process (70) is a self-contained set of operations that discovers and returns information for up to a predetermined number of route nodes (three (3) in the examples described herein) that are connected to a route. The discovered route nodes may belong to the same or different routes. The discovered route node information will include the route node's address, a number of hops to the gateway (0 if the route node is a gateway), and link quality information. The link quality information may include both the link between the hub 255 and route node as well as the node's route to the gateway 251. The discovered route node information will be evaluated by the hub (255 in the examples of
Until hub 255 has linked to an existing route node and then itself becomes a route node, it will not function as a cluster host. Therefore, it will ignore all messages from any end computing devices. The same is true if an existing link to a route node is broken. Any end devices that were a member of a cluster whose cluster host can no longer provide a route to a gateway (i.e., an unconnected hub) will be ignored (i.e., the unconnected hub will not transmit an ACK in response to any attempts by end devices to send a message, and the end devices will therefore not receive an ACK from the cluster host within an acceptable time limit or after a defined number of retry attempts) thus forcing the end devices to discover a new cluster host if one is available.
To discover a route to a gateway, a hub, such as hub 255 shown in
Each route node that receives the RNDM will transmit an RNDM reply that includes the hub's 4-byte factory address. Since more than one (1) route node can receive the RNDM broadcast at the same time, in some examples each route node that receives the RNDM will implement an anti-collision broadcast reply algorithm by randomly selecting a time slot in which to transmit its reply. In the example shown in
Hub 255 will broadcast up to a predetermined number of RNDMs at predetermined intervals (e.g., three (3) RNDMs in 1 second intervals, or any other appropriate number or interval), after each RNDM reply is received to determine if any additional route nodes are available. Replies from up to a predetermined number (three (3) in this example) different route nodes will be accepted. If there is no reply after three (3) consecutive RNDM broadcast attempts, hub 255 will assume there are no more available route nodes within its wireless range.
While hub 255 is executing the RNDA process (e.g.,
In
In
The RNDM reply (RNDMR) from each route node 001 and 002 to hub 255 will include the route node's number of hops to the respective gateway for that route (0 if the route node is a gateway), and link quality information including both the link between the hub and node as well as the node's route to the gateway. As discussed above, only hubs with a route to a gateway will reply to a RNDM. In this example, route node 001 has one (1) hop to gateway 251 and route node 002 has two (2) hops to gateway 251.
Once all replies have been received and acknowledged, hub 255 will exit the route node discovery algorithm (60). Hub 255 then evaluates the discovered route information returned by each responding route node and select the route node which provides the best overall link quality (see, e.g.,
As shown in
The selected route node (001 in this example) will then pass the JRM to gateway 251 via the route to the gateway previously determined during its own route node discovery process. In this example, the route to gateway 251 from route node 001 includes the single hop from route node 001 to gateway 251. Once gateway 251 receives the JRM, it will request that the server computing device assign hub 255 a unique 1-byte network address (unique to that gateway). As shown in
After hub 255 receives the JRM reply from gateway 251, it will update its 1-byte network address and become a member of the route. As shown in
As shown in
The hub computing device broadcasts an RNDM (75). The RNDM includes the hub's 255 4-byte factory address and message ID. This message may be received by any route node within wireless range of the new hub. Hubs that are not currently route nodes (i.e., do not have a route to a gateway) will ignore the RNDM. If more than one route node is within range, all of the route nodes within range will receive the RNDM broadcast. Each route node that receives the RNDM (the so-called discovered route nodes) will respond to the RNDM with an RNDM reply. The RNDM reply will include the discovered route node's 4-byte factory address. The RNDM reply will also include the discovered route node's number of hops to the respective gateway for that route (0 if the route node is a gateway), and link quality information including both the link between the new hub computing device and the discovered route node as well as quality information concerning the route node's route to the gateway.
If one or more RNDM replies are received (76), the new hub computing device responds with an ACK message to the first valid RNDM reply it receives (77). The new hub computing device will store the route node information corresponding to the discovered route node address received in the RNDM reply (78) and increment the number of route nodes found (79). If the number of route nodes found/discovered satisfies a threshold (80) (greater than three in this example), the process (70) is complete (81). If the number of route nodes found/discovered does not satisfy the threshold (80) (less than three in this example) the new hub computing device may further broadcast additional RNDMs, at predefined intervals (87) (1 second intervals in this example), after each RNDM reply is received to determine if any additional route nodes are available. Replies from up to three (3) different route nodes will be accepted in this example.
If no replies are received (76) to an RNDM message, the new hub computing device will determine if the number of nodes found is greater than zero (that is, at least one node has been found) (82). If so, the hub will determine whether the broadcast count satisfies a threshold (83) (whether the broadcast count equals three in this example). If the broadcast count satisfies the threshold, the route node discovery process is complete (88). This means that the new hub computing device has found at least one route node and has tried at least three times to discover additional route nodes.
If the number of nodes found is not greater than zero (that is, no nodes have been found) (82), and the broadcast count does not satisfy the threshold (broadcast count is less than three in this example) the hub computing device will delay for a predefined period of time (86) (one second in this example) and then rebroadcast another RNDM with the same message ID (74, 75) in an attempt to discover at least one route node.
If the number of nodes found is not greater than zero (that is, no nodes have been found) (82), and the broadcast count satisfies a threshold (broadcast count equals three in this example, meaning that the hub computing device has broadcast the same RNDM at least three times with no response) the hub computing device will delay for a random period (85) (e.g., between 1 and 128 seconds) and then repeat the route node discovery process (70) with a new message ID (71). This process (70) repeats indefinitely until at least one route node has been discovered.
Once all replies have been received and acknowledged, the hub computing devices exits the example route node discovery process (70) and then evaluates the information returned by each route node and selects the route node which provides the best overall link quality as shown in
A hub computing device seeking to join an adaptive route network evaluates the discovered route information returned by each responding route node (102). The hub computing device selects the route node which provides the best overall link quality (104). Hub computing device transmits a Join Route Message (JRM) to the selected route node (106). In
The selected route node (001 in this example) passes the JRM to the gateway (gateway 251 in the example of
After the new hub computing device receives the JRM reply from the gateway, it updates its 1-byte network address (110), stores the next hop (downstream) address (112) and the process is complete (114). The new hub computing device is now a member of the adaptive route network and may respond to any join cluster messages from end computing devices and become a cluster host as described herein with respect to
Bi-Directional Communication
In some existing connected device networks, sending a message “downstream” from an end device to a gateway is straightforward. All routes in a connected device network converge on the gateway and each route node need only know the address of the next node along the route. However, sending a message “upstream” from the server computing device or from a gateway computing device to a specific route node or to an end computing device is more difficult. Many existing network protocols solve this problem by having each device in the network keep a table that stores a route from itself to every other device on the network. However, this method requires a large amount of memory and constant maintenance to keep the routes current. This method also vastly increases the amount of network traffic as route maintenance messages must be continually sent through the network in order to update the route tables at each node.
In the adaptive route network and protocol in accordance with the present disclosure, each computing device along a route appends the previous hop's network address to downstream messages as they are passed along the route from an originating computing device (either an end computing device or a cluster host computing device) to the gateway for ultimate transmission to the server. Once a downstream network message has traveled from an originating computing device to the gateway, the appended network addresses record the route taken by the downstream message as it travels from an originating computing device through the adaptive route network to the gateway computing device. The server computing device maintains a route table which includes the appended route node addresses received with each downstream message. Since memory is plentiful on the server, the server can maintain a table of routes to each cluster host and end computing device based on the received downstream messages. This will allow the server to generate unsolicited messages that can be sent upstream from the server to any computing device (gateway, cluster host, or end device) on the network. If the gateway or server needs to send a reply back to either a cluster host computing device or to an end computing device, or transmit updates to settings or firmware to a cluster host or an end computing device, it may do so by including the appended device address(es) from the previously received message into any upstream message going back onto the network.
One advantage of the adaptive route network and protocol in accordance with the present disclosure, in which the previous route node network addresses are appended to a downstream message at each hop along a route from an end device to a gateway, is that each device or node in the network does not need to maintain large route tables in their own local memory that store routes from itself to every other device in the network, thus reducing memory requirements, simplifying their design and lowering cost. Another advantage is that it reduces or eliminates the network traffic required to keep route tables at each node up to date, as route addresses are sent within event messages themselves, rather than requiring separate route maintenance messages to be continually sent throughout the network.
In accordance with the present disclosure, to reduce the number of bytes in a message packet, each device within the adaptive route network, including cluster host (hub) computing devices and end computing devices, is assigned a 1-byte network address by the server computing device at the time the route node joins the adaptive route network. The 1-byte network address is unique to each gateway; thus, each gateway may have up to 255 devices included within its portion of the overall adaptive route network.
In the examples described herein, all route nodes are assigned a unique 4-byte address at the factory (see
An example 1-byte route node network address space is shown in Table 1.
The server maintains a table of network addresses like the example shown in Table 2. Four (4) bytes will be allocated in memory for each network address. The first three (3) bytes will contain a device's 4-byte factory address minus the device type byte. In this example, as only hubs may become route nodes, the most significant byte (MSB) of the factory address, which is the device type ID, will always be the same (0×01 in this example). Therefore, there is no need to store the MSB in this example. The fourth byte will be used to determine if the hub assigned to the corresponding network address is active.
When a join route message (JRM) transmitted by a hub/cluster host is received by the gateway, the server assigns a network address and the hub's 4-byte factory address and assigned network address is recorded in the network address table. Once the assigned network address is received from the server, the gateway then transmits a JRM reply back to the hub which contains the assigned network address. When the hub receives the JRM reply, it becomes a route node and the newly assigned network address will be stored in its memory. The route node will then answer to this address or its 4-byte factory address until a different address has been assigned by the gateway.
Address reassignment will only occur if a route node has a network address of 255 (default) or a route node with a duplicate network address was introduced into the network for that gateway. In the latter case, when a JRM is transmitted to the gateway, the server will look up the received network address in that gateway's network address table. If the route node's unique 4-byte factory address matches the factory address recorded in the table, i.e., the device was reintroduced into the network, the server will return the same network address to the route node in the JRM reply and the route node will keep its current network address. Conversely, if the route node's 4-byte factory address does not match the factory address recorded in the table, i.e., a second device was introduced into the network with a duplicate address, the server will assign the next network address available in the table, record the route node's factory address and transmit a JRM reply with the newly assigned network address. When the route node receives the JRM reply, it will update its network address to the newly assigned address.
In some examples, to verify that a route node is active, each active route node (e.g., cluster host and/or end computing device) may regularly transmit heartbeat messages at periodic (e.g., one (1) hour) intervals, if no event messages have been sent during that time. If an event message is sent, the heartbeat timer may be restarted to reduce network traffic with unnecessary heartbeat messages. Once every hour, the server will increment the No Heartbeat Count for each assigned network address in the network address table. Each time the server receives a heartbeat message (or event message) from a route node, it will clear the No Heartbeat Count for that route node's corresponding network address in the network address table. The No Heartbeat Count belonging to the assigned address of an inactive route node will increment to a maximum count (e.g., a count of 24 after 24 hours) of not receiving any heartbeat (or event) messages. When this occurs, the server will assume the route node is no longer active and will free the network address for assignment to a new route node by clearing the hub Factory Address and setting the No Heartbeat Count to 255 (FFh) in the network address table. An example of this is shown for example network address 006 of Table 2, where address 006 is now available for assignment.
In accordance with the present disclosure, all downstream messages in an adaptive route network, including join cluster messages, join route messages, and event messages include a record of the route taken to the gateway. This record is constructed by appending the network address (1-byte in the examples described herein) of the previous hop (source address) into the network message itself. Each node along the route appends the previous hop's network address onto the message before forwarding the message to the next hop in the route. In this way, when the message is received at the gateway, the message will include the network addresses for each node along the route from the end device to the gateway.
Each time a network message is received from an end computing device or a cluster host computing device, server computing device compares the route stored in the appended address field of the network message to the portion of the route table corresponding to that end device. If the route is different, that means that the route from that computing device to a gateway has changed since the last time the server received a message from the end device. The server then updates the route table corresponding to that computing device to reflect the new route.
All downstream messages traveling along a route from a device (e.g., end device or cluster host) to the gateway (not just messages requiring a reply) will receive an appended route node address at each hop. The messages passed from the gateway to the server will retain the appended addresses. This will allow the server to see the route from the originating device and maintain a route table that is refreshed with each message received. When a hub joins a route and the server assigns it a 1-byte network address, the gateway will send a message to the server with both the hub's newly assigned network address and its 4-byte factory address. This allows the server to maintain a table to cross-reference between a route node's network and factory address when reporting status as only the factory address would be relevant to a user.
If the server needs to send an unsolicited message, such as updates to settings or firmware, to a route node or an end device, it will use its route table to construct the route within the message using the appended address structure. Only route node network addresses will be used for routing purposes in this example. The final destination end device's 4-byte factory address will be contained in the message payload and will be used by the device to verify that it is the intended recipient. This will apply to all final destination devices, both route nodes and end devices.
For example, a portion of the route table stored by a server computing device corresponding to end device 1E000905h in the example of
When the message of
In some examples, a route node cannot transmit an unsolicited message to an end computing device until that end device first transmits a message to the route node which is also the end device's cluster host. This is because, in some examples in order to save battery power, an end computing device's wireless receiver is only briefly enabled while waiting to receive a reply to a previously transmitted message. Therefore, the cluster host must hold the message until it receives a message from the intended recipient in order to help ensure that the end computing device can receive the message.
For example, when a message of any type (heartbeat, CHDM or end device event) is eventually received by the cluster host from the intended recipient of a pending end device message, the cluster host may reply with an ACK. The cluster host may set a status bit within the ACK message to indicate to the end device that there is a pending message waiting for delivery. Upon receiving the ACK, the end device may respond by transmitting a Deliver Pending Message Message (DPMM). The cluster host may then transmit the pending message to the intended recipient. Once received, the end device may reply with an ACK.
In
Upon receipt of the message, end device (device 1E000905h in this example) may send an ACK back to the cluster host (cluster host 004 in this example). If an ACK is received by the cluster host, it may transmit a Pending Message Status Message (PMSM) back to the gateway (gateway 251 in this example) which will then send it on to the server. The PMSM will contain the message recipient's 4-byte factory address, the original message's nonce (message ID) and a status byte set to indicate that the message was received by the intended recipient (end device 1E000905h in this example). The PMSM provides feedback to the server indicating that the message was or was not delivered successfully to the intended recipient.
In some examples, the cluster host will only hold one (1) downstream message for each of its cluster member end devices at a time. In such examples, the server/gateway will buffer multiple messages and only send a new one once receiving confirmation that the previous message has been delivered. This may help to reduce memory requirements of cluster host/hub devices, simplifying the design and reducing costs. This communication protocol allows the adaptive route network of the present disclosure to efficiently deliver high volumes of messages downstream from the end devices to the gateway.
End computing device 400 includes one or more processor(s) 402, a wireless communication unit 406, one or more event sensor(s) 404, and one or more storage device(s) 408. Storage device(s) 408 includes an adaptive route protocol module 410, a bi-directional communication module 422, an event detection module 12, a cluster host address 414, a factory address 418, and data storage/message buffer 416.
One or more wireless communication units 406 of end computing device 400 are configured to permit bi-directional wireless communication with one or more cluster host computing devices. Examples of communication units 406 include any device or technology capable of sending and receiving wireless communications. Such devices may include optical transceivers, radio frequency (RF) transceivers, infrared (IR) transceivers, satellite communication, cellular communication, etc.
One or more processors 402 may implement functionality and/or execute instructions associated with end computing device 400. Examples of processors 402 include application processors, microcontrollers, and any other hardware configured to function as a processor, a processing unit, controller, or a processing device.
For example, processors 402 may execute adaptive route protocol module 410 to execute a cluster host discovery process such as that shown and described herein with respect to
Adaptive route protocol module 410, event detection module 412, and bi-directional communication module 422, as well as other functional modules not shown in
In some examples, storage device(s) 408 may include a temporary memory, meaning that a primary purpose of such as portion of storage device(s) 408 is not long-term storage. Storage device(s) 408 on end computing device 400 may be configured for short-term storage of information as volatile memory and therefore not retain stored contents if powered off. Examples of volatile memories include random access memories (RAM), dynamic random-access memories (DRAM), static random-access memories (SRAM), and other forms of volatile memories known in the art.
Storage device(s) 408, in some examples, may also include one or more computer-readable storage media. Storage device(s) 408 in some examples include one or more non-transitory computer-readable storage mediums. Storage device(s) 408 may be configured to store larger amounts of information than typically stored by volatile memory. Storage device(s) 408 may further be configured for long-term storage of information as non-volatile memory space and retain information after power on/off cycles. Examples of non-volatile memories include magnetic hard discs, optical discs, floppy discs, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories. Storage device(s) 408 may store program instructions and/or information (e.g., data) associated modules 410, 412 and/or 422. Storage device(s) may include a memory configured to store data or other information associated with modules 410, 412, and 422, such as data storage/message buffer 416.
Storage device(s) 408 further include storage of a current cluster host network address 414 and factory address 418 assigned to end computing device 400 at the time of manufacture.
Event sensor(s) 404 may include any type of sensor(s), and the type of sensor(s) may depend at least in part upon the particular application in which the adaptive route network is to be deployed, and the type of event(s) which are to be detected. For example, sensor(s) 404 may include one or more sensors applicable in smart home, healthcare, artificial intelligence, transportation, government, automotive, commercial and/or industrial applications, among others. Event detection module 412 may include functionality that when executed by processor(s) 402, cause end computing device 400 to sense or detect one or more events, and/or perform any corresponding analysis or communication regarding such detected events, depending upon the requirements of the application in which the end devices are being implemented.
Transmission of certain types of messages by end computing device 400 are event triggered. For example, upon detection of an event by one of sensor(s) 404, processor(s) 402 may execute event detection module 412 to analyze the detected event data received from sensors 404, generate any corresponding data associated with the event (such as date and time stamps, etc.), and generate and transmit an event message including the event data and any corresponding data (all of which may be referred to herein simply as, “event data”). End computing devices 400 may include a message buffer 416 to buffer messages in the event they cannot be transmitted at the time of the event, or in those applications where events are transmitted on a batch basis, etc. In some examples, event detection module 412 may further include instructions that allow end computing device 400 to communicate with and/or analyze data received from other computing devices, such as electronic user identification badges, or with any other end devices computing devices (whether of the same type or a different type).
In a hand hygiene compliance network, for example, the system may include a plurality of compliance badges for monitoring of an individual user's hand hygiene practices. In some examples, each of a plurality of compliance badges is uniquely assigned to one of a plurality of users whose hand hygiene practices are to be monitored. The hand hygiene compliance system may further include dispenser module end computing devices, each of which detects dispense events at a hand hygiene product dispenser and communicates with compliance badges to associate each dispense event with a particular user. The system may further include zone module end computing devices, each of which generates a “zone” around an area to be monitored, and detects entry and/or exit events of compliance badges to/from the zone, such as a zone around a patient bed or other area to be monitored. To analyze compliance with hand hygiene procedures, the system includes one or more sets of compliance rules that define compliant and non-compliant hand hygiene practices. Upon sensing of a zone entry/exit event and/or dispense event, the sensing end device obtains badge identification information from the compliance badge associated with the zone entry/exit event and/or dispense event. The dispense event data and/or the zone entry/exit event data is transmitted from the end device(s) to the server, which analyzes the data in accordance with the compliance rules. In this way, individual compliance/non-compliance with hand hygiene procedures may be monitored and analyzed.
In accordance with the bi-directional communication protocols described herein, the event message will include the factory address 418 of end computing device 400. In some examples, the event message is transmitted to the current cluster host address 414 at the time of the occurrence of the event. Sending the event messages at the time of the event permits the server computing device to analyze the data and/or make decisions regarding the event in real time or near real time. This also helps to reduce memory requirements of each end computing device 400, as less memory is required to buffer or store large amounts of event data, thus increasing simplicity of design, reducing memory requirements, and reducing costs.
Cluster host computing device 370 includes one or more processor(s) 372, a wireless communication unit 374, and one or more storage device(s) 376. Storage device(s) 376 includes an adaptive route protocol module 380, a bi-directional communication module 382, a next hop (downstream) address 384, a factory address 390, a network address 392, and data storage/message buffer 388. Cluster host computing device 370 does not need to store the next hop upstream address, as upstream communication is directed from the next hop addresses stored in the upstream message itself as described herein within respect to the bi-directional communication protocol. Cluster host computing device 370 further does not maintain or store a list of its cluster members, as the server maintains a route table that associates each end device factory address with a particular cluster host computing device within the network. All of this serves to reduce memory requirements and simplify the design of the cluster host computing devices 370.
One or more wireless communication units 374 of cluster host computing device 370 are configured to provide bi-directional wireless communication with other cluster host computing devices, a gateway, and/or one or more end computing devices associated with its cluster. Examples of communication units 374 include any device or technology capable of sending and receiving wireless communications. Such devices may include optical transceivers, radio frequency (RF) transceivers, infrared (IR) transceivers, and devices for satellite communication, cellular communication, etc.
One or more processors 372 may implement functionality and/or execute instructions associated with cluster hub computing device 400. Examples of processors 372 include application processors, microcontrollers, and any other hardware configured to function as a processor, a processing unit, controller, or a processing device.
For example, processors 372 may execute adaptive route protocol module 380 to execute a join route discovery process such as that shown and described herein with respect to
In some examples, storage device(s) 376 may include a temporary memory, meaning that a primary purpose of such as portion of storage device(s) 376 is not long-term storage. Storage device(s) 376 may be configured for short-term storage of information as volatile memory and therefore not retain stored contents if powered off. Examples of volatile memories include random access memories (RAM), dynamic random-access memories (DRAM), static random-access memories (SRAM), and other forms of volatile memories known in the art.
Storage device(s) 376, in some examples, may also include one or more computer-readable storage media. Storage device(s) 376 in some examples include one or more non-transitory computer-readable storage mediums. Storage device(s) 376 may be configured to store larger amounts of information than typically stored by volatile memory. Storage device(s) 376 may further be configured for long-term storage of information as non-volatile memory space and retain information after power on/off cycles. Examples of non-volatile memories include magnetic hard discs, optical discs, floppy discs, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories. Storage device(s) 376 may store program instructions and/or information (e.g., data) associated with modules 380 and 382. Storage device(s) 276 may include a memory configured to store data, buffer upstream and/or downstream messages, or store any other information associated with modules 380, 382, such as data/message buffer 388.
Storage device(s) 376 further include storage of a factory address 390 assigned to cluster host computing device 370 at the time of manufacture, and a network address 392 assigned to it by the server upon joining a route in an adaptive route network. Storage device(s) 376 further stores a next hop address (downstream) 384 that is used during execution of bi-directional communication module 376 to generate and/or transmit downstream messages.
Data/message buffer 388 may further include a message buffer that stores one or more upstream messages in the event that cluster host computing device 370 is not able to immediately transmit upstream messages intended for an end device belonging to its cluster or intended for another cluster host computing device upstream from the current cluster host computing device. Cluster host computing device 370 determines whether an upstream message is intended for an associated end device by checking the Node Count byte in the network message. If the Node Count byte is equal to zero, that means the current cluster host computing device 370 is the last hop in the route before the end device. Cluster host computing device 370 then checks the payload of the upstream message for the factory address of the end device. As discussed herein, to save battery life in the end devices, a cluster host computing device cannot transmit an unsolicited message to an end computing device until that end device first transmits a message to the cluster host. This is because, in some examples in order to save battery power, an end computing device's wireless receiver is only briefly enabled while waiting to receive a reply to a previously transmitted message. Therefore, the cluster host must hold the unsolicited upstream message in the message buffer 388 until it receives a message from the intended recipient in order to help ensure that the end computing device can receive the message. The cluster host responds with an ACK having a status bit set indicating that there is a pending message waiting for delivery. Upon receiving the ACK, the end computing device may respond by transmitting a Deliver Pending Message Message (DPMM), and cluster host may then transmit the pending message to the end computing device 1E000905.
Cluster host computing device 370 generates and transmits downstream messages (that is, messages initiated by an end computing device for transmission along a route to an associated gateway) by execution of bi-directional communication module 382. For example, upon receipt of an event message from an end computing device via wireless communication unit 374, processor(s) 372 may execute bi-directional communication module to generate and transmit the received messages to the next hop along the associated route. In accordance with the bi-directional communication protocols described herein, processor(s) 372 will append its own network address 392 to the appended address portion of the received message and transmit the new message to the next hop address 382 as stored in its memory 276. Processor(s) 372 will also increment the node count portion of the message by one (1) to indicate the number of hops from cluster host computing device 370 to the next downstream cluster host (or gateway if there are no intervening cluster hosts). This process repeated by each cluster host computing device along the route until the message is received by the gateway computing device associated with the route.
Gateway computing device 350 includes one or more processor(s) 352, one or more wireless communication unit(s) 356, one or more wired/serial communication unit(s) 355, and one or more storage device(s) 358. Storage device(s) 358 includes an adaptive route protocol module 360, a bi-directional communication module 362, a factory address 366, a network address 367, and data storage/message buffer 368. In some examples, the downstream portion of the message buffer 368 may be quite large, such as 1M bytes, for example. Since the gateway computing device communicates with the server computing device(s) over a serial connection, much larger messages may be from the gateway to the server than those that are transmitted on the adaptive route network.
Gateway computing device 350 is configured for wireless communication with one or more devices in an adaptive route network 340. Gateway computing device 350 is further configured to wirelessly communicate with one or more server computing device(s) 300 and/or one or more local/remote computing device(s) 332 via other network(s) 330. Gateway computing device 350 is configured for wired and/or wireless communication with any of one or more server computing device(s) 300 and/or one or more local/remote computing device(s) 332 via network(s) 330. Network(s) 330 may include, for example, one or more of a dial-up connection, a local area network (LAN), a wide area network (WAN), the internet, a wireless or Wi-Fi network, a cell phone network, satellite communication, or other means of electronic communication. The communication within network(s) 330 may be wired or wireless. Remote/local computing device(s) 332 may include, for example, one or more of a server computing device, a desktop computing device, a laptop computing device, a tablet computing device, a mobile computing device (such as a smart phone) a personal digital assistant, a pager, or any other type of computing device.
Wireless communication units 356 of gateway computing device 350 may wirelessly communicate with cluster host computing devices that form a part of an associated route in adaptive route network 340. Wireless communication units 356 of gateway computing device 350 may also wirelessly communicate one or more of server computing device 300 and/or remote/local computing device(s) 332 via networks 330. Examples of wireless communication unit(s) 356 include any device or technology capable of sending and receiving wired or wireless communications. Such wireless devices may include optical transceivers, radio frequency (RF) transceivers, infrared (IR) transceivers, and devices for satellite communication, or cellular communication. One or more wired/serial communication unit(s)355 of gateway computing device 350 may communicate with server computing device(s) 300 and/or local/remote computing device(s) 332 using, for example RS-485, Ethernet, or other communication interfaces or connections to the network 330.
Server computing device(s) 300 are configured to maintain route information defining routes to/from the gateways to the end computing devices in any associated adaptive route network(s), generate and transmit updates to settings or firmware to the gateways, cluster hosts, and/or end computing devices in the adaptive route networks, analyze the event data received from sensors in the adaptive route network(s), generate reports concerning the event data received from the sensors in the adaptive route network(s), etc.
One or more processors 352 may implement functionality and/or execute instructions associated with gateway computing device 350. Examples of processors 352 include application processors, microcontrollers, and any other hardware configured to function as a processor, a processing unit, controller, or a processing device.
For example, processors 352 may execute adaptive route protocol module 360 to execute the gateway side of a cluster host discovery process such as that shown and described herein with respect to
In some examples, storage device(s) 358 may include a temporary memory, meaning that a primary purpose of such as portion of storage device(s) 358 is not long-term storage. Storage device(s) 358 may be configured for short-term storage of information as volatile memory and therefore not retain stored contents if powered off. Examples of volatile memories include random access memories (RAM), dynamic random-access memories (DRAM), static random-access memories (SRAM), and other forms of volatile memories known in the art.
Storage device(s) 358, in some examples, may also include one or more computer-readable storage media. Storage device(s) 358 in some examples include one or more non-transitory computer-readable storage mediums. Storage device(s) 358 may be configured to store larger amounts of information than typically stored by volatile memory. Storage device(s) 358 may further be configured for long-term storage of information as non-volatile memory space and retain information after power on/off cycles. Examples of non-volatile memories include magnetic hard discs, optical discs, floppy discs, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories. Storage device(s) 358 may store program instructions and/or information (e.g., data) associated with modules 360 and 362. Storage device(s) 358 may include a memory configured to store data or other information associated with modules 360 and 362, such as data 374.
Storage device(s) 358 further include storage for the gateway network address itself 367 and a factory address 366 assigned to gateway computing device 350 at the time of manufacture.
Gateway computing device 350 receives downstream messages from the adaptive route network (that is, messages originating from an end computing device or a cluster host computing device) and transmits them to server 300 by execution of bi-directional communication module 362. For example, upon receipt of an event message from a cluster hub computing device 370 via wireless communication unit 356, processor(s) 352 may execute bi-directional communication module 362 to transmit the received event messages to the server 300 via network(s) 330. As another example, if server 300 or gateway 350 needs to send an unsolicited upstream message to one or more devices on adaptive route network 340 (such as updates to settings or firmware), processor(s) 352 may execute bi-directional communication module 362 to transmit the unsolicited upstream message(s) to the appropriate destination device (e.g., cluster host or end computing device).
Server computing device 300 includes one or more processor(s) 302, one or more communication unit(s) 306, one or more user interface(s) 304, and one or more storage device(s) 308. Storage device(s) 308 includes an adaptive route protocol module 310, a bi-directional communication module 312, route tables 314, factory/network address table 326, enterprise data 316, event messages 318, data 320, event analysis module 322 and reporting module/dashboard 324.
Server computing device 300 is configured to communicate with one or more gateway computing devices in an adaptive route network 340. Server computing device 300 is further configured to communicate with one or more other remote or local computing device(s) 300 via network(s) 330. Network(s) 330 may include, for example, one or more of a dial-up connection, a local area network (LAN), a wide area network (WAN), the Internet, a wireless or Wi-Fi network, a cell phone network, satellite communication, or other means of electronic communication. The communication within network(s) 330 may be wired or wireless. To that end, communication unit(s) 306 may include one or more wired and/or wireless communication unit(s). Remote/local computing device(s) 332 may include, for example, one or more of a server computing device, a desktop computing device, a laptop computing device, a tablet computing device, a mobile computing device (such as a smart phone) a personal digital assistant, a pager, or any other type of computing device.
Server computing device(s) 300 is configured to maintain route information (e.g., route tables 314) defining routes to/from the gateways to each of the end computing devices in one or more associated adaptive route network(s) 340. Server computing device(s) 300 also maintain factory/network address table 326 that stores the factory address and the associated assigned network address for each cluster host and end computing device in an adaptive route network. Server computing device(s) 300 may also generate and transmit upstream messages including updates to settings or firmware to the gateways, cluster hosts, and/or end computing devices in the adaptive route networks 340.
Server computing device(s) 300 may further, upon execution of the event analysis module 322 by processor(s) 302, analyze event data received from end computing devices in the adaptive route network(s) 340, and generate reports concerning the event data received from the sensors in the adaptive route network(s), etc.
One or more processors 302 may implement functionality and/or execute instructions associated with server computing device 300. Examples of processors 302 include application processors, microcontrollers, and any other hardware configured to function as a processor, a processing unit, controller, or a processing device.
For example, processors 302 may execute adaptive route protocol module 310 to execute the server side of a cluster host discovery process or a join route discovery process, and to store the relevant factory and network addresses of any end device joining a cluster or cluster hub joining a route in route tables 314. Processors 302 may further execute bi-directional communication protocol module 362 to receive downstream event messages (e.g., messages originating at an end device and transmitted to a gateway and then to the server) and/or to generate and transmit upstream reply messages or unsolicited upstream network maintenance messages from the server to an end device.
In some examples, storage device(s) 308 may include a temporary memory, meaning that a primary purpose of such as portion of storage device(s) 308 is not long-term storage. Storage device(s) 308 may be configured for short-term storage of information as volatile memory and therefore not retain stored contents if powered off. Examples of volatile memories include random access memories (RAM), dynamic random-access memories (DRAM), static random-access memories (SRAM), and other forms of volatile memories known in the art.
Storage device(s) 308, in some examples, may also include one or more computer-readable storage media. Storage device(s) 308 in some examples include one or more non-transitory computer-readable storage mediums. Storage device(s) 308 may be configured to store larger amounts of information than typically stored by volatile memory. Storage device(s) 308 may further be configured for long-term storage of information as non-volatile memory space and retain information after power on/off cycles. Examples of non-volatile memories include magnetic hard discs, optical discs, floppy discs, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories. Storage device(s) 308 may store program instructions and/or information (e.g., data) associated with modules 310, 312, 322, and/or 324. Storage device(s) 308 may include a memory configured to store data or other information associated with modules 310, 312, 322, and/or 324, such as data 320.
Enterprise data 316 may include data that uniquely identifies or is associated with the respective facility or enterprise with which the adaptive route network(s) 340 are associated. As such, enterprise data 316 may include, for example, enterprise identification information, employee information, management information, accounting information, business information, pricing information, information concerning those persons or entities authorized to access the reports generated by server computing device(s) 300, location information, and any other enterprise-specific information. In addition, enterprise data 316 may further include data corresponding to more than one unique enterprise, in the event that server computing device(s) 300 provides data analysis and reporting services to one or more enterprises implementing the adaptive route network(s) 340.
Event analysis module 322 includes instructions that, when executed by processor(s) 302, cause processor(s) 302 to analyze event data received from end computing device(s). For example, if the adaptive route network 340 is used in a hand hygiene compliance system, event analysis module 322 may cause processor(s) to monitor and analyze hand hygiene compliance at a hospital or other healthcare facility. In such an example, reporting module 324 may include instructions that, when executed by processor(s) 302, cause processors to generate one or more reports concerning hand hygiene compliance at a hospital or other healthcare facility. Reporting module/dashboard 324 may further generate and cause to be presented on any one or more of local/remote computing device(s) 332 a user interface or dashboard that allows a user to enter commands, generate and view reports, perform event analysis, and otherwise interact with the data obtained from or transmitted to the computing devices on the adaptive route network, the enterprise data, information or data entered by a user, and/or any other data or information associated with the adaptive route network or the environment in which it is implemented.
For example, server computer 300 may analyze the hand hygiene event data to monitor hand hygiene compliance by individual healthcare worker, type of healthcare worker (e.g., nurses, doctors, environmental services (EVS), etc.), individual departments, type of department, individual hospital, type of hospital, across multiple hospitals, over one or more specified timeframes, or by various other selected parameters. Server computer 300 may generate a variety of reports and transmit those report(s) to one or more remote or local computing device(s) 332 to provide users local to each hospital or remote users with both qualitative and quantitative data regarding hand hygiene compliance at their hospital, to compare data over time to determine whether improvement has occurred, and/or to benchmark hand hygiene compliance at multiple hospitals or other healthcare facilities. Relevant reports may be generated for any application or environment in which the adaptive route network is implemented, and it shall be understood that the disclosure is not limited in this respect.
A cluster host computing device will be a first node in a route to the gateway if the downstream message is received from an end computing device (504). If the message is received from an end device (504), cluster host computing device generates a new network message, and in doing so sets the Source Address field in the network message to its own network address; sets the Destination address field in the network message to its next hop address (see, e.g., Next Hop Address 384 in
If the message is received from another cluster host computing device (514), cluster host computing device sets the Source address field in the network message to its own network address (SELF ADDR); sets the Destination Address field in the network message to its next hop address (see, e.g., Next Hop Address 384 in
The cluster host then transmits the network message to the address indicated in the Destination field of the newly generated network message. Each successive cluster host along the route executes the same process (502, 514-522) (see, e.g., Hop 3 and Hop 4,
In the event that the server needs to send updates to settings or firmware, or other unsolicited message to any of the computing devices (including gateways, cluster hosts, and end devices) in an adaptive route network, the server generates the adaptive route network message (602), such as that shown as Hop 1 in
If the node count does not equal zero (624) the current cluster host computing device generates a new network message for transmission to the next node along the route (628), and in doing so, sets the Source Address to its own network address (SELF ADDR); sets the Destination address to the Appended Address Node byte corresponding to the current Node Count specified in the received network message (ADDRN+1); deletes/removes the Appended Address Node byte corresponding to the current Node Count from the Appended Address list of the received network message; and decrements the Node Count in the Node Count field; (see, e.g., Hops, 2, 3, and 4 in
The adaptive route wireless network topology and bi-directional communication protocol in accordance with the present disclosure provides a network having the ability to support multiple gateways, dynamically discover the best route between an end device and a gateway and to dynamically adapt to changing environments, dynamically discover a new route between an end device and a gateway if a link is broken, and/or support bi-directional communication between and end device and a gateway. The adaptive route wireless network therefore provides a flexible system that is designed to be easier for users and service technicians to use and maintain. The adaptive route wireless network is a stand-alone network that does not consume network traffic on an enterprise's wired or wireless network(s). The ability to support multiple gateways increases the number of end devices that can be supported as compared to networks that only permit one gateway per building, and thus the size of the customer, and the number of end devices, is therefore not limited in that respect. The bi-directional communication protocol allows information to be transmitted from the end devices to a local or remote computing devices and/or a server/data repository (on or off-site) for analysis, and also allows information to be easily transmitted from the server, or from other local or remote computing devices, to the end computing devices with a very small amount of overhead, so that unsolicited updates to settings or firmware may be easily and efficiently transmitted from the server computing device throughout the network.
The bi-directional communication protocol of the present disclosure enables simplified, low-overhead bi-directional network communication without requiring each device or node in the network to maintain large route tables in their own local memory that store routes from itself to every other device in the network, thus simplifying their design and lowering cost. The bi-directional communication protocol of the present disclosure also eliminates the network traffic required to keep such route tables up to date, as route addresses are sent within messages themselves using a relatively small number of bytes, rather than requiring separate route maintenance messages to be continually sent throughout the network.
In this example, in order to monitor hand hygiene compliance of a plurality of healthcare workers associate with the healthcare facility, each healthcare worker is uniquely assigned to one of a plurality of compliance badges 654A-654N. For simplicity of illustration, these are shown with respect to hospital 652A. It shall be understood, however, that compliance badges need not necessarily be used with implementation of an adaptive route network, but rather that compliance badges may be used in conjunction with an adaptive route network where monitoring of individuals is desired, such as the example shown in
Each of the plurality of manual dispensers is associated with a different one of a plurality of manual dispenser end computing devices 656A-656N configured to detect a dispense event each time the respective manual dispenser is actuated. Similarly, each of the plurality of touch free dispensers is associated with a different one of a plurality of touch free dispenser end computing devices 658A-658N and is configured to detect a dispense event each time the respective touch free dispenser is actuated. In addition, each of a plurality of bed zone end computing device(s) 660A-660N is configured to generate a zone around an area to be monitored, such as a patient bed zone, and to detect entry events into the zone when it detects a compliance badge entering the patient bed zone, and to detect exit events out of the zone when it detects a compliance badge leaving the patient bed zone. Each of end computing devices 656A-656N, 658A-658N, and 660A-660N may be implemented as the end computing device 400 as shown in
It shall be understood that other end computing devices associated with other devices, apparatus, and/or areas to be monitored may also be included, and that the disclosure is not limited in this respect. For example, end computing devices may also be associated with an area to be monitored, such as to detect presence of a compliance badge or healthcare worker in a patient room, treatment area, bathroom, or other area to be monitored). End computing devices may also be associated with any of sinks, toilets, or other device, apparatus, or area to be monitored for monitoring of hand hygiene compliance.
Each compliance badge 654A-654N is configured for short-range wireless communication with any of end computing device(s) 656A-656N, 658A-658N, and 660A-660N. Upon detection of a dispense event, for example, a manual dispenser end computing device 656A-656N may generate and transmit a short-range wireless interrogation signal, which induces any compliance badge 654A-654N within range of the transmission to transmit badge data, such as badge id, healthcare worker id, etc., upon receipt of the interrogation signal. The short-range wireless communication may include, for example short-range radio (RF) (e.g., Bluetooth, ZigBee, or ultra-wide band (UWB)) communication, infrared (IR) communication, or near field (NFC) communication techniques.
The end computing device(s) 656A-656N, 658A-658N, and 660A-660N are further configured to form part of an adaptive route wireless network 670 and communicate using the bi-directional communication protocol in accordance with the present disclosure. Upon receipt of the badge data from a compliance badge, end computing device 656A-656N associates the badge data with the dispense event, and transmits the badge data along with the other dispense event data, in an adaptive route network message as described herein.
To that end, end computing device(s) 656A-656N, 658A-658N, and 660A-660N are configured for wireless transmission of dispense event data and/or entry/event data via the adaptive route network 670. Each of end computing devices 656A-656N, 658A-658N, and 660A-660N is therefore configured to join a cluster with, and to transmit to and receive data from, one of cluster host computing devices 662A-662N. Each of cluster host computing devices 662A-662N is further in turn configured to join a route to a gateway 664A-664N with one or more of the other cluster host computing device 662A-662N as described herein (or none if there is only one cluster host along the route). Cluster host computing devices 662A-662N may be implemented as, for example, cluster host computing device 370 as shown in
The dispense event data may include, among other things, a time and date stamp for the dispense event, a healthcare worker id or badge number received from a compliance badge associated with the dispense event, and a dispenser id. The dispense event data may also include status information corresponding to the dispense event, including a battery level for the dispenser or for the associated end computing device, a bottle presence indicator, a dispense event count, a number of dispenses remaining, a product empty indicator, or any other information relevant to the dispense event or to the status of the dispenser.
The zone entry/exit event data may include, among other things, a time and date stamp for the entry/exit event, a healthcare worker id or badge number received from a compliance badge associated with the entry/exit event, and a bed zone beacon id. The entry/exit event data may also include status information corresponding to the entry/exit event, including a battery level for the bed zone beacon or for the associated end computing device, an entry event count, an exit event count, or any other information relevant to the entry/exit event or to the status of the bed zone beacon or end computing device.
To monitor hand hygiene compliance, dispense event data from the plurality of dispenser end computing devices 656A-656N, 658A-658N, and/or entry/exit event data from the plurality of bed zone end computing device(s) 660A-660N, is wirelessly transmitted along a route through the adaptive route network in accordance with the bi-directional communication protocol of the present disclosure to one or more server computing device(s) 682 for data analysis and reporting. Server computing device may include, for example, server computing device 300 as shown in
Server computing device 682 includes an analysis application that, when executed by processors of server computing device 682, analyzes the hand hygiene data (e.g., dispense event data and entry/exit event data) in accordance with one or more compliance rules so as to monitor hand hygiene compliance of healthcare workers within the healthcare facility. Server computing device 682 further includes a reporting application that, when executed by processors of server computing device 682, generates reports regarding hand hygiene compliance. For example, server computing devices 682 may analyze the hand hygiene data to monitor hand hygiene compliance by individual healthcare worker, type of healthcare worker (e.g., nurses, doctors, environmental services (EVS), housekeeping personnel, maintenance personnel, etc.), department, type of department, individual hospital, type of hospital, across multiple hospitals, or by various other selected parameters. Server computing devices 682 may generate and transmit a variety of reports automatically or on demand to one or more local computing device(s) 668, one or more remote user computing device(s) 684, with both qualitative and quantitative data regarding hand hygiene compliance at their hospital, to compare data over time to determine whether improvement has occurred, and/or to benchmark hand hygiene compliance at one hospitals, at multiple hospitals, or to view and compare hand hygiene compliance over time. Analysis and/or reporting applications may also be stored locally on hospital computing devices 668 so that analysis and reporting of hand hygiene data may be done locally if desired.
In some example adaptive route networks in accordance with the present disclosure, the system may include a plurality of badges for monitoring user's behavior and/or interaction with other devices in the network. In a hand hygiene compliance network, for example, each of a plurality of compliance badges may be uniquely assigned to one of a plurality of users whose hand hygiene practices are to be monitored. The hand hygiene compliance system may further include dispenser module end computing devices, each of which detects dispense events at a hand hygiene product dispenser and communicates with the compliance badges to associate each dispense event with a particular user. The system may further include zone module end computing devices, each of which generates a “zone” around an area to be monitored, and detects entry and/or exit events of compliance badges to/from the zone, such as a zone around a patient bed or other area to be monitored.
To analyze compliance with hand hygiene procedures, the adaptive route network may include one or more sets of compliance rules that define compliant and non-compliant hand hygiene practices. Each set of compliance rules corresponds to a different type of user. In a hand hygiene network for use in a healthcare facility, for example, the user types may include physicians, nurses, physical therapists, environmental service staff, administrative personnel, etc. The compliance rules corresponding to each user type may include zone entry/exit event and dispense event timings designed with the anticipated workflow of the user type taken into account. Each set of compliance rules may include one or more configurable items that may be programmed or adjusted to accommodate the workflow of a corresponding user type. For example, the configurable items may include one or more audible indicator settings, one or more visible indicator settings, one or more timers or grace periods including times between patient zone entry/exit events, times between patient zone entry/exit events and dispense events, times after leaving a patient zone, and any other configurable item that may be used to evaluate compliance with hand hygiene procedures.
Upon sensing of a zone entry/exit event and/or dispense event, the sensing end device obtains badge identification information from the compliance badge associated with the zone entry/exit event and/or dispense event. The dispense event data and/or the zone entry/exit event data (including a time/date stamp associated with the event, the badge id, device id, etc.) is transmitted from the end device(s) to the server via the adaptive route network, which analyzes the data in accordance with the compliance rules. In this way, individual compliance/non-compliance with hand hygiene procedures may be monitored and analyzed. Each compliance badge may also be programmed to analyze dispense event and/or zone entry/exit data in accordance with the compliance rules to determine compliance/non-compliance with the hand hygiene procedures.
In some circumstances, it may be desirable to update, customize, or otherwise change the one or more sets of compliance rules or other badge settings in an adaptive route network. To that end, the adaptive route network includes configurable compliance badges having one or more sets of compliance rules that may be configured based on user type and/or the needs of the site.
The server computing device maintains a current set of compliance rules. Each time the set of compliance rules is updated or changed, the server increments a “configuration id” number corresponding to the current set of compliance rules. In order to distribute the updated set of compliance rules throughout the adaptive route network, the server transmits the current set of compliance rules and associated configuration id to the gateway computing device(s), which is local to the site.
To distribute the current set of compliance rules from a gateway computing device to all the hub/cluster host computing devices in an adaptive route network, the heartbeat messages transmitted by the route nodes (e.g., hub/cluster host computing device) in an adaptive route network are used to monitor the sets of compliance rules stored by each device. As mentioned above, in some examples, to verify that a route node is active (that is, that a route node is a hub with current network membership), each active route node (e.g., hub/cluster host computing device) transmits heartbeat messages at periodic (e.g., one (1) hour) intervals. Each heartbeat message includes the hub computing device's configuration id number. Each time the gateway receives a heartbeat message from a route node, the gateway compares the hub computing device's configuration id number with the current configuration id number. If the hub computing device's configuration id number is less than the current configuration id number, the gateway transmits a badge configuration message (BCM) to the hub computing device, and also transmits the current set of compliance rules and the current configuration id number to the device. In response to receipt of the BCM, the hub computing device updates the set of compliance rules and the configuration id number stored on the hub computing device. In this way, a current set of compliance rules may be distributed to all of the hubs in an adaptive route network using a relatively small amount of network traffic. As the heartbeat message is sent only once per hour, and the configuration id number takes up only a small number of bytes in the heartbeat message, the status of each device's set of compliance rules may be determined using a relatively small amount of network traffic, and the full set of compliance rules need only be sent if it is determined that a particular device's configuration id is less than the configuration id corresponding to the current set of compliance rules. In addition, the hubs may be updated relatively quickly as their configurations are checked with every heartbeat message.
Similarly, a dispense event message and/or heartbeat message transmitted by each end computing device (such as a dispenser) also includes the configuration id stored by the end computing device's stored configuration id. An end computing device generates a heartbeat message if no events have occurred within the heartbeat timeout period (e.g., 1 hour). If an event occurs before the heartbeat timeout has expired, the end computing device will reset the heartbeat timeout to 1 hour. Each time a hub/cluster host computing device receives a heartbeat message or dispense event message from an end computing device, the hub computing device compares its configuration id number with the configuration id number received from the end computing device. If the end computing device's configuration id number is less than the hub's configuration id number, the hub transmits a badge configuration message (BCM) to the end computing device, and also transmits the set of compliance rules and the configuration id number stored by the hub to the end computing device. In response to receipt of the BCM, the end computing device updates the set of compliance rules and the configuration id number stored on the end computing device. In this way, similar to updating the hubs in an adaptive route network, an updated set of compliance rules may be distributed to all of the end computing devices in an adaptive route network using a relatively small amount of network traffic. Because the configuration id number takes up only a small number of bytes in an event message or a heartbeat message, the status of each end computing device's set of compliance rules may be determined using a relatively small amount of network traffic, and the full set of compliance rules need only be sent if it is determined that a particular end device's configuration id is less than the configuration id stored by the hub/cluster host computing device. An end computing device will be checked at least as often as a heartbeat message is sent, and sometimes more frequently if a dispense event occurs.
To update the compliance badges in the network with the current set of compliance rules, each time an end computing device detects a dispense event or zone entry/exit event, the device establishes communication with the compliance badge associated with the event, and the compliance badge transmits a dispense event message, including its configuration id number and badge identification number to the end computing device. For example, if a dispenser detects a dispense event, the dispenser establishes communication with the compliance badge associated with the dispense event, and the compliance badge transmits dispense event message, including its badge id number and its configuration id number to the dispenser. The dispenser compares the configuration id number received from the compliance badge with the configuration id number stored by the dispenser. If the badge configuration id number is less than the configuration id number stored by the dispenser, the dispenser transmits a badge configuration message (BCM) back to the compliance badge associated with the dispense event. In response to receipt of the BCM, the badge updates the set of compliance rules and the configuration id number stored on the badge. In this way, the set of compliance rules stored by each compliance badge in the network is checked against the current set of compliance rules each time a dispense event associated with the badge is detected, and the set of compliance rules stored by the compliance badge is updated if necessary.
As with updating the hubs and the end computing devices, an updated set of compliance rules may be distributed to all of the compliance badges in an adaptive route network using a relatively small amount of network traffic. Because the configuration id number takes up only a small number of bytes in an event message, the status of each compliance badge's set of compliance rules may be determined using a relatively small amount of network traffic, and the full set of compliance rules need only be sent if it is determined that a particular compliance badge's configuration id is less than the configuration id stored by the end computing device.
The time required for updating a compliance badge is determined by how often the compliance badge is used to complete a dispense event.
Compliance badge 700 includes one or more processor(s) 704, a wireless communication unit 706, one or more indicator(s) 710, one or more batteries 724, and one or more storage device(s) 708. Storage device(s) 708 includes a compliance module 712, compliance rules 714, a configuration id 716, a badge id 718, a user type 720, and a data storage/message buffer 722.
One or more wireless communication units 706 permit short-range wireless communication with end computing devices, such as end computing device(s) 702 in an adaptive route network. The end computing device(s) 702 may include, for example, any of dispenser end devices and/or bed beacon end devices in a hand hygiene compliance network, or any other type of end computing device. Upon detection of a dispense event, for example, a dispenser end computing device 702 may generate and transmit a short-range wireless interrogation signal, which induces any compliance badge 700 within range of the transmission to transmit badge data, such as badge id, healthcare worker id, configuration id number, etc., in response to receipt of the interrogation signal. The short-range wireless communication may include, for example short-range radio (RF) (e.g., Bluetooth, ZigBee, or ultra-wide band (UWB)) communication, infrared (IR) communication, or near field (NFC) communication techniques.
One or more processors 704 may implement functionality and/or execute instructions associated with compliance badge 700. Examples of processors 704 include application processors, microcontrollers, and any other hardware configured to function as a processor, a processing unit, controller, or a processing device. Processors 704 may execute compliance module 712 to communicate with one or more end computing device(s), detect dispense and/or exit/entry events, and/or perform any corresponding analysis or communication regarding such detected events. For example, processors 704 may retrieve and execute instructions stored by storage components 708 that cause processors 704 to perform or execute the operations stored in compliance module 712. The instructions, when executed by processors 704, may cause compliance badge 700 to generate and/or store information within storage components 708, such as data storage/message buffer 722.
In some examples, compliance rules 714 includes one or more sets of compliance rules, each corresponding to a different defined user type. In a healthcare facility, for example, the user types may include a physician user type, a nurse user type, a physical therapist user type, an environmental services user type, a dietary stuff user type, and any other defined user type. Each compliance is uniquely associated with a different user, and the user type 720 corresponding to that user is stored. To analyze hand hygiene behaviors, compliance badge 700 uses the set of compliance rules 714 corresponding to the user type 720.
Transmission of certain types of messages by compliance badge 700 may be event triggered. For example, upon detection of an event by one of end computing devices 702, processor(s) 704 may execute compliance module 712 to generate and transmit an event message including badge id 718, user type 720, and configuration id 716 to the end computing device 702 associated with the event. Compliance module 712 may also include instructions that, when executed by processor(s) 704, permit compliance badge 700 to analyze data corresponding to the detected event based on the compliance rules 714 and the user type 720 to determine compliance and/or non-compliance with hand hygiene practices.
The example process (760) illustrated in
Examples of the compliance rules and compliance badge hygiene status levels (states) for an example hand hygiene compliance network will now be described. By performing proper hand hygiene before and after each patient contact (i.e., when entering and exiting a patient zone), a Healthcare Worker (HCW) is proactively reducing the potential for the spread of harmful or even deadly pathogens. This proactive behavior results in a higher level of protection for both the patient and the HCW. The purpose of the compliance badge is to assist in reaching this higher level of protection by reminding or alerting the HCW of their current hand hygiene status level at all times. This is done, in real-time, as the HCW interacts with patient beds equipped with bed zone module end computing devices and soap/sanitizer dispenser module end computing devices. In some examples, each compliance badge includes one or more status indicators (such as status indicators 710 of
State 1 corresponds to a “Compliant Patient Contact” status level. When an HCW enters a patient zone with a badge at the “Clean” Status level (State 0), the badge's status level changes to State 1 and the LED will remain green while inside that specific patient zone. This informs both the HCW and the patient that the HCW has performed recent hand hygiene prior to contact with the patient.
State 1 may also correspond to a “Compliant Patient Re-Contact” status level (during the State 1 Grace Period). When the HCW leaves the patient zone, their badge will flash the green LED and then the yellow LED together. While the badge is flashing “green/yellow” lights together, this indicates that the HCW may re-enter the same patient zone without the need to perform hand hygiene again. The badge will only remain at the “Compliant Patient Re-Contact Status” level for a limited time. It has a configurable internal timer that will eventually expire and change the badge to the yellow “Cue to Clean” status level (State 1) unless the HCW performs hand hygiene. The internal timer for the “Compliant Patient Re-Contact” status level has a factory default expiration time of 5 minutes, but this can be adjusted to accommodate a HCW's workflow. It is recommended that the HCW check the status of their badge before re-contacting a patient to determine if performing hand hygiene is necessary.
When the badge shows “green/yellow” lights together, the HCW may not enter the patient zone of a different patient without first performing hand hygiene. Going from one patient zone to a different patient zone without performing hand hygiene would be recorded as a non-compliant event, and the badge LED would display a red LED after a brief grace period (30 seconds after leaving the original patient zone).
The yellow LED seen for the “Cue to Clean” status level (State 1 or State 4) indicates that the HCW must perform hand hygiene before either entering or re-entering a patient zone. The “Cue to Clean” status level occurs when the HCW has not recently performed routine hand hygiene (State 4) or when the HCW has recently exited a patient zone (State 1) without performing hand hygiene.
In the case of recent patient zone exit, the badge has a configurable internal timer that will give the HCW a default grace period of 5 minutes during which they can return to their patient. After 5 minutes, another configurable timer begins that causes the yellow LED to flash for one minute (a total of 6 minutes after leaving the patient zone, at default timings). If the one-minute grace period expires before the HCW performs hand hygiene, the badge's hand hygiene status will update to the “NON-Compliant” status level (State 5), showing the red LED.
The internal timer for the “Cue to Clean” status level after inactivity (State 4), has a factory default expiration time of 10 minutes, but this can be adjusted to accommodate a HCW's workflow. It is recommended that the HCW always perform hand hygiene immediately after leaving a patient zone when they are done working with that patient.
When the red LED is visible, the badge is at the “Non-Compliant” status level. This indicates that the HCW has broken the proper hand hygiene protocol of performing hand hygiene before entering a patient zone (State 2—Non-Compliant Patient Contact), before re-entering a patient zone (State 3—Non-Compliant Patient Re-contact) or after exiting a patient zone (State 5—Non-Compliant After Patient Contact). At any of these status levels, the HCW may have the potential to spread pathogens from one patient to another because the defined hand hygiene procedures have not been followed. As soon as the HCW recognizes that they are at a “Non-Compliant” status level, they should immediately perform hand hygiene, unless a critical patient need takes priority.
In this example, there are four ways that an HCW can reach the “Non-Compliant” (red LED) status level:
1. Failing to perform hand hygiene before entering a patient zone (State 2).
2. Failing to perform hand hygiene when going directly from one patient zone to another patient zone (State 2).
3. Failing to perform hand hygiene before re-entering a patient zone after being away from that specific patient zone for more than 5 minutes (default); i.e., exiting and re-entering the same patient zone after being away for an extended time period (State 3).
4. Failing to perform hand hygiene after exiting a patient zone (State 5).
The steps below can be followed to prevent reaching the “Non-Compliant” (red LED) status level:
1. If the badge is asleep, i.e., no flashing LED is visible, perform hand hygiene at a monitored dispenser to wake it up, and to reset hand hygiene status to “Clean” before entering a patient zone.
2. Check the badge's status level before entering a patient zone.
a. If the badge is at the “green” or “Clean” status level, patient zone entry will be compliant.
b. If the badge is at the “Cue to Clean” status level (yellow LED), avoid patient zone entry until hand hygiene has been performed, assuming that there is no overriding patient safety concern.
3. Before re-entering the same patient zone, verify that the badge is at the “Compliant Patient Re-Contact” status level (green/yellow LEDs). Otherwise, perform hand hygiene before re-entering the patient zone.
4. Perform hand hygiene immediately after leaving a patient zone.
In the example hand hygiene compliance network, each patient bed includes a bed zone end computing device that generates a patient zone around a patient bed and detects an entry event and/or an exit event each time a healthcare worker wearing an electronic identification badge enters and/or leaves the patient zone. The badge patient zone detection time (or “bed attach time”) is the length of time a badge remains inside a patient zone before changing from the “Clean” status level (green LED, State 0) to the “Patient Contact” status level (State 1). In one example, the patient zone detection or bed attach time is adjustable/configurable from 0 seconds to 15 seconds with a default time of 3 seconds. The patient zone detection time only applies if the HCW's badge is at the “Clean” status level (State 0) when entering the patient zone. The purpose of the bed attach time feature is to allow the badge to determine if patient zone entry is intentional or unintentional and thus prevent a brief, unintentional patient zone entry from changing the badge's status level (State).
The example compliance badges (such as compliance badges 654A-654N of
The purpose of the State 0 Grace Period (Clean-After Washing or Sanitizing Hands) is to allow time after an HCW uses a monitored dispenser, during which their badge will ignore patient zones. Immediately after using a monitored dispenser, the badge will ignore patient zone entry and maintain the “Clean” Status level (State 0) for the duration of the grace period. After the grace period expires, the badge will behave normally and change to the “Clean Patient Contact” status level (State 1) when patient zone entry occurs. The State 0 Grace Period can be adjusted between 0 and 60 seconds. The factory default is 15 seconds.
With the State 0 Grace Period set to 15 seconds, the HCW activates the dispenser (
The purpose of the State 2 grace period (Non-Compliant Patient Contact) is to prevent the HCW's badge from entering the “Non-Compliant” status level if the HCW briefly and unintentionally moves from one patient zone to another. In this example, when a badge with a “Clean” status level (State 0) enters a patient zone, it will change to the “Compliant Patient Contact” status level (State 1). If the HCW wearing the badge exits the patient zone and enters a different patient zone, the badge should immediately change to the “Non-Compliant” status level (State 2). However, in areas where patient beds are particularly close to one another, it may be unreasonable to enforce non-compliant bed-to-bed contact so strictly. To this end, the State 2 grace period allows an HCW to briefly enter a second patient zone without penalty.
The badge's internal State 2 Grace Period timer starts the moment an HCW exits the patient zone of initial contact. During this time, the HCW's badge will ignore other patient zones until the grace period expires (30 seconds for default setting). If the HCW enters a second patient zone during the State 2 grace period, the badge will produce warning beeps indicating the HCW has entered the second patient zone. Once the grace period expires, the badge will change to the “Non-Compliant” (red LED) status level (State 2) if the HCW is currently inside a second patient zone or enters a second patient zone. If the HCW re-enters the patient zone of initial contact prior to grace period expiration, the internal timer will reset and the badge will remain at the “Compliant Patient Contact” status level (State 1). In the present example, the State 2 grace period can be adjusted between 0 and 60 seconds, and the factory default is 30 seconds.
The purpose of the State 3 grace period (Compliant Patient Re-contact) is to provide an HCW with flexibility while working around a patient bed by giving them the ability to enter, exit and re-enter the same patient zone as many times as necessary without having to perform hand hygiene before each re-entry. When a badge having a “Clean” status level (State 0) enters a patient zone, it will change to the “Compliant Patient Contact” status level (State 1). When the badge leaves the patient zone, it will change to the “Compliant Patient Re-Contact” status level (State 1) with green and yellow flashing LEDs (
The State 3 grace period begins at the moment the badge leaves the patient zone and will reset when the badge re-enters the patient zone, unless the State 3 grace period has expired before re-entry. If the State 3 grace period has expired, the badge may beep, for example, three times, and change to the “Cue to Clean” status level with only the yellow LED flashing. Now, the badge will change to the “Non-Compliant” (red LED) status level (State 3) if it re-enters the patient zone unless the HCW performs hand hygiene prior to entry.
In this example, the State 3 grace period may be adjusted between 1 minute and 45 minutes. The factory default may be, for example, 5 minutes.
If the State 3 grace period expires, the badge will beep, for example, three times and change to the “Cue to Clean” status level (State 1) with only the yellow LED flashing. If the HCW re-enters the patient zone 804A while at the “Cue to Clean” status level (
Table 3 lists example adjustable/configurable badge configurations:
In this example, the State 2 grace period is less than the State 3 grace period, and the State 3 grace period is less than the State 5 timeout. The bed attach time is in multiples of 3, i.e., at 3 second intervals. Thus configuration option 0=0 seconds, 1=3 seconds, 2=6 seconds, 3=9 seconds, 4=12 seconds, and 5=15 seconds.
Example 1: A wireless sensor network system, comprising a gateway computing device, a plurality of cluster host computing devices, and a plurality of end computing devices, each end computing device including a sensor that detects event data, each end computing device further configured for wireless bi-directional communication with one of the plurality of cluster-host computing devices; the plurality of cluster host computing devices forming a route between each of the plurality of end devices and the gateway, each cluster host computing device storing a next downstream network address; wherein each of the plurality of cluster host computing devices forming part of the route from one of the plurality of end computing devices to the gateway further modifies a downstream network message received from a previous cluster host computing device, and further: appends a network address of the previous cluster host obtained from a source address field of a downstream network message to an appended addresses field of the downstream network message; sets a source address field of the downstream network message to a network address of the current cluster host computing device; and sets the destination address field of the downstream network message to the next downstream network address stored by the current cluster host computing device; and wherein the current cluster host computing device further wirelessly transmits the modified downstream network message to the next downstream network address contained in the destination field of the modified downstream network message.
Example 2. The system of Example 1, wherein the downstream network message further includes a message payload field including event data corresponding to an event detected one of the end computing device.
Example 3. The system of Example 1, wherein the downstream network message further includes a node count field containing a node count corresponding to a number of nodes between the current cluster host computing device and an originating computing device of the downstream network message, and wherein the current cluster host computing device further increments the node count in the node count field of the downstream network message.
Example 4. The system of Example 1, wherein the downstream network message further includes a message payload field including a factory address of the originating computing device.
Example 5. The system of Example 1, wherein the wireless network comprises a cluster-tree network.
Example 6. The system of Example 1 further comprising a server computing device configured to receive downstream network messages from the gateway computing device; the server computing device further configured to update a portion of a route table corresponding to an originating end computing device, the portion of the route table including a factory address of the originating end computing device, appended network addresses contained in the appended addresses field of the modified downstream network message, and a node count contained in the node count field of the modified network message.
Example 7. The system of Example 6, the server computing device further configured to generate an upstream network message to be transmitted to the originating computing device, the upstream network message including a payload field containing the factory address of the originating computing device, an appended addresses field containing the appended network addresses stored in the portion of the route table corresponding to the originating computing device, and a node count field containing the node count stored in the portion of the route table corresponding to the originating computing device.
Example 8. A method of wireless communication between a first computing device, a second computing device, and a third computing device in a wireless network, comprising storing, by the second computing device, a network address of a third computing device, the third computing device being a next downstream node along a route through the wireless network from the second computing device to a gateway computing device; wirelessly receiving, by the second computing device, a downstream network message from the first computing device, the downstream network message including a source address field containing a network address of the first computing device, a destination address field containing a network address of the second computing device, and an appended address field; modifying, by the second computing device, the downstream network message, comprising appending, by the second computing device, the network address of the first computing device to the appended addresses field of the downstream network message; setting, by the second computing device, the source address field of the downstream network message to the network address of the second computing device; and setting, by the second computing device, the destination address field of the downstream network message to the network address of the third computing device stored by the second computing device; and wirelessly transmitting, by the second computing device, the modified downstream network message to the network address of the third computing device as contained in the destination field of the modified network message.
Example 9. The method of Example 8, wherein the downstream network message further includes a node count field containing a node count corresponding to a number of nodes between the first computing device and an originating computing device of the downstream network message, and wherein modifying the downstream network message further comprises incrementing, by the second computing device, the node count in the node count field of the downstream network message.
Example 10. The method of Example 8, wherein the downstream network message further includes a message payload field including event data corresponding to an event detected at the originating computing device.
Example 11. The method of Example 8, wherein the downstream network message further includes a message payload field including a factory address of the originating computing device.
Example 12. The method of Example 8, wherein the wireless network comprises a cluster-tree network.
Example 13. The method of Example 8, further comprising receiving, by a server computing device and from the gateway computing device, the modified network message; updating, by the server computing device, a portion of a route table corresponding to the originating computing device, the portion of the route table including a factory address of the originating computing device, appended network addresses contained in the appended addresses field of the modified network message, and the node count contained in the node count field of the modified network message.
Example 14. The method of Example 13, further comprising generating, by the server computing device, an upstream network message to be transmitted to the originating computing device, the upstream network message including a payload field containing the factory address of the originating computing device, an appended addresses field containing the appended network addresses stored in the portion of the route table corresponding to the originating computing device, and a node count field containing the node count stored in the portion of the route table corresponding to the originating computing device.
Example 15. The method of Example 13, further comprising receiving, by the second computing device, the upstream network message; modifying, by the second computing device, the upstream network message, comprising setting, by the second computing device, the source address field of the downstream network message to the network address of the second computing device; and setting, by the second computing device, the destination address field of the upstream network message to a next hop network address contained in the appended addresses field of the upstream network message, the next hop network address corresponding to the network address of the first computing device; removing, by the second computing device, the next hop network address from the appended addresses field of the upstream network message; and wirelessly transmitting, by the second computing device, the modified upstream network message to the network address of the first computing device as contained in the destination address field of the modified upstream network message.
Example 16. A method comprising wirelessly receiving, by a server computing device and from a gateway computing device, a network message originating from one of a plurality of end computing devices, the network message including event data corresponding to an event detected at the originating end computing device, the network message further including a list of one or more appended network addresses corresponding to one or more cluster host computing devices forming a wireless communication route between the originating end computing device and the gateway computing device, the network messages further including a node count corresponding to the number of cluster host computing devices forming the wireless communication route between the originating end computing device and the gateway computing device; and maintaining, by the server computing device, and based on the received network message, a portion of a route table corresponding to the originating end computing device, the portion of the route table including the list of one or more appended network addresses and the node count.
Example 17. The method of Example 16, wherein the network message further includes a factory address of the originating end computing device, and the portion of the route table further includes the factory address of the originating end computing device.
Example 18. The method of Example 16, further including generating, by the server computing device, an upstream network message intended for a destination one of the plurality of end computing devices, the upstream network message including the list of one or more appended network addresses from the portion of the route table corresponding to the destination end computing device, and including the node count from the portion of the route table corresponding to the destination end computing device.
Example 19. A method comprising wirelessly receiving, by a current cluster host computing device and from a previous cluster host computing device, a network message originating from one of a plurality of end computing devices, the network message including event data corresponding to an event detected at the originating end computing device; and wirelessly transmitting, by the current cluster host computing device, the network message, the transmitted network message including the event data, a list of one or more appended network addresses corresponding to one or more previous cluster host computing devices forming a wireless communication route between the originating end computing device and the current cluster host computing device, and a node count corresponding to the number of cluster host computing devices forming the wireless communication route between the originating end computing device and the current cluster host computing device.
Example 20. A hand hygiene compliance network, comprising a plurality of end computing devices, each of the plurality of end computing devices associated with a different one of a plurality of hand hygiene product dispensers and configured to detect dispense events; and a server computing device configured to wireless receive, from a gateway computing device, a downstream network message originating from one of the plurality of end computing devices, the downstream network message including dispense event data corresponding to a detected dispense event, the downstream network message further including a list of one or more appended network addresses corresponding to one or more cluster host computing devices forming a wireless communication route between the originating end computing device and the gateway computing device, the downstream network message further including a node count corresponding to the number of cluster host computing devices forming the wireless communication route between the originating end computing device and the gateway computing device, the server computing device further configured to maintain based on the received downstream network message, a portion of a route table corresponding to the originating end computing device, the portion of the route table including the list of one or more appended network addresses and the node count the server computing device further configured to analyze the dispense event data and to monitor hand hygiene compliance based on the analysis.
Various examples have been described. These and other examples are within the scope of the following claims.
This application is a continuation of U.S. application Ser. No. 16/723,234, filed Dec. 20, 2019 and entitled, “Adaptive Route, Bi-Directional Network Communication,” which claims the benefit of U.S. Provisional Application No. 62/782,991 filed Dec. 20, 2018, and entitled, “Adaptive Route, Bi-Directional Network Communication,” each of which is incorporated by reference herein in its entirety.
| Number | Name | Date | Kind |
|---|---|---|---|
| D48940 | Key | Apr 1916 | S |
| 1643828 | Young | Sep 1927 | A |
| 1985615 | Mitchell | Dec 1934 | A |
| 2219597 | Lutz | Oct 1940 | A |
| D134354 | Miller | Nov 1942 | S |
| 2319739 | Kessler | May 1943 | A |
| 2333791 | Hutchinson | Nov 1943 | A |
| 3091327 | Lalley | May 1963 | A |
| 3136157 | Seed et al. | Jun 1964 | A |
| 3412254 | Mever-Doering et al. | Nov 1968 | A |
| 3526334 | Ashton et al. | Sep 1970 | A |
| 3578094 | Henry et al. | May 1971 | A |
| 3653544 | Young et al. | Apr 1972 | A |
| 3736584 | Goble et al. | May 1973 | A |
| 3743598 | Field | Jul 1973 | A |
| 3754871 | Hessel et al. | Aug 1973 | A |
| 3760166 | Adams et al. | Sep 1973 | A |
| 3761909 | Schweitzer et al. | Sep 1973 | A |
| 3772193 | Nelli et al. | Nov 1973 | A |
| 3774056 | Sample et al. | Nov 1973 | A |
| 3786467 | Cotter | Jan 1974 | A |
| 3801977 | Cotter | Jan 1974 | A |
| 3796349 | Weber | Mar 1974 | A |
| 3826113 | Boraas et al. | Jul 1974 | A |
| 3826408 | Berndt et al. | Jul 1974 | A |
| 3866198 | Cohen | Feb 1975 | A |
| 3961321 | Moss | Jun 1976 | A |
| 3986182 | Hackett | Oct 1976 | A |
| 4040515 | Hessel et al. | Aug 1977 | A |
| 4046996 | Williams et al. | Sep 1977 | A |
| 4076146 | Lausberg et al. | Feb 1978 | A |
| 4083298 | Schotten | Apr 1978 | A |
| 4117462 | Miller | Sep 1978 | A |
| 4198618 | Kleinschmidt | Apr 1980 | A |
| 4199001 | Kratz | Apr 1980 | A |
| 4209776 | Frederick | Jun 1980 | A |
| 4211517 | Schmid | Jul 1980 | A |
| 4241400 | Keifer | Dec 1980 | A |
| 4247396 | Buseing | Jan 1981 | A |
| 4265266 | Kierbow et al. | May 1981 | A |
| 4275390 | Heywang et al. | Jun 1981 | A |
| 4319349 | Hackett | Mar 1982 | A |
| 4353482 | Tomlinson et al. | Oct 1982 | A |
| 4360905 | Hackett | Nov 1982 | A |
| 4373418 | Rhodes et al. | Feb 1983 | A |
| 4380726 | Sado et al. | Apr 1983 | A |
| 4396828 | Dino et al. | Aug 1983 | A |
| 4402426 | Faulkner et al. | Sep 1983 | A |
| 4404639 | McGuire et al. | Sep 1983 | A |
| 4463844 | Huffman et al. | Aug 1984 | A |
| 4482785 | Finnegan et al. | Nov 1984 | A |
| 4486910 | Saalmann | Dec 1984 | A |
| 4509543 | Livingston et al. | Apr 1985 | A |
| 4523219 | Heidegger et al. | Jun 1985 | A |
| 4539846 | Grossman | Sep 1985 | A |
| 4573606 | Lewis et al. | Mar 1986 | A |
| 4590460 | Abbott et al. | May 1986 | A |
| 4597091 | Blake | Jun 1986 | A |
| 4606085 | Davies | Aug 1986 | A |
| 4630654 | Kennedy, Jr. | Dec 1986 | A |
| 4644509 | Kiewit | Feb 1987 | A |
| 4676399 | Burckhardt | Jun 1987 | A |
| 4688585 | Vetter | Aug 1987 | A |
| 4690305 | Copeland | Sep 1987 | A |
| 4697243 | Moore et al. | Sep 1987 | A |
| 4707848 | Durston et al. | Nov 1987 | A |
| 4711370 | Goudy, Jr. et al. | Dec 1987 | A |
| 4727522 | Steiner et al. | Feb 1988 | A |
| 4729120 | Steiner et al. | Mar 1988 | A |
| 4733971 | Pratt | Mar 1988 | A |
| 4756321 | Livingston et al. | Jul 1988 | A |
| 4766548 | Cedrone et al. | Aug 1988 | A |
| 4770859 | Heiser, Jr. | Sep 1988 | A |
| 4800372 | Poteet | Jan 1989 | A |
| 4826661 | Copeland et al. | May 1989 | A |
| 4834546 | Putz | May 1989 | A |
| 4837811 | Butler et al. | Jun 1989 | A |
| 4839597 | Rowland | Jun 1989 | A |
| 4843579 | Andrews et al. | Jun 1989 | A |
| 4845965 | Copeland et al. | Jul 1989 | A |
| 4848381 | Livingston et al. | Jul 1989 | A |
| 4858449 | Lehn | Aug 1989 | A |
| 4867196 | Zetena et al. | Sep 1989 | A |
| 4867343 | Ricciardi et al. | Sep 1989 | A |
| 4896144 | Bogstad | Jan 1990 | A |
| 4908190 | Maglio et al. | Mar 1990 | A |
| 4938240 | Lakhan et al. | Jul 1990 | A |
| 4944428 | Gmuer et al. | Jul 1990 | A |
| 4964185 | Lehn | Oct 1990 | A |
| 4969011 | Faull et al. | Nov 1990 | A |
| 4974646 | Martin et al. | Dec 1990 | A |
| 4976137 | Decker et al. | Dec 1990 | A |
| 4980292 | Elbert et al. | Dec 1990 | A |
| D313422 | Leonard et al. | Jan 1991 | S |
| 4987402 | Nykerk | Jan 1991 | A |
| 4991146 | Ransdell et al. | Feb 1991 | A |
| 4999124 | Copeland | Mar 1991 | A |
| 5006995 | Toschi et al. | Apr 1991 | A |
| 5014211 | Turner et al. | May 1991 | A |
| 5014877 | Roos | May 1991 | A |
| 5024352 | Gmur et al. | Jun 1991 | A |
| 5036479 | Prednis et al. | Jul 1991 | A |
| 5038807 | Bailey et al. | Aug 1991 | A |
| 5038973 | Gmur et al. | Aug 1991 | A |
| 5040699 | Gangemi | Aug 1991 | A |
| 5043860 | Koether et al. | Aug 1991 | A |
| 5053206 | Maglio et al. | Oct 1991 | A |
| 5059954 | Beldham et al. | Oct 1991 | A |
| 5064094 | Roos et al. | Nov 1991 | A |
| 5083298 | Citterio et al. | Jan 1992 | A |
| 5110364 | Mazur et al. | May 1992 | A |
| 5115842 | Crafts et al. | May 1992 | A |
| 5136281 | Bonaquist | Aug 1992 | A |
| 5147615 | Bird et al. | Sep 1992 | A |
| 5150099 | Lienau | Sep 1992 | A |
| 5153520 | Dumbeck | Oct 1992 | A |
| 5158895 | Ashihara et al. | Oct 1992 | A |
| 5199118 | Cole et al. | Apr 1993 | A |
| 5202666 | Knippscheer | Apr 1993 | A |
| 5203366 | Czeck et al. | Apr 1993 | A |
| 5219224 | Pratt | Jun 1993 | A |
| 5222027 | Williams et al. | Jun 1993 | A |
| 5240326 | Evanson | Aug 1993 | A |
| 5245317 | Chidley et al. | Sep 1993 | A |
| 5263006 | Hermesmeyer | Nov 1993 | A |
| 5268153 | Muller | Dec 1993 | A |
| 5279448 | Hanlin et al. | Jan 1994 | A |
| 5283639 | Esch et al. | Feb 1994 | A |
| 5294022 | Earle | Mar 1994 | A |
| 5309409 | Jones et al. | May 1994 | A |
| 5316195 | Moksnes et al. | May 1994 | A |
| 5322571 | Plummer et al. | Jun 1994 | A |
| 5332312 | Evanson | Jul 1994 | A |
| 5345379 | Brous et al. | Sep 1994 | A |
| 5369032 | Pratt | Nov 1994 | A |
| 5370267 | Schroeder | Dec 1994 | A |
| 5389344 | Copeland et al. | Feb 1995 | A |
| 5390385 | Beldham | Feb 1995 | A |
| 5397028 | Jesadanont | Mar 1995 | A |
| 5400018 | Scholl et al. | Mar 1995 | A |
| 5404893 | Brady et al. | Apr 1995 | A |
| 5407598 | Olson et al. | Apr 1995 | A |
| 5411716 | Thomas et al. | May 1995 | A |
| 5427748 | Wiedrich et al. | Jun 1995 | A |
| 5430293 | Sato et al. | Jul 1995 | A |
| 5463595 | Rodhall et al. | Oct 1995 | A |
| 5467481 | Srivastava | Nov 1995 | A |
| 5476385 | Parikh et al. | Dec 1995 | A |
| 5480068 | Frazier et al. | Jan 1996 | A |
| 5497914 | Maltsis | Mar 1996 | A |
| 5500050 | Chan et al. | Mar 1996 | A |
| 5505915 | Copeland et al. | Apr 1996 | A |
| 5556478 | Brady et al. | Sep 1996 | A |
| 5570079 | Dockery | Oct 1996 | A |
| 5580448 | Brandreth | Dec 1996 | A |
| 5581982 | Schroeder et al. | Dec 1996 | A |
| 5584025 | Keithley et al. | Dec 1996 | A |
| 5584079 | Wong et al. | Dec 1996 | A |
| 5609417 | Otte | Mar 1997 | A |
| 5610589 | Evans et al. | Mar 1997 | A |
| 5619183 | Ziegra et al. | Apr 1997 | A |
| 5624810 | Miller et al. | Apr 1997 | A |
| 5625659 | Sears | Apr 1997 | A |
| 5625908 | Shaw | May 1997 | A |
| 5632411 | Harty et al. | May 1997 | A |
| 5636008 | Lobiondo et al. | Jun 1997 | A |
| 5638417 | Boyer et al. | Jun 1997 | A |
| 5653269 | Miller et al. | Aug 1997 | A |
| 5661471 | Kotlicki et al. | Aug 1997 | A |
| 5671262 | Boyer et al. | Sep 1997 | A |
| 5679173 | Hartman | Oct 1997 | A |
| 5681400 | Brady et al. | Oct 1997 | A |
| 5684458 | Calvarese | Nov 1997 | A |
| 5687717 | Halpern et al. | Nov 1997 | A |
| 5694323 | Koropitzer et al. | Dec 1997 | A |
| 5695091 | Winings et al. | Dec 1997 | A |
| 5724261 | Denny et al. | Mar 1998 | A |
| 5731526 | Kindrick | Mar 1998 | A |
| 5735925 | Scott | Apr 1998 | A |
| 5745381 | Tanaka et al. | Apr 1998 | A |
| 5757664 | Rogers et al. | May 1998 | A |
| 5758300 | Abe | May 1998 | A |
| 5759501 | Livingston et al. | Jun 1998 | A |
| 5761278 | Pickett et al. | Jun 1998 | A |
| 5762096 | Mirabile | Jun 1998 | A |
| 5764136 | Harron | Jun 1998 | A |
| 5765605 | Waymire et al. | Jun 1998 | A |
| 5769536 | Kotylak | Jun 1998 | A |
| 5771925 | Lewandowski | Jun 1998 | A |
| D396009 | Reubens | Jul 1998 | S |
| 5777895 | Kuroda et al. | Jul 1998 | A |
| 5781942 | Allen et al. | Jul 1998 | A |
| 5793653 | Segal | Aug 1998 | A |
| 5808553 | Cunningham | Sep 1998 | A |
| 5812059 | Shaw et al. | Sep 1998 | A |
| 5821523 | Bunte et al. | Oct 1998 | A |
| 5826749 | Howland et al. | Oct 1998 | A |
| 5827486 | Crossdale | Oct 1998 | A |
| 5839097 | Klausner | Nov 1998 | A |
| 5851291 | Poterala et al. | Dec 1998 | A |
| 5861881 | Freeman et al. | Jan 1999 | A |
| 5864783 | Struck et al. | Jan 1999 | A |
| 5875430 | Koether | Feb 1999 | A |
| 5885446 | McGrew, Jr. | Mar 1999 | A |
| 5887145 | Harari et al. | Mar 1999 | A |
| 5887975 | Mordaunt et al. | Mar 1999 | A |
| 5897671 | Newman et al. | Apr 1999 | A |
| 5900067 | Jones | May 1999 | A |
| 5902749 | Lichtwardt et al. | May 1999 | A |
| 5913915 | McQuinn | Jun 1999 | A |
| 5917425 | Crimmins | Jun 1999 | A |
| 5919567 | Okada et al. | Jul 1999 | A |
| 5931877 | Smith et al. | Aug 1999 | A |
| 5933479 | Michael et al. | Aug 1999 | A |
| 5938074 | Dartus | Aug 1999 | A |
| 5939974 | Heagle et al. | Aug 1999 | A |
| 5945910 | Gorra | Aug 1999 | A |
| 5952924 | Evans et al. | Sep 1999 | A |
| 5954069 | Foster | Sep 1999 | A |
| 5956487 | Venkatraman et al. | Sep 1999 | A |
| 5961561 | Wakefield, II | Oct 1999 | A |
| 5966753 | Gauthier | Oct 1999 | A |
| 5967202 | Mullen et al. | Oct 1999 | A |
| 5973696 | Agranat et al. | Oct 1999 | A |
| 5974345 | Buck et al. | Oct 1999 | A |
| 5975352 | Spriggs et al. | Nov 1999 | A |
| 5977913 | Christ | Nov 1999 | A |
| 5979703 | Nystrom | Nov 1999 | A |
| 5980090 | Royal et al. | Nov 1999 | A |
| 5987105 | Jenkins et al. | Nov 1999 | A |
| 5992686 | Cline et al. | Nov 1999 | A |
| 6003070 | Frantz | Dec 1999 | A |
| 6007788 | Bellon et al. | Dec 1999 | A |
| 6012041 | Brewer et al. | Jan 2000 | A |
| 6029286 | Funk | Feb 2000 | A |
| 6031461 | Lynn | Feb 2000 | A |
| 6038331 | Johnson | Mar 2000 | A |
| 6049792 | Hart et al. | Apr 2000 | A |
| 6061668 | Sharrow | May 2000 | A |
| 6065639 | Maddox et al. | May 2000 | A |
| 6073124 | Krishnan et al. | Jun 2000 | A |
| 6082149 | Woods | Jul 2000 | A |
| 6098843 | Soberanis et al. | Aug 2000 | A |
| 6120175 | Tewell | Sep 2000 | A |
| D431404 | Brazis et al. | Oct 2000 | S |
| 6125482 | Foster | Oct 2000 | A |
| 6129449 | McCain et al. | Oct 2000 | A |
| 6130607 | McClanahan et al. | Oct 2000 | A |
| 6133555 | Brenn | Oct 2000 | A |
| 6136184 | King | Oct 2000 | A |
| 6147607 | Lynn | Nov 2000 | A |
| 6164189 | Anson | Dec 2000 | A |
| 6167358 | Othmer et al. | Dec 2000 | A |
| 6175308 | Tallman et al. | Jan 2001 | B1 |
| 6191693 | Sangsingkeow | Feb 2001 | B1 |
| 6211788 | Lynn et al. | Apr 2001 | B1 |
| 6213424 | Helter-Grand | Apr 2001 | B1 |
| 6220312 | Hirsch et al. | Apr 2001 | B1 |
| 6221788 | Kobayashi et al. | Apr 2001 | B1 |
| 6236317 | Cohen et al. | May 2001 | B1 |
| 6236953 | Segal | May 2001 | B1 |
| 6247621 | Lewis | Jun 2001 | B1 |
| 6249778 | Vaghi | Jun 2001 | B1 |
| 6259956 | Myers et al. | Jul 2001 | B1 |
| 6269975 | Soberanis et al. | Aug 2001 | B2 |
| 6278372 | Velasco, Jr. | Aug 2001 | B1 |
| 6279777 | Goodin et al. | Aug 2001 | B1 |
| 6288641 | Casais | Sep 2001 | B1 |
| 6291000 | Havakawa | Sep 2001 | B1 |
| 6314282 | Weber et al. | Nov 2001 | B1 |
| 6321204 | Kazanu et al. | Nov 2001 | B1 |
| 6330499 | Chou et al. | Dec 2001 | B1 |
| 6331964 | Barone | Dec 2001 | B1 |
| 6347724 | Chen et al. | Feb 2002 | B1 |
| 6351223 | DeWeerd et al. | Feb 2002 | B1 |
| 6356205 | Salvo et al. | Mar 2002 | B1 |
| 6357292 | Schultz et al. | Mar 2002 | B1 |
| 6360181 | Gemmell et al. | Mar 2002 | B1 |
| 6368420 | Angevaare et al. | Apr 2002 | B1 |
| 6370454 | Moore | Apr 2002 | B1 |
| 6375038 | Daansen et al. | Apr 2002 | B1 |
| 6377868 | Gardner, Jr. | Apr 2002 | B1 |
| 6392546 | Smith | May 2002 | B1 |
| 6404837 | Thompson et al. | Jun 2002 | B1 |
| 6417773 | Vlahos et al. | Jul 2002 | B1 |
| 6418371 | Arnold | Jul 2002 | B1 |
| 6426701 | Levy et al. | Jul 2002 | B1 |
| 6438471 | Katagishi et al. | Aug 2002 | B1 |
| 6463940 | Thomas et al. | Oct 2002 | B1 |
| 6472615 | Carlson | Oct 2002 | B1 |
| 6476385 | Albert | Nov 2002 | B1 |
| 6485979 | Kippenhan et al. | Nov 2002 | B1 |
| 6490513 | Fish et al. | Dec 2002 | B1 |
| 6523193 | Saraya | Feb 2003 | B2 |
| 6524390 | Jones | Feb 2003 | B1 |
| 6547097 | Cavallaro et al. | Apr 2003 | B1 |
| 6561381 | Osterheld et al. | May 2003 | B1 |
| 6577240 | Armstrong | Jun 2003 | B2 |
| 6611207 | Yuan et al. | Aug 2003 | B1 |
| 6681003 | Linder | Jan 2004 | B2 |
| 6697706 | Gardner, Jr. | Feb 2004 | B2 |
| 6707873 | Thompson et al. | Mar 2004 | B2 |
| 6718394 | Cain | Apr 2004 | B2 |
| 6727818 | Wildman et al. | Apr 2004 | B1 |
| 6730024 | Freyre et al. | May 2004 | B2 |
| 6749148 | Helfer-Grand | Jun 2004 | B2 |
| 6759959 | Wildman | Jul 2004 | B2 |
| 6762161 | Sava et al. | Jul 2004 | B2 |
| 6778092 | Braune | Aug 2004 | B2 |
| 6781523 | Matsui et al. | Aug 2004 | B2 |
| 6792395 | Roberts | Sep 2004 | B2 |
| 6799085 | Crisp, III | Sep 2004 | B1 |
| 6807460 | Black et al. | Oct 2004 | B2 |
| 6870846 | Cain | Mar 2005 | B2 |
| 6882278 | Winings et al. | Apr 2005 | B2 |
| 6882315 | Richley et al. | Apr 2005 | B2 |
| 6883563 | Smith | Apr 2005 | B2 |
| 6893321 | Buchanan et al. | May 2005 | B1 |
| 6896140 | Perry | May 2005 | B1 |
| 6897780 | Ulrich et al. | May 2005 | B2 |
| 6917290 | Land | Jul 2005 | B2 |
| 6919567 | Iwasawa | Jul 2005 | B2 |
| 6950683 | Hunt | Sep 2005 | B2 |
| 6956498 | Gauthier et al. | Oct 2005 | B1 |
| 6970860 | Liu et al. | Nov 2005 | B1 |
| 6975231 | Lane et al. | Dec 2005 | B2 |
| 6977588 | Schotz et al. | Dec 2005 | B2 |
| 6987228 | MacMichael et al. | Jan 2006 | B1 |
| 6991779 | Steiner et al. | Jan 2006 | B2 |
| 7015816 | Wildman et al. | Mar 2006 | B2 |
| 7023341 | Stilp et al. | Apr 2006 | B2 |
| 7023356 | Burkhardt et al. | Apr 2006 | B2 |
| 7042361 | Kazdin et al. | May 2006 | B2 |
| 7056050 | Sacks | Jun 2006 | B2 |
| 7067054 | Fritze | Jun 2006 | B2 |
| 7069188 | Roberts | Jun 2006 | B2 |
| 7075412 | Reynolds et al. | Jul 2006 | B1 |
| 7099781 | Heidi et al. | Aug 2006 | B1 |
| 7099856 | Barangan et al. | Aug 2006 | B2 |
| 7117374 | Hill et al. | Oct 2006 | B2 |
| 7119688 | Wildman | Oct 2006 | B2 |
| 7119692 | Lieffort et al. | Oct 2006 | B2 |
| 7128215 | Danechi | Oct 2006 | B2 |
| 7142108 | Diener et al. | Nov 2006 | B2 |
| 7154397 | Zerhusen et al. | Dec 2006 | B2 |
| 7157045 | McVey | Jan 2007 | B2 |
| 7160846 | Biering et al. | Jan 2007 | B2 |
| 7175048 | Wolfschaffner | Feb 2007 | B2 |
| 7187287 | Ryal | Mar 2007 | B2 |
| 7191090 | Cunningham | Mar 2007 | B1 |
| 7201005 | Voglewede et al. | Apr 2007 | B2 |
| 7202780 | Teller | Apr 2007 | B2 |
| 7228990 | Schmidt | Jun 2007 | B2 |
| 7236097 | Cunningham | Jun 2007 | B1 |
| 7242306 | Wildman et al. | Jul 2007 | B2 |
| 7242307 | LeBlond et al. | Jul 2007 | B1 |
| 7248933 | Wildman | Jul 2007 | B2 |
| 7265673 | Teller | Sep 2007 | B2 |
| 7266347 | Gross | Sep 2007 | B2 |
| 7267531 | Anderson et al. | Sep 2007 | B2 |
| 7271728 | Taylor et al. | Sep 2007 | B2 |
| 7272537 | Mogadam | Sep 2007 | B2 |
| 7286057 | Bolling | Oct 2007 | B2 |
| 7292914 | Jungmann et al. | Nov 2007 | B2 |
| 7293645 | Harper et al. | Nov 2007 | B2 |
| 7315245 | Lynn et al. | Jan 2008 | B2 |
| 7320418 | Sassoon | Jan 2008 | B2 |
| 7330108 | Thomas | Feb 2008 | B2 |
| 7372367 | Lane et al. | May 2008 | B2 |
| 7375640 | Plost | May 2008 | B1 |
| 7400264 | Boaz | Jul 2008 | B2 |
| 7408470 | Wildman et al. | Aug 2008 | B2 |
| 7411511 | Kennish et al. | Aug 2008 | B2 |
| 7423533 | LeBlond et al. | Sep 2008 | B1 |
| 7425900 | Lynn et al. | Sep 2008 | B2 |
| 7440620 | Aartsen | Oct 2008 | B1 |
| 7443302 | Reeder et al. | Oct 2008 | B2 |
| 7443305 | Verdiramo | Oct 2008 | B2 |
| RE40588 | Ostendorf et al. | Nov 2008 | E |
| 7450472 | Guyvarch | Nov 2008 | B2 |
| 7450477 | Kim et al. | Nov 2008 | B2 |
| 7457869 | Kernan | Nov 2008 | B2 |
| 7474215 | Scott et al. | Jan 2009 | B2 |
| 7477148 | Lynn et al. | Jan 2009 | B2 |
| 7482936 | Bolling | Jan 2009 | B2 |
| 7486193 | Elwell | Feb 2009 | B2 |
| 7487538 | Mok | Feb 2009 | B2 |
| 7490045 | Flores et al. | Feb 2009 | B1 |
| 7496479 | Garcia et al. | Feb 2009 | B2 |
| 7530729 | O'Callaghan | May 2009 | B2 |
| 7538680 | Scott et al. | May 2009 | B2 |
| 7551092 | Henry | Jun 2009 | B1 |
| 7597122 | Smith | Oct 2009 | B1 |
| 7600137 | Trappeniers et al. | Oct 2009 | B2 |
| 7605704 | Munro et al. | Oct 2009 | B2 |
| 7611030 | Reynolds et al. | Nov 2009 | B2 |
| 7616122 | Bolling | Nov 2009 | B2 |
| 7649884 | Ahmed | Jan 2010 | B1 |
| 7682464 | Glenn et al. | Mar 2010 | B2 |
| 7718395 | Carling | May 2010 | B2 |
| 7738457 | Nordmark | Jun 2010 | B2 |
| 7755494 | Melker et al. | Jul 2010 | B2 |
| 7770782 | Sahud | Aug 2010 | B2 |
| 7780453 | Carling | Aug 2010 | B2 |
| 7783380 | York et al. | Aug 2010 | B2 |
| 7785109 | Carling | Aug 2010 | B2 |
| 7812730 | Wildman et al. | Oct 2010 | B2 |
| 7855651 | LeBlond et al. | Dec 2010 | B2 |
| 7891523 | Mehus et al. | Feb 2011 | B2 |
| 7893842 | Deutsch | Feb 2011 | B2 |
| 7898407 | Hufton et al. | Mar 2011 | B2 |
| 7952484 | Lynn | May 2011 | B2 |
| 7978564 | DeLaHuerga | Jul 2011 | B2 |
| 7982619 | Bolling | Jul 2011 | B2 |
| 8020733 | Snodgrass | Sep 2011 | B2 |
| 8026821 | Reeder et al. | Sep 2011 | B2 |
| 8040245 | Koblasz | Oct 2011 | B2 |
| 8045498 | Hyland | Oct 2011 | B2 |
| 8056768 | Snodgrass | Nov 2011 | B2 |
| 8085155 | Prodanovich et al. | Dec 2011 | B2 |
| 8087543 | Yang et al. | Jan 2012 | B2 |
| D654743 | Rospierski | Feb 2012 | S |
| 8146613 | Barnhill et al. | Apr 2012 | B2 |
| 8152027 | Baker | Apr 2012 | B1 |
| 8154412 | Verdiramo | Apr 2012 | B2 |
| 8164439 | Dempsey et al. | Apr 2012 | B2 |
| 8196810 | Sahud | Jun 2012 | B2 |
| 8212653 | Goldstein et al. | Jul 2012 | B1 |
| 8237558 | Momen et al. | Aug 2012 | B2 |
| 8240517 | Stob et al. | Aug 2012 | B1 |
| 8249295 | Johnson | Aug 2012 | B2 |
| 8258965 | Reeder et al. | Sep 2012 | B2 |
| 8261950 | Cittadino et al. | Sep 2012 | B2 |
| 8264343 | Snodgrass | Sep 2012 | B2 |
| 8279063 | Wohltjen | Oct 2012 | B2 |
| 8294585 | Barnhill | Oct 2012 | B2 |
| 8308027 | Law et al. | Nov 2012 | B2 |
| 8342365 | Snodgrass | Jan 2013 | B2 |
| 8344893 | Drammeh | Jan 2013 | B1 |
| 8350706 | Wegelin et al. | Jan 2013 | B2 |
| 8368544 | Wildman et al. | Feb 2013 | B2 |
| 8372207 | Shields | Feb 2013 | B1 |
| 8395515 | Tokhtuev et al. | Mar 2013 | B2 |
| 8400309 | Glenn et al. | Mar 2013 | B2 |
| 8427323 | Alper et al. | Apr 2013 | B2 |
| 8482406 | Snodgrass | Jul 2013 | B2 |
| 8502680 | Tokhtuev et al. | Aug 2013 | B2 |
| 8502681 | Bolling et al. | Aug 2013 | B2 |
| 8511512 | Carlson et al. | Aug 2013 | B2 |
| 8525666 | Melker et al. | Sep 2013 | B2 |
| 8547220 | Dempsey et al. | Oct 2013 | B1 |
| 8558660 | Nix et al. | Oct 2013 | B2 |
| 8558701 | Wegelin et al. | Oct 2013 | B2 |
| 8564431 | Snodgrass | Oct 2013 | B2 |
| D693140 | Rospierski | Nov 2013 | S |
| 8587437 | Kyle et al. | Nov 2013 | B2 |
| 8598996 | Wildman et al. | Dec 2013 | B2 |
| 8633806 | Amir | Jan 2014 | B2 |
| 8633816 | Snodgrass et al. | Jan 2014 | B2 |
| 8639527 | Rensvold et al. | Jan 2014 | B2 |
| 8646656 | Johnson | Feb 2014 | B2 |
| 8648724 | Forsberg et al. | Feb 2014 | B2 |
| 8651328 | Cittadinoc | Feb 2014 | B2 |
| 8668145 | Tessier | Mar 2014 | B2 |
| 8674840 | Snodgrass | Mar 2014 | B2 |
| 8698637 | Raichman | Apr 2014 | B2 |
| 8720107 | Vickery | May 2014 | B1 |
| 8776817 | Sawaski et al. | Jul 2014 | B2 |
| 8783511 | Snodgrass | Jul 2014 | B2 |
| 8786429 | Li et al. | Jul 2014 | B2 |
| 8816860 | Ophardt et al. | Aug 2014 | B2 |
| 8823525 | Cartner et al. | Sep 2014 | B2 |
| 8842406 | Tseng et al. | Sep 2014 | B2 |
| 8847752 | Wegelin et al. | Sep 2014 | B2 |
| 8872665 | Snodgrass | Oct 2014 | B2 |
| 8903416 | Perkins et al. | Dec 2014 | B1 |
| 8963721 | Harris et al. | Feb 2015 | B2 |
| 8963723 | Snodgrass | Feb 2015 | B2 |
| 8976031 | Ophardt | Mar 2015 | B2 |
| 8988228 | Iseri et al. | Mar 2015 | B2 |
| 8990098 | Swart et al. | Mar 2015 | B2 |
| 8994537 | Pokrajac | Mar 2015 | B2 |
| 8999261 | Benedetto | Apr 2015 | B2 |
| 9000930 | Pelland et al. | Apr 2015 | B2 |
| 9007209 | Ehrman et al. | Apr 2015 | B1 |
| 9007936 | Gaylard et al. | Apr 2015 | B2 |
| 9013312 | Bolling | Apr 2015 | B2 |
| 9047755 | Bonner | Jun 2015 | B2 |
| 9060655 | Iseri et al. | Jun 2015 | B2 |
| 9076044 | Dryer et al. | Jul 2015 | B2 |
| 9111435 | Gips et al. | Aug 2015 | B2 |
| 9117361 | Hennigan et al. | Aug 2015 | B1 |
| 9123233 | Hermann | Sep 2015 | B2 |
| 9159216 | Limbert et al. | Oct 2015 | B2 |
| 9218734 | Wallace et al. | Dec 2015 | B2 |
| 9235977 | Deutsch | Jan 2016 | B2 |
| 9239361 | Long | Jan 2016 | B2 |
| 9262905 | Wegelin et al. | Feb 2016 | B2 |
| 9271611 | Stratman | Mar 2016 | B2 |
| 9271612 | Miller | Mar 2016 | B2 |
| 9299238 | Ahmad et al. | Mar 2016 | B1 |
| 9311809 | Diaz | Apr 2016 | B2 |
| 9317817 | Barsky | Apr 2016 | B2 |
| 9328490 | Bayley et al. | May 2016 | B2 |
| 9349274 | Wegelin et al. | May 2016 | B2 |
| 9373242 | Conrad et al. | Jun 2016 | B1 |
| 9437103 | Ophardt | Sep 2016 | B2 |
| 9472089 | AlHazme | Oct 2016 | B2 |
| 9478118 | Keown et al. | Oct 2016 | B2 |
| 9497428 | Gaisser et al. | Nov 2016 | B2 |
| 9524480 | Christensen | Dec 2016 | B2 |
| 9524632 | Moore | Dec 2016 | B2 |
| 9526380 | Hamilton et al. | Dec 2016 | B2 |
| 9536415 | De Luca et al. | Jan 2017 | B2 |
| 9561517 | Wertheim et al. | Feb 2017 | B2 |
| 9613519 | Iseri et al. | Apr 2017 | B2 |
| 9626650 | Hwang et al. | Apr 2017 | B2 |
| 9628434 | Laidlaw et al. | Apr 2017 | B2 |
| 9633543 | Wegelin et al. | Apr 2017 | B2 |
| 9633544 | Wegelin et al. | Apr 2017 | B2 |
| 9633545 | Wegelin et al. | Apr 2017 | B2 |
| 9640059 | Hyland | May 2017 | B2 |
| 9702961 | Shields | Jul 2017 | B2 |
| 9824569 | Snodgrass | Nov 2017 | B2 |
| 9830764 | Murphy | Nov 2017 | B1 |
| 9881485 | Haidenberg | Jan 2018 | B2 |
| 9920553 | Limbert et al. | Mar 2018 | B2 |
| 10022023 | Santoro et al. | Jul 2018 | B2 |
| 10123661 | Wertheim et al. | Nov 2018 | B2 |
| 10226037 | States, III et al. | Mar 2019 | B2 |
| 10373477 | Bonner et al. | Aug 2019 | B1 |
| 10490057 | Malina et al. | Nov 2019 | B1 |
| 10529219 | Herdt et al. | Jan 2020 | B2 |
| 10665084 | Peck et al. | May 2020 | B1 |
| 10714216 | Hardman et al. | Jul 2020 | B1 |
| 10732021 | Moore | Aug 2020 | B2 |
| 10743720 | Wertheim | Aug 2020 | B2 |
| 10743721 | Wertheim | Aug 2020 | B2 |
| 10978200 | Hardman et al. | Apr 2021 | B1 |
| 11025720 | Skaaksrud | Jun 2021 | B2 |
| RE48951 | Tokhtuev et al. | Mar 2022 | E |
| 11284333 | Snodgrass | Mar 2022 | B2 |
| 20010023841 | Zimmerman et al. | Sep 2001 | A1 |
| 20010023878 | Irwin | Sep 2001 | A1 |
| 20010028308 | De La Huerga | Oct 2001 | A1 |
| 20010039501 | Crevel et al. | Nov 2001 | A1 |
| 20010047214 | Cocking et al. | Nov 2001 | A1 |
| 20010053939 | Crevel et al. | Dec 2001 | A1 |
| 20010054038 | Crevel et al. | Dec 2001 | A1 |
| 20010054626 | Bethune et al. | Dec 2001 | A1 |
| 20020000449 | Armstrong | Jan 2002 | A1 |
| 20020005414 | DeKoning et al. | Jan 2002 | A1 |
| 20020014496 | Cline et al. | Feb 2002 | A1 |
| 20020019709 | Segal | Feb 2002 | A1 |
| 20020050006 | Saraya | May 2002 | A1 |
| 20020096537 | Gardner, Jr. | Jul 2002 | A1 |
| 20020100676 | Janniere | Aug 2002 | A1 |
| 20020103671 | Pederson et al. | Aug 2002 | A1 |
| 20020107744 | Rosenberg et al. | Aug 2002 | A1 |
| 20020117187 | Helminger | Aug 2002 | A1 |
| 20020132343 | Lum | Sep 2002 | A1 |
| 20020135486 | Brohagen et al. | Sep 2002 | A1 |
| 20020145523 | Robaey | Oct 2002 | A1 |
| 20020168216 | Policicchio et al. | Nov 2002 | A1 |
| 20020175182 | Matthews | Nov 2002 | A1 |
| 20020183979 | Wildman | Dec 2002 | A1 |
| 20030030562 | Lane et al. | Feb 2003 | A1 |
| 20030033396 | McCall | Feb 2003 | A1 |
| 20030043688 | Peterson et al. | Mar 2003 | A1 |
| 20030065536 | Hansen et al. | Apr 2003 | A1 |
| 20030074222 | Rosow et al. | Apr 2003 | A1 |
| 20030109057 | DiCesare et al. | Jun 2003 | A1 |
| 20030121561 | Wagner et al. | Jul 2003 | A1 |
| 20030155035 | Ichikawa et al. | Aug 2003 | A1 |
| 20030182180 | Zarrow | Sep 2003 | A1 |
| 20040001009 | Winings et al. | Jan 2004 | A1 |
| 20040015269 | Jungmann et al. | Jan 2004 | A1 |
| 20040018839 | Andric et al. | Jan 2004 | A1 |
| 20040028608 | Saul et al. | Feb 2004 | A1 |
| 20040049369 | Konicek et al. | Mar 2004 | A1 |
| 20040075347 | Biskup et al. | Apr 2004 | A1 |
| 20040088076 | Gardner | May 2004 | A1 |
| 20040090333 | Wildman et al. | May 2004 | A1 |
| 20040148196 | Kalies | Jul 2004 | A1 |
| 20040150527 | Harper et al. | Aug 2004 | A1 |
| 20040162850 | Sanville et al. | Aug 2004 | A1 |
| 20040217197 | Mazooji et al. | Nov 2004 | A1 |
| 20040220844 | Sanville et al. | Nov 2004 | A1 |
| 20040226956 | Brooks | Nov 2004 | A1 |
| 20040226959 | Mehus et al. | Nov 2004 | A1 |
| 20040226962 | Mazursky et al. | Nov 2004 | A1 |
| 20040229959 | Reddy et al. | Nov 2004 | A1 |
| 20040230339 | Maser et al. | Nov 2004 | A1 |
| 20050065644 | Gardner, Jr. et al. | Mar 2005 | A1 |
| 20050072793 | Mehus et al. | Apr 2005 | A1 |
| 20050086341 | Enga et al. | Apr 2005 | A1 |
| 20050102167 | Kapoor | May 2005 | A1 |
| 20050134465 | Rice et al. | Jun 2005 | A1 |
| 20050134466 | Tirkel | Jun 2005 | A1 |
| 20050149341 | Eguchi et al. | Jul 2005 | A1 |
| 20050171634 | York et al. | Aug 2005 | A1 |
| 20050222889 | Lai et al. | Oct 2005 | A1 |
| 20050248461 | Lane et al. | Nov 2005 | A1 |
| 20060067545 | Lewis et al. | Mar 2006 | A1 |
| 20060067546 | Lewis et al. | Mar 2006 | A1 |
| 20060071799 | Verdiramo | Apr 2006 | A1 |
| 20060104245 | Narayanaswami et al. | May 2006 | A1 |
| 20060132316 | Wildman et al. | Jun 2006 | A1 |
| 20060139449 | Cheng et al. | Jun 2006 | A1 |
| 20060140703 | Sacks | Jun 2006 | A1 |
| 20060154642 | Scannell | Jul 2006 | A1 |
| 20060156415 | Rubinstein et al. | Jul 2006 | A1 |
| 20060191068 | Vlahos et al. | Aug 2006 | A1 |
| 20060223731 | Carling | Oct 2006 | A1 |
| 20060229821 | Brossette et al. | Oct 2006 | A1 |
| 20060240397 | Lynn et al. | Oct 2006 | A1 |
| 20060248588 | Jayaraman | Nov 2006 | A1 |
| 20060272361 | Snodgrass | Dec 2006 | A1 |
| 20060273915 | Snodgrass | Dec 2006 | A1 |
| 20060277065 | Guten et al. | Dec 2006 | A1 |
| 20070008146 | Taylor et al. | Jan 2007 | A1 |
| 20070008147 | Bolling | Jan 2007 | A1 |
| 20070008149 | Bolling | Jan 2007 | A1 |
| 20070016466 | Taylor | Jan 2007 | A1 |
| 20070020212 | Bernal et al. | Jan 2007 | A1 |
| 20070029962 | Saeki | Feb 2007 | A1 |
| 20070044819 | Chan et al. | Mar 2007 | A1 |
| 20070055483 | Lee et al. | Mar 2007 | A1 |
| 20070056091 | Bolton et al. | Mar 2007 | A1 |
| 20070069884 | Waxman | Mar 2007 | A1 |
| 20070096930 | Cardoso | May 2007 | A1 |
| 20070135866 | Baker et al. | Jun 2007 | A1 |
| 20070182581 | Elwell | Aug 2007 | A1 |
| 20070198067 | Van den Heuvel et al. | Aug 2007 | A1 |
| 20070205861 | Nair et al. | Sep 2007 | A1 |
| 20070213877 | Hart et al. | Sep 2007 | A1 |
| 20070222599 | Coveley et al. | Sep 2007 | A1 |
| 20070228065 | Anderson et al. | Oct 2007 | A1 |
| 20070229288 | Ogrin et al. | Oct 2007 | A1 |
| 20070247316 | Wildman et al. | Oct 2007 | A1 |
| 20070257803 | Munro et al. | Nov 2007 | A1 |
| 20070285277 | Scott et al. | Dec 2007 | A1 |
| 20070290865 | Lynn et al. | Dec 2007 | A1 |
| 20080001763 | Raja et al. | Jan 2008 | A1 |
| 20080019489 | Lynn | Jan 2008 | A1 |
| 20080019490 | Lynn | Jan 2008 | A1 |
| 20080046278 | Sanville et al. | Feb 2008 | A1 |
| 20080084315 | Pittz | Apr 2008 | A1 |
| 20080087719 | Sahud | Apr 2008 | A1 |
| 20080095677 | McSherry et al. | Apr 2008 | A1 |
| 20080100441 | Prodanovich et al. | May 2008 | A1 |
| 20080103636 | Glenn et al. | May 2008 | A1 |
| 20080131332 | Nguyen et al. | Jun 2008 | A1 |
| 20080136649 | Van De Hey | Jun 2008 | A1 |
| 20080177155 | Hansen et al. | Jul 2008 | A1 |
| 20080181142 | Garrett et al. | Jul 2008 | A1 |
| 20080185540 | Turner et al. | Aug 2008 | A1 |
| 20080189142 | Brown et al. | Aug 2008 | A1 |
| 20080193631 | Kanamori et al. | Aug 2008 | A1 |
| 20080246599 | Hufton et al. | Oct 2008 | A1 |
| 20080262097 | Eady et al. | Oct 2008 | A1 |
| 20080266113 | Kennish et al. | Oct 2008 | A1 |
| 20080267408 | Hsieh | Oct 2008 | A1 |
| 20080271928 | Mehus et al. | Nov 2008 | A1 |
| 20080280380 | Dietz et al. | Nov 2008 | A1 |
| 20080283145 | Maxwell | Nov 2008 | A1 |
| 20080290112 | Lynn | Nov 2008 | A1 |
| 20080303658 | Melker et al. | Dec 2008 | A1 |
| 20090002644 | Christensen et al. | Jan 2009 | A1 |
| 20090019552 | McLaughlin et al. | Jan 2009 | A1 |
| 20090030721 | Garcia et al. | Jan 2009 | A1 |
| 20090037026 | Sostaric et al. | Feb 2009 | A1 |
| 20090049610 | Heimbrock et al. | Feb 2009 | A1 |
| 20090051545 | Koblasz | Feb 2009 | A1 |
| 20090068116 | Arndt | Mar 2009 | A1 |
| 20090084407 | Glenn et al. | Apr 2009 | A1 |
| 20090090564 | Kresina | Apr 2009 | A1 |
| 20090091458 | Deutsch | Apr 2009 | A1 |
| 20090102681 | Brennan, Jr. et al. | Apr 2009 | A1 |
| 20090112360 | Berg | Apr 2009 | A1 |
| 20090112541 | Anderson et al. | Apr 2009 | A1 |
| 20090112630 | Collins, Jr. et al. | Apr 2009 | A1 |
| 20090119142 | Yenni et al. | May 2009 | A1 |
| 20090125424 | Wegelin | May 2009 | A1 |
| 20090127282 | Reynolds et al. | May 2009 | A1 |
| 20090138303 | Seshadri | May 2009 | A1 |
| 20090145925 | Wegelin | Jun 2009 | A1 |
| 20090148342 | Bromberg et al. | Jun 2009 | A1 |
| 20090166378 | Stilley | Jul 2009 | A1 |
| 20090171502 | Freidin | Jul 2009 | A1 |
| 20090195385 | Huang | Aug 2009 | A1 |
| 20090204256 | Wegelin | Aug 2009 | A1 |
| 20090219131 | Barnett et al. | Sep 2009 | A1 |
| 20090219172 | Wilbrod | Sep 2009 | A1 |
| 20090224907 | Sinha et al. | Sep 2009 | A1 |
| 20090224924 | Thorp | Sep 2009 | A1 |
| 20090266842 | Snodgrass | Oct 2009 | A1 |
| 20090267776 | Glenn et al. | Oct 2009 | A1 |
| 20090272405 | Barnhill et al. | Nov 2009 | A1 |
| 20090273477 | Barnhill | Nov 2009 | A1 |
| 20090276239 | Swart et al. | Nov 2009 | A1 |
| 20090294469 | Poulain et al. | Dec 2009 | A1 |
| 20090299787 | Barnhill | Dec 2009 | A1 |
| 20090301523 | Barnhill et al. | Dec 2009 | A1 |
| 20100074157 | Doh | Mar 2010 | A1 |
| 20100084486 | Kim | Apr 2010 | A1 |
| 20100094581 | Cagle | Apr 2010 | A1 |
| 20100097224 | Prodanovich et al. | Apr 2010 | A1 |
| 20100117823 | Wholtjen | May 2010 | A1 |
| 20100117836 | Momen et al. | May 2010 | A1 |
| 20100134296 | Hwang | Jun 2010 | A1 |
| 20100153374 | LeBlond et al. | Jun 2010 | A1 |
| 20100173581 | Dolan | Jul 2010 | A1 |
| 20100188228 | Hyland | Jul 2010 | A1 |
| 20100233020 | Klaassen et al. | Sep 2010 | A1 |
| 20100238021 | Harris | Sep 2010 | A1 |
| 20100274640 | Morey et al. | Oct 2010 | A1 |
| 20100315243 | Tokhtuev et al. | Dec 2010 | A1 |
| 20100315244 | Tokhtuev et al. | Dec 2010 | A1 |
| 20100328076 | Kyle et al. | Dec 2010 | A1 |
| 20100332022 | Wegelin et al. | Dec 2010 | A1 |
| 20110018056 | Takeuchi | Jan 2011 | A1 |
| 20110063106 | Snodgrass | Mar 2011 | A1 |
| 20110088809 | Lin | Apr 2011 | A1 |
| 20110093313 | LeBlond et al. | Apr 2011 | A1 |
| 20110291841 | Hollock et al. | Apr 2011 | A1 |
| 20110121974 | Tenarvitz et al. | May 2011 | A1 |
| 20110169645 | Cartner et al. | Jul 2011 | A1 |
| 20110169646 | Raichman | Jul 2011 | A1 |
| 20110180564 | Jones et al. | Jul 2011 | A1 |
| 20110193703 | Parton et al. | Aug 2011 | A1 |
| 20110196720 | Guten et al. | Aug 2011 | A1 |
| 20110234598 | Scarola et al. | Sep 2011 | A1 |
| 20110260872 | Kennish et al. | Oct 2011 | A1 |
| 20110273298 | Snodgrass et al. | Nov 2011 | A1 |
| 20110286326 | Awano | Nov 2011 | A1 |
| 20110296664 | Minard et al. | Dec 2011 | A1 |
| 20110316695 | Li et al. | Dec 2011 | A1 |
| 20110316701 | Alper et al. | Dec 2011 | A1 |
| 20110316703 | Butler et al. | Dec 2011 | A1 |
| 20120024890 | Ota et al. | Feb 2012 | A1 |
| 20120047988 | Mehus et al. | Mar 2012 | A1 |
| 20120062382 | Taneff | Mar 2012 | A1 |
| 20120112906 | Borke et al. | May 2012 | A1 |
| 20120112914 | Wegelin et al. | May 2012 | A1 |
| 20120168459 | D'Onofrio | Jul 2012 | A1 |
| 20120212344 | Forsberg et al. | Aug 2012 | A1 |
| 20120218106 | Zaima et al. | Aug 2012 | A1 |
| 20120245729 | Wegelin et al. | Sep 2012 | A1 |
| 20120256742 | Snodgrass et al. | Oct 2012 | A1 |
| 20120274468 | Wegelin et al. | Nov 2012 | A1 |
| 20120299731 | Triener | Nov 2012 | A1 |
| 20120310664 | Long et al. | Dec 2012 | A1 |
| 20120329438 | Snodgrass | Dec 2012 | A1 |
| 20130037569 | Kelly et al. | Feb 2013 | A1 |
| 20130045685 | Kiani | Feb 2013 | A1 |
| 20130075346 | Rumberger et al. | Mar 2013 | A1 |
| 20130076514 | Wegelin et al. | Mar 2013 | A1 |
| 20130091631 | Hayes et al. | Apr 2013 | A1 |
| 20130098941 | Wegelin | Apr 2013 | A1 |
| 20130099900 | Pulvermacher | Apr 2013 | A1 |
| 20130113931 | Alper | May 2013 | A1 |
| 20130120120 | Long et al. | May 2013 | A1 |
| 20130122807 | Tenarvitz | May 2013 | A1 |
| 20130133762 | Snodgrass | May 2013 | A1 |
| 20130224076 | Hansmann et al. | Aug 2013 | A1 |
| 20130229276 | Hunter | Sep 2013 | A1 |
| 20130234855 | Knighton | Sep 2013 | A1 |
| 20130257615 | Tseri et al. | Oct 2013 | A1 |
| 20130261795 | Long et al. | Oct 2013 | A1 |
| 20130264355 | Jodoin | Oct 2013 | A1 |
| 20130285814 | Snodgrass | Oct 2013 | A1 |
| 20130290016 | Alper et al. | Oct 2013 | A1 |
| 20130292407 | Beavis et al. | Nov 2013 | A1 |
| 20130306105 | Battah | Nov 2013 | A1 |
| 20130332184 | Burnham et al. | Dec 2013 | A1 |
| 20130333184 | Couture et al. | Dec 2013 | A1 |
| 20130342349 | Cruz | Dec 2013 | A1 |
| 20140009292 | Long et al. | Jan 2014 | A1 |
| 20140015670 | Wegelin et al. | Jan 2014 | A1 |
| 20140070950 | Snodgrass | Mar 2014 | A1 |
| 20140081653 | Davis et al. | Mar 2014 | A1 |
| 20140108039 | Rensvold et al. | Apr 2014 | A1 |
| 20140158714 | Snodgrass et al. | Jun 2014 | A1 |
| 20140180713 | Tenarvitz et al. | Jun 2014 | A1 |
| 20140210620 | Snodgrass | Jul 2014 | A1 |
| 20140214449 | Long et al. | Jul 2014 | A1 |
| 20140231455 | Jersey et al. | Aug 2014 | A1 |
| 20140242562 | McSterling et al. | Aug 2014 | A1 |
| 20140253334 | Hanlin et al. | Sep 2014 | A1 |
| 20140253336 | Ophardt | Sep 2014 | A1 |
| 20140279603 | Ortiz et al. | Sep 2014 | A1 |
| 20140311239 | Marjanovic et al. | Oct 2014 | A1 |
| 20140320289 | Raichman | Oct 2014 | A1 |
| 20140327545 | Bolling et al. | Nov 2014 | A1 |
| 20140333433 | Li et al. | Nov 2014 | A1 |
| 20140333744 | Baym et al. | Nov 2014 | A1 |
| 20140347185 | Smith et al. | Nov 2014 | A1 |
| 20140361898 | Wegelin et al. | Dec 2014 | A1 |
| 20140366264 | Ciavarella et al. | Dec 2014 | A1 |
| 20140368320 | Hyland | Dec 2014 | A1 |
| 20150022361 | Gaisser et al. | Jan 2015 | A1 |
| 20150035678 | Long | Feb 2015 | A1 |
| 20150048940 | Keown et al. | Feb 2015 | A1 |
| 20150061867 | Engelhard et al. | Mar 2015 | A1 |
| 20150070174 | Douglas | Mar 2015 | A1 |
| 20150101121 | Burgo, Sr. et al. | Apr 2015 | A1 |
| 20150127365 | Rizvi et al. | May 2015 | A1 |
| 20150134354 | Alper et al. | May 2015 | A1 |
| 20150134357 | Davis et al. | May 2015 | A1 |
| 20150170502 | Harris et al. | Jun 2015 | A1 |
| 20150179047 | Wallace et al. | Jun 2015 | A1 |
| 20150194043 | Dunn et al. | Jul 2015 | A1 |
| 20150199883 | Hartley et al. | Jul 2015 | A1 |
| 20150221208 | Knighton et al. | Aug 2015 | A1 |
| 20150278456 | Bermudez Rodriguez et al. | Oct 2015 | A1 |
| 20150308149 | Oshmyansky et al. | Oct 2015 | A1 |
| 20150313422 | Ophardt et al. | Nov 2015 | A1 |
| 20150366411 | Yang et al. | Dec 2015 | A1 |
| 20160042635 | Rosebraugh et al. | Feb 2016 | A1 |
| 20160068383 | Falco, III et al. | Mar 2016 | A1 |
| 20160093195 | Ophardt | Mar 2016 | A1 |
| 20160128520 | Wegelin et al. | May 2016 | A1 |
| 20160140830 | Hathorn | May 2016 | A1 |
| 20160152430 | Ray | Jun 2016 | A1 |
| 20160174022 | Nhu | Jun 2016 | A1 |
| 20160179089 | Stratmann | Jun 2016 | A1 |
| 20160240070 | Wegelin et al. | Aug 2016 | A1 |
| 20160247381 | Rensvold et al. | Aug 2016 | A1 |
| 20160249774 | Ophardt et al. | Sep 2016 | A1 |
| 20160267772 | Iseri et al. | Sep 2016 | A1 |
| 20160292992 | Ortiz et al. | Oct 2016 | A1 |
| 20160309967 | Pelfrey et al. | Oct 2016 | A1 |
| 20160331894 | Harmon et al. | Nov 2016 | A1 |
| 20170004287 | O'Toole | Jan 2017 | A1 |
| 20170098366 | Hood et al. | Apr 2017 | A1 |
| 20170120274 | Schultz et al. | May 2017 | A1 |
| 20170134887 | Wegelin et al. | May 2017 | A1 |
| 20170256155 | Sengstaken, Jr. et al. | Sep 2017 | A1 |
| 20170287313 | Park et al. | Oct 2017 | A1 |
| 20180024202 | Erickson et al. | Jan 2018 | A1 |
| 20180111145 | Ophardt et al. | Apr 2018 | A1 |
| 20180255981 | Rospierski | Sep 2018 | A1 |
| 20180310780 | Mahaffey et al. | Nov 2018 | A1 |
| 20190063980 | Kobs | Feb 2019 | A1 |
| 20190172336 | Haidegger et al. | Jun 2019 | A1 |
| 20190228640 | Freedman et al. | Jul 2019 | A1 |
| 20190250653 | Conlon | Aug 2019 | A1 |
| 20200094091 | Skaaksrud | Mar 2020 | A1 |
| 20200100627 | Ophardt | Apr 2020 | A1 |
| 20200173719 | Jaakkola | Jun 2020 | A1 |
| 20200193797 | Lindstrom | Jun 2020 | A1 |
| 20200193798 | Lindstrom | Jun 2020 | A1 |
| 20200205055 | Snodgrass | Jun 2020 | A1 |
| 20210012640 | Tokhtuev et al. | Jan 2021 | A1 |
| Number | Date | Country |
|---|---|---|
| 200114943 | May 2001 | AU |
| 2012360763 | Jul 2013 | AU |
| 2015202637 | Jun 2015 | AU |
| 2015258158 | Dec 2015 | AU |
| 2015275337 | Jan 2016 | AU |
| 2013378514 | Nov 2017 | AU |
| 102012030486 | Sep 2014 | BR |
| 2605412 | Dec 2006 | CA |
| 2592814 | Dec 2007 | CA |
| 2674654 | Oct 2009 | CA |
| 2776280 | Nov 2013 | CA |
| 2780411 | Dec 2013 | CA |
| 2807337 | Aug 2014 | CA |
| 2914864 | Jun 2016 | CA |
| 2354482 | Dec 1999 | CN |
| 1181415 | Dec 2004 | CN |
| 1938724 | Mar 2007 | CN |
| 100340935 | Oct 2007 | CN |
| 101592510 | Dec 2009 | CN |
| 201974318 | Sep 2011 | CN |
| 202677403 | Jan 2013 | CN |
| 103169409 | Jun 2013 | CN |
| 103198628 | Jul 2013 | CN |
| 203153706 | Aug 2013 | CN |
| 203325033 | Dec 2013 | CN |
| 103617349 | Mar 2014 | CN |
| 204218783 | Mar 2015 | CN |
| 104615091 | May 2015 | CN |
| 104622348 | May 2015 | CN |
| 204520455 | Aug 2015 | CN |
| 105139320 | Dec 2015 | CN |
| 105164737 | Dec 2015 | CN |
| 204990347 | Jan 2016 | CN |
| 101911108 | Feb 2016 | CN |
| 205197874 | May 2016 | CN |
| 106154902 | Nov 2016 | CN |
| 69917795 | Jan 2000 | DE |
| 69708606 | Aug 2002 | DE |
| 10157975 | Jun 2003 | DE |
| 69917795 | Jul 2005 | DE |
| 19882120 | Oct 2010 | DE |
| 102012105365 | Dec 2013 | DE |
| 2015665 | Nov 2009 | DK |
| 0921506 | Jun 1999 | EP |
| 0927535 | Jul 1999 | EP |
| 0940110 | Sep 1999 | EP |
| 1121500 | Oct 1999 | EP |
| 250917 | Jan 2000 | EP |
| 26374540 | Jan 2000 | EP |
| 1245016 | Oct 2000 | EP |
| 1049998 | Nov 2000 | EP |
| 1099400 | May 2001 | EP |
| 1201172 | May 2002 | EP |
| 1390204 | Dec 2004 | EP |
| 1034132 | Aug 2005 | EP |
| 1483728 | Oct 2006 | EP |
| 1791077 | May 2007 | EP |
| 1794727 | Jun 2007 | EP |
| 1872802 | Jan 2008 | EP |
| 1872892 | Jan 2008 | EP |
| 1913892 | Apr 2008 | EP |
| 1978703 | Oct 2008 | EP |
| 2012277 | Jan 2009 | EP |
| 2223642 | Sep 2010 | EP |
| 2511889 | Oct 2010 | EP |
| 2509017 | Oct 2012 | EP |
| 26374540 | Sep 2013 | EP |
| 2860716 | Apr 2015 | EP |
| 2956918 | Dec 2015 | EP |
| 3581897 | Sep 2020 | EP |
| 2872315 | Dec 2005 | FR |
| 2997779 | May 2014 | FR |
| 2052251 | Jan 1981 | GB |
| 2137749 | Oct 1984 | GB |
| 2217013 | Oct 1989 | GB |
| 2299405 | Feb 1996 | GB |
| 2298851 | Sep 1996 | GB |
| 2324397 | Oct 1998 | GB |
| 2337327 | Nov 1999 | GB |
| 2340647 | Feb 2000 | GB |
| 2394654 | May 2004 | GB |
| 2417810 | Mar 2006 | GB |
| 2417811 | Mar 2006 | GB |
| 2425388 | Oct 2006 | GB |
| 2446871 | Aug 2007 | GB |
| 2436793 | Oct 2007 | GB |
| 2437555 | Oct 2007 | GB |
| 2439306 | Dec 2007 | GB |
| 2439457 | Dec 2007 | GB |
| 2452189 | Feb 2009 | GB |
| 2457930 | Sep 2009 | GB |
| 2458118 | Sep 2009 | GB |
| 2469482 | Oct 2010 | GB |
| 2474317 | Apr 2011 | GB |
| 2486767 | Jun 2012 | GB |
| 2537179 | Oct 2016 | GB |
| 06226068 | Aug 1994 | JP |
| 09066995 | Mar 1997 | JP |
| 09066999 | Mar 1997 | JP |
| 10309540 | Nov 1998 | JP |
| 11332961 | Dec 1999 | JP |
| 2001292918 | Oct 2001 | JP |
| 3281375 | May 2002 | JP |
| 2002197559 | Jul 2002 | JP |
| 2003105819 | Apr 2003 | JP |
| 2003122823 | Apr 2003 | JP |
| 2006132277 | May 2005 | JP |
| 2005218999 | Aug 2005 | JP |
| 2006198318 | Aug 2006 | JP |
| 2008027436 | Feb 2008 | JP |
| 2009282442 | Dec 2009 | JP |
| 4523219 | Aug 2010 | JP |
| 2013017631 | Jan 2013 | JP |
| 2013180046 | Sep 2013 | JP |
| 2013187557 | Sep 2013 | JP |
| 2015153084 | Aug 2015 | JP |
| 2015230207 | Dec 2015 | JP |
| 2016520883 | Jul 2016 | JP |
| 101632716 | Jun 2016 | KR |
| 101647831 | Aug 2016 | KR |
| 2012015244 | Apr 2013 | MX |
| 01219439 | Sep 1989 | PH |
| 882280 | May 2002 | PT |
| 186323 | Jan 2013 | SG |
| 503189 | Jun 2015 | TW |
| 199213327 | Aug 1992 | WO |
| 199731350 | Aug 1997 | WO |
| 199809261 | Mar 1998 | WO |
| 199826704 | Jun 1998 | WO |
| 1998036258 | Aug 1998 | WO |
| 199930299 | Jun 1999 | WO |
| 199933008 | Jul 1999 | WO |
| 2002094073 | Jan 2000 | WO |
| 200022260 | Apr 2000 | WO |
| 200125730 | Apr 2001 | WO |
| 200131532 | May 2001 | WO |
| 2001033529 | May 2001 | WO |
| 200141612 | Jun 2001 | WO |
| 2002021475 | Mar 2002 | WO |
| 2002059701 | Aug 2002 | WO |
| 2002077927 | Oct 2002 | WO |
| 2002094073 | Nov 2002 | WO |
| 2003059143 | Jul 2003 | WO |
| 2003079278 | Sep 2003 | WO |
| 2003082351 | Oct 2003 | WO |
| 2004052162 | Jun 2004 | WO |
| 2004101122 | Nov 2004 | WO |
| 2005040984 | May 2005 | WO |
| 2005055793 | Jun 2005 | WO |
| 2005055793 | Jun 2005 | WO |
| 2005094711 | Oct 2005 | WO |
| 2005117672 | Dec 2005 | WO |
| 2006036687 | Apr 2006 | WO |
| 2006133026 | Dec 2006 | WO |
| 2006135922 | Dec 2006 | WO |
| 2007001866 | Jan 2007 | WO |
| 2007090470 | Aug 2007 | WO |
| 2007127495 | Nov 2007 | WO |
| 2007129289 | Nov 2007 | WO |
| 2007133960 | Nov 2007 | WO |
| 2008088424 | Jul 2008 | WO |
| 2008118143 | Oct 2008 | WO |
| 2008119158 | Oct 2008 | WO |
| 2008133495 | Nov 2008 | WO |
| 2009087046 | Jul 2009 | WO |
| 2009097096 | Aug 2009 | WO |
| 2009134242 | Nov 2009 | WO |
| 2010026581 | Mar 2010 | WO |
| 2010101929 | Sep 2010 | WO |
| 2011038173 | Mar 2011 | WO |
| 2011085292 | Jul 2011 | WO |
| 2011131800 | Oct 2011 | WO |
| 2011161475 | Dec 2011 | WO |
| 2012064515 | May 2012 | WO |
| 2012150563 | Nov 2012 | WO |
| 2012152495 | Nov 2012 | WO |
| 2012161766 | Nov 2012 | WO |
| 2013003661 | Jan 2013 | WO |
| 2013025889 | Feb 2013 | WO |
| 2013025956 | Feb 2013 | WO |
| 2013033243 | Mar 2013 | WO |
| 2013049357 | Apr 2013 | WO |
| 2013049462 | Apr 2013 | WO |
| 2013055616 | Apr 2013 | WO |
| 2013058821 | Apr 2013 | WO |
| 2013063690 | May 2013 | WO |
| 2013070888 | May 2013 | WO |
| 2013074660 | May 2013 | WO |
| 2013140253 | Sep 2013 | WO |
| 2013165585 | Nov 2013 | WO |
| 2013190016 | Dec 2013 | WO |
| 2014027030 | Feb 2014 | WO |
| 2014035610 | Mar 2014 | WO |
| 2014037938 | Mar 2014 | WO |
| 2014046645 | Mar 2014 | WO |
| 2014060726 | Apr 2014 | WO |
| 2012125320 | Aug 2014 | WO |
| 2014125320 | Aug 2014 | WO |
| 2014205283 | Dec 2014 | WO |
| 2015017702 | Feb 2015 | WO |
| 2015054193 | Apr 2015 | WO |
| 2015061718 | Apr 2015 | WO |
| 2015070016 | May 2015 | WO |
| 2016168082 | Oct 2016 | WO |
| 2017200965 | Nov 2017 | WO |
| 2018165107 | Sep 2018 | WO |
| Entry |
|---|
| US 8,157,027 B1, 04/2012, Baker (withdrawn) |
| “3M and Patient Care Technology Systems Collaborate on State of-the-Art Automated Hand Hygiene Solution to Improve Compliance,” retrieved from http://news.3m.com/pt/press-release/company/3m-and- D i patient-care-technology, on Apr. 13, 2017, 2 pp. |
| “America's Dirty Little Secret: Second Handwashing Survey Reveals Americans Still Don't Get It,” American Society for Microbiology, Sep. 19, 2000, 3 pp. |
| “ARC-T Network Protocol for the CompassNet Wireless IoT Network,” Ecolab Healthcare Division, Jan. 14, 2017, 36 pp. |
| “Bentley WiNET Tag User Guide—FAS1503, DOC1036,” UltraClenz, Jan. 25, 2011, 12 pp. |
| “Don't Get Caught Dirty Handed,” ASM's Microbes Afterhours, Sep. 6, 2009, 11 pp. |
| “Dr. Semmelweiss Was Right: Washing Hands Prevents Infection,” Water Quality and Health Council, retrieved from www.waterandhealth.org/newsletter/new/4/12/20I7/right.him, Feb. 2017,2 pp. |
| “Evidence of hand hygiene to reduce transmission and infections by multi-drug resistant organisms in health-care settings,” World Health Organization, Jan. 5, 2014, 7 pp. |
| “Hand Washing, Cleaning, Disinfection and Sterilization in Health Care,” Infection Control Guidelines, Canada Communicable Disease Report., vol. 24S8, Dec. 1998, 66 pp. |
| “Home Routines App for iPhone, iPad, & iPod touch,” retrieved from the internet http://www.homeroutines.com/, (Applicant points out, in accordance with MPEP 609.C14(a), that the year of publication, 2010, is sufliciently earlier than the effective U.S. filing date, 2017, so that the particular month of publication is not in issue.) 7 pp. |
| “Home Routines for iPhone, iPod touch, and iPad on the iTunes App Store,” retrieved from the internet https:/litunes.apple.com/us/app/homeroutines/id353117370?mt=8, Sep. 5, 2013, 3 pp. |
| “Measuring Hand Hygiene Adherence: Overcoming the Challenges,” The Joint Commission et al., 2009 (Applicant points out, in accordance with MPEP 609.04(a), that the year of publication, 2009, is sufficiently earlier than the effective U.S filing date, 2017, so that the particular month of publication is not in issue.) 234 pp. |
| “Patient Safeguard System Healthcare Worker Badge User's Guide,” DOC1046 Revision 8, UltraClenz, Mar. 14, 2012, 21 pp. |
| “ProGiene System Description for ULand CE Mark Approval,” UltraClenz, Feb. 8, 2002, 5 pp. |
| “WHO Guidelines on Hand Hygiene in Health Care (Advanced Draft),” World Health Organization, Apr. 2006, 216 pp. |
| “WHO Guidelines on Hand Hygiene in Health Care,” World Health Organization, 2009 (Applicant points out, in accordance with MPEP 609.04(a), that the year of publication, 2009, is sufficiently earlier than the eflective U.S. filing date, 2017, so that the particular month of publication is not in issue.) 270 pp. |
| Home Routines for iPhone, iPod touch, and iPad on the iTunes App Store, retrieved from Ihe internet D https:/litunes.apple.com/us/app/homeroutines/id353117370?mt=8, Sep. 5, 2013 3 pp. |
| Al-Hamad et al., “How Clean is Clean? Proposed Methods for Hospital Cleaning Assessment,” Journal of Hospital Infection, vol. 70, Oct. 9, 2008, pp. 328-334. |
| Amendment in Response to Office Action dated Apr. 22, 2021, from U.S. Appl. No. 16/723,234, filed Jul. 22, 2021, 14 pp. |
| Amendment in Response to Office Action dated Nov. 3, 2020, from U.S. Appl. No. 14/819,349, filed Apr. 26, 2021, 11 pp. |
| Anonymous et al., “Hand Hygiene,” Progressive Grocer, vol. 76, No. 8, Aug. 1997, pp. 111-112. |
| Bourn, Auditor General for Wales, “The Management and Delivery of Hospital Cleaning Services in Wales,” National Audit Office Wales, 39 pp., May 23, 2003. |
| Corrected Notice of Allowability from U.S. Appl. No. 16/723,234, dated Feb. 9, 2022, 2 pp. |
| Corrected Notice of Allowability from U.S. Appl. No. 16/723,234, dated Oct. 15, 2021, 2 pp. |
| Dancer, “How do we Assess Hospital Cleaning? A Proposal for Microbiological Standards for Surface Hygiene in Hospitals” Journal of Hospital Infection, vol. 56, Sep. 2003, pp. 10-15. |
| Diller et al., “Estimation of hand hygiene opportunities on an adult medical ward using 24-hour camera surveillance: Validation of the HOW2 Benchmark Study,” American Journal of Infection Control, vol. 42, 2014 (Applicant points out, in accordance with MPEP 609.04(a), that the year of publication, 2014, is sufficiently earlier than the effective U.S. filing date, 2017, so that the particular month of publication is not in issue.) pp. 602-607. |
| Diversey, “iMAP Internet Mobile Auditing Platform,” Diversey Inc., 2012, (Applicant points out, in accordance with MPEP 609.04(a), that the year of publication, 2012, is sufficiently earlier than the effective U.S. filing date, so that the particular month of publication is not in issue.) 2 pp. |
| Diversey, “iMAP TM/MC . . . Data Collection & Reporting Platform,” Diversey Inc., Sep. 5, 2013, 2 pp. |
| Diversey, “Reporting,” downloaded from Diversey.com, Sep. 5, 2013, 1 pp. |
| Diversey, “Sealed Air's Diversey Business Introduces Mobile Application to Capture Facility Auditing Data,” Diversey Inc., Oct. 18, 2011, 2 pp. |
| Diversey, “Unleash Your Data, The power of iMAP is now available on virtually any smart device. Get robust data collection and analysis anytime, anywhere, in any language,” Diversey Inc., Sep. 15, 2011, 2 pp. |
| Diversey, Diverlog-L Enhanced “DLE—Production Summary Reports,” Apr. 1990, 5 pp. |
| Diversey, Diverlog-L Enhanced “DLE—Single Cycle Reports,” Mar. 1990, 5 pp. |
| Diversey, Inc., “Diversey VeriCieanTM System Implementation and Support Guide,” 2012, (Applicant points out, in accordance with MPEP 609.04(a), that the year of publication, 2012, is sufficiently earlier than the effective U.S. filing date, so that the particular month of publication is not in issue.) 64 pp. |
| Dix et al., “Environmental Surface Cleaning: First Defense Against Infectious Agents,” Infection Control Today Magazine, 6 pp., Dec. 1, 2005. |
| Ecolab, Inc., product brochure: “We'd like to make a couple of things perfectly CLEAR,” 1998 (Applicant points out, in accordance vvilh MPEP 609.04(a), that the year of publication, 1998, is sufficiently earlier than the effective U.S. filing date, so that the particular month of publication is not in issue), 4 pp. |
| Ecolab® balancer.com, MRE, Jun. 4, 1997, 4 pp. |
| Elliott, “Determining Three Metrics for Cleaning Satisfaction,” found at equipmentrentaltools/article/Determining-Three-Metrics-for-Cleaning-Satisfaction-- 7698#, Nov. 2007, 2 pp. |
| Evaluating Municipal Services: Scorecard Cleanliness Program Prospectus, New York, found at http://www.worldsweeper.com/Street/Profiles/NYCScorecard.pdf, archived Jan. 5, 2009, 16 pp. |
| Exner et al., “Household Cleaning and Surface Disinfection: New Insights and Strategies,” Journal of Hospital Infection, vol. 56, 2008 (Applicant points out, in accordance with MPEP 609.04(a), that the year of publication, 2008, is sufficiently earlier than the effective U.S. filing date, so that the particular month of publication is not in issue.), pp. s70-s75. |
| Final Office Action from U.S. Appl. No. 14/819,349, dated Jun. 8, 2021, 7 pp. |
| Final Office Action from U.S. Appl. No. 14/819,349, dated Jun. 16, 2020, 31 pp. |
| Florida Department of Health, “Guidelines for Control of Antibiotic Resistant Organisms,” Dec. 20, 1999, 34 pp. |
| Garner et al., “Guidelines for Handwashing and Hospital Environmental Control,” CDC Prevention Guidelines, Jan. 1, 1985, 10 pp. |
| Garner, “Guidelines for Isolation Precautions in Hospitals,” Hospital Infection Control Advisory Committee, Jan. 1, 1996, 39 pp. |
| Green, “Hand hygiene in 2015: 7 Findings,” retrieved from http:/www.beckershospitalreview.com/quality!hand-hygiene-1 n-2015-7-findings.html?tmpl=component&print″=1&layout′″default&page=″, Nov. 12, 2015, 1 pp. |
| Griffith et al., “An Evaluation of Hospital Cleaning Regimes and Standards,” J. Hosp. Infect., vol. 45, pp. 19-28, 2000, accepted Dec. 23, 1999. |
| Griffith et al., “The Effectiveness of Existing and Modified Cleaning Regimens in a Welsh Hospital,” Journal of Hospital Infection, vol. 66, Jul. 26, 2007, pp. 352-359. |
| Grjffith, “Nosocomial infection: Are there lessons from the food industry?” The Biomedical Scientist, pp. 697-699, Aug. 2006. |
| Hamilton et al., “Hand Hygiene,” Wild Iris Medical Education, Inc., 2014, (Applicant points out, in accordance with MPEP 609.04(a), that the year of publication, 2014, is sufficiently earlier than the effective U.S. filing date, 2017, so that the particular month of publication is not in issue.) 24 pp. |
| Hicpac, “Recommendations for Preventing the Spread of Vancomycin Resistance,” Morbidity and CDC Mortality Weekly Report, Recommendations and Reports, vol. 44, No. RR-12, 1-13, Sep. 22, 1995, 16 pp. |
| International Preliminary Report on Patentability from International Application No. PCT/US2019/067983, dated Jul. 1, 2021, 9 pp. |
| International Search Report and Written Opinion of International Application No. PCT/US2019/067983, dated Mar. 20, 2020, 13 pp. |
| Johnson et al., “Dynamic Source Routing in Ad Hoc Wireless Networks,” Mobile Computing, vol. 353, 1996 (Applicant points out, in accordance with MPEP 609.04(a), that the year of publication, 1996, is sufficiently earlier than the effective U.S. filing date, so that the particular month of publication is not in issue.), 18 pp. |
| Larson et al., “A Multifaceted Approach to Changing Handwashing Behavior,” American Journal of Infection Control, vol. 25, Feb. 1997, pp. 3-10. |
| Larson, “APIC Guidelines for Hand Washing and Hand Antisepsis in Health-Care Settings,” APIC Guidelines Committee, Aug. 1995, Am J Infect Control, 23:251, 18 pp. |
| Levchenko et al., “Embedded System for Hygiene Compliance Monitoring,” IEEE Transactions on Automation Science and Engineering, vol. 7, No. 3, Jul. 2010, 4 pp. |
| Lewis et al., “A Modified ATP Benchmark for Evaluating the Cleaning of Some Hospital Environmental Surfaces,” Journal of Hospital Infection, vol. 69, May 12, 2008, pp. 156-163. |
| Malik et al., “Use of Audit Tools to Evaluate the Efficacy of Cleaning Systems in Hospitals,” Am. J. Infect. D Control, vol. 31, No. 3, p. 181-187, May 2003. |
| Mallow General Hospital, “Hygiene Services Assessment Scheme, Assessment Report,” 38 pp., Oct. 2007. |
| Mangram et al. “Guidelines for Prevention of Surgical Site Infection, 1999,” Infection Control and Hospital Epidemiology, vol. 20, No. 4, Apr. 1999, pp. 247-278. |
| Meengs et al., “Hand Washing Frequency in an Emergency Department,” Annals of Emergency Medicine, vol. 23, No. 6, Jun. 1994, pp. 1307-1312. |
| Mills et al., “Guidelines for Working with Rodents Potentially Infected with Hantavirus,” Journal of Mammalogy, vol. 76, No. 3, Aug. 1995, pp. 716-722. |
| Munro et al., “Treating Exposure to Chemical Warfare Agents: Implications for Health Care Providers and Community Emergency Planning,” Environmental Health Perspectives, vol. 89, Nov. 1990, pp. 205-215. |
| Net/Tech to Unveil Patented Hygiene Guard Hand-Washing Monitoring System at the National Restaurant Show, BusinessWire, Apr. 3, 1997, 3 pp. |
| Nexgen Si, Inc., “InTouch Water Treatment Information Management Solution,” Mar. 29, 1999, 59 pp. |
| NOV ALINK™ brochure: “Laundry Information System: Overview Reports,” Dec. 13, 1995, 6 pp. |
| NOV ALINK™ OverViewTM Program Pricing, cited in an IDS in U.S. Appl. No. 10/436,454 filed May. |
| Nova Controls, “ORION Liquid Laundry Supply Dispenser,” Feb. 1989, 5 pp. |
| Nova Controls, Nova News, “Save Money and Gain Sales Features?” Aug. 12, 1992, 1 pg. |
| NOVALINK OverView Program Pricing, cited in an IDS in U.S, U.S. Appl. No. 10/436,454, filed May 20, 2005, 1 pg. |
| NOVALINK™ Laundry Information System, Control Master Version 2.0 for Windows User's Guide, 2000 (Applicant points out, in accordance with MPEP 609.04(a), that the year of publication, 2000, is sufficiently earlier than the effective U.S. filing date, so that the particular month of publication is not in issue.) 39 pp. |
| Ophardt, Hygiene-Technik GmbH+ Co. KG, “Making The World A More Hygienic Place”, Hygiene Compliance Solutions, 2009, (Applicant points out, in accordance with MPEP 609.04(a), that the year of publication, 2009, is sufficiently earlier than the effective U.S. filing date, so that the particular month of publication is not in issue.) 1 page. |
| Persyst Inc., “Dial-A-Wash Automatic Laundry Room Attendant for Apartment And Complex Laundry D Rooms,” cited in an IDS in U.S. Appl. No. 10/436,454, filed May 20, 2005, 2 pp. |
| Persyst Inc., “LDAS-2000 Remote Information Control and Management System for the Commercial Laundry And Vending Industry,” cited in an IDS in U.S. Appl. No. 10/436,454, filed May 20, 2005, 4 pp. |
| PowerPoint Presentation: “ECOLAB Aramark Unifoml Services Joining Forces for Service Excellence,” 1998 (Applicant points out, in accordance with MPEP 609.04(a), that the year of publication, 1998, is sufficiently earlier than the effective U. S. filing date, so that the particular month of publication is not in issue) 69 pp. |
| Prosecution History from U.S. Appl. No. 14/819,349, dated Apr. 5, 2019 through Nov. 1, 2021, 232 pp. |
| Prosecution History from U.S. Appl. No. 16/723,234, dated Feb. 18, 2020 through Feb. 9, 2022, 50 pp. |
| Prosecution History from U.S. Appl. No. 17/000,625, dated Apr. 12, 2021 through Nov. 15, 2021, 12 pp. |
| Prosecution History from U.S. Appl. No. 12/787,064, dated Dec. 6, 2012 through Apr. 8, 2013, 20 pp. |
| Ptttet et al., “Compliance with Handwashing in a Teaching Hospital,” Annals of internal Medicine, vol. 130, No. 2, Jan. 19, 1999, pp. 126-130. |
| Quattrin, MD. et al., “Application of Hazard Analysis Critical Control Points to Control Surgical Site Infections in Hip and Knee Arthroplasty,” Orthopedics 31:132, 6 pp, 2008, (Applicant points out in accordance with MPEP 609 .04(a), that the year of publication, 2008, is sufficiently earlier than the effective U.S. filing date, so that the particular month of publication is not in issue.). |
| Response to Communication Pursuant to Rules 161(1) and 162 EPC dated Jul. 27, 2021, from counterpart European Application No. 19839755.6, filed Jan. 24, 2022, 21 pp. |
| SaferCorp, LLC, “SaferCorp Life Advantage Solutions presents Safer Hands Hospital Automated Hand Hygiene Monitoring System,” retrieved electronically from http://www.guardianics.com/ on Dec. 15, 2010, 14 pp. |
| SaferCorp, LLC, Guardian Automated Infection Control Systems (GAICS), Feb. 6, 2010, 4 pp. |
| Sahud et al., “An Electronic Hand Hygiene Surveillance Device: A Pilot Study Exploring Surrogate Makers for Hand Hygiene Compliance,” Infection Control and Hospital Epidemiology, vol. 31, No. 6, Jun. 2010, 6 pp. |
| Sample Reports, NOV ALINK™ System, Jan. 1996, 9 pp. |
| Sample Reports, Nova Controls, Oct. 1997, 8 pp. |
| Sax et al., “My five moments for hand hygiene: a user-centered design approach to understand, train, monitor and report hand hvgiene,” Journal of Hospital Infection, vol. 67, Aug. 27, 2007, pp. 9-21. |
| Semmelweis, “The Etiology, Concept, and Prophylaxis of Childbed Fever,” The University of Wisconsin Press, Sep. 15, 1983, pp. 46-59. |
| Steed et al “Hospital Hand Hygiene Opportunities: Were and When (HOW2)? The HOW2 Benchmark Study,” American Journal of Infection Control, vol. 39, Feb. 2011, 8 pp. |
| Sturman et al., “Cornell University Hospitality Report: A New Method for Measuring Housekeeping Performance Consistency,” CHR Reports, vol. 6, No. 11, Sep. 2006, 15 pp. |
| Swedberg, “RFID-based Hand-Hygiene System Prevents Health-Care Acquired Infections,” RFID. |
| Swedberg, “RFID-based Hand-Hygiene System Prevents Health-Care Acquired Infections,” RFID Journal, Jun. 10, 2010, 2 pp. |
| Swoboda et al., “Electronic Monitoring and Voice Prompts Improve Hand Hygiene and Decrease Nosocomial Infections in an Intermediate Care Unit,” Crit Care Med, vol. 32, No. 2, Feb. 2004, pp. 358-363. |
| T-JET™ 2000 PC, Wash-Aisle Productivity Manager Software Guide, ECOLAB® Textile Care Division, cited in an IDS in U.S. Appl. No. 10/436,454, filed May 20, 2005, 29 pp. |
| Taylor, “An Evaluation of Handwashing Techniques—I”, Nursing Times, vol. 74, Jan. 12, 1978, pp. 54-55. |
| Thompson et al., “Handwashing and Glove Use in a Long-Term1-Care Facility,” Infection Control and Hospital Epidemiology, vol. 18, No. 2, Feb. 1997, pp. 97-103. |
| Tibballs et al., “Teaching Hospital Medical Staff to Handwash,” The Medical Journal of Australia, vol. 164, No. 7, Apr. 1, 1996, pp. 395-398. |
| Tsai et al., “iMAT: Intelligent Medication Administration Tools,” Aug. 2010, 8 pp. |
| U.S. Appl. No. 17/383,689, filed Jul. 23, 2021, by Tokhtuev et al. |
| U.S. Appl. No. 14/819,349, filed Aug. 5, 2015, by Tokhtuev et al. |
| Van Ryzin et al., “Measuring Street Cleanliness: A Comparison of New York City's Scorecard and Results from a Citizen Survey,” Public Administration Review 68(2), Mar./Apr. 2008, pp. 295-303. |
| Watanakunakorn et al., “An Observational Study ofHand Washing and Infection Control Practices by Healhcare Workers,” Infection Control and Hospital Epidemiolgy, vol. 19, No. 11, Nov. 1998, pp. |
| Yoshikura, “Workflow from Clean to Dirty, HACCP and Inclusiveness Principles in Effective Implementation of Hospital Infection Control,” Jpn. J. Infect. Dis. 53, Jun. 6, 2000, 2 pp. |
| Zuhlsdorf et al., “Cleanmg Efficacy of Nine Different Cleaners in a Washer-Disinfector Designed for Flexible Endoscopes,” Journal of Hospital Infection, vol. 52, Oct. 9, 2002, pp. 206-211. |
| Office Action from U.S. Appl. No. 17/383,689 dated Oct. 5, 2022, 29 pp. |
| Response to Office Action dated Aug. 31, 2022, from counterpart Canadian Application No. 3,123,862 filed Nov. 7, 2022, 22 pp. |
| Office Action from counterpart Canadian Application No. 3,123,862 dated Aug. 31, 2022, 4 pp. |
| Response to Office Action dated Oct. 5, 2022 from U.S. Appl. No. 17/383,689, filed Feb. 6, 2023, 24 pp. |
| Final Office Action from U.S. Appl. No. 17/383,689 dated Mar. 7, 2023, 40 pp. |
| Office Action from counterpart Canadian Application No. 3,123,862 dated Mar. 7, 2023, 4 pp. |
| Number | Date | Country | |
|---|---|---|---|
| 20220201590 A1 | Jun 2022 | US |
| Number | Date | Country | |
|---|---|---|---|
| 62782991 | Dec 2018 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 16723234 | Dec 2019 | US |
| Child | 17654324 | US |
