Patent Grant
10911368
The present technology pertains to telecommunications networks and more specifically to utilizing alternative telecommunications networks.
The approaches described in this section could be pursued but are not necessarily approaches that have previously been conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.
Communications networks can include a collection of nodes where transmission links are connected so as to enable communication between the nodes. The transmission links connect the nodes together. The nodes use circuit switching, message switching, or packet switching to pass the signal through the correct links and nodes to reach the correct destination terminal. Each node in the network usually has a unique address so messages or connections can be routed to the correct recipients. The collection of addresses in the network is called the address space.
This summary is provided to introduce a selection of concepts in a simplified form that are further described in the Detailed Description below. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.
The present disclosure is related to various systems and methods for alternate network utilization. Specifically, a method may comprise: broadcasting by a hub an unsolicited announcement over a network to a plurality of devices coupled to a router, the unsolicited announcement being configured to cause at least some of the plurality of devices to store in a table a link-layer address of the hub as a link-layer address of the router. Some embodiments may further include: receiving by the hub a data packet from a device of the plurality of devices; and selectively directing by the hub the received packet to a first broadband network or a second broadband network using predetermined criteria.
Embodiments are illustrated by way of example, and not by limitation, in the figures of the accompanying drawings, in which like references indicate similar elements and in which:
While this technology is susceptible of embodiment in many different forms, there is shown in the drawings and will herein be described in detail several specific embodiments with the understanding that the present disclosure is to be considered as an exemplification of the principles of the technology and is not intended to limit the technology to the embodiments illustrated. The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the technology. As used herein, the singular forms “a,” “an,” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises,” “comprising,” “includes,” and/or “including,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. It will be understood that like or analogous elements and/or components, referred to herein, may be identified throughout the drawings with like reference characters. It will be further understood that several of the figures are merely schematic representations of the present technology. As such, some of the components may have been distorted from their actual scale for pictorial clarity.
IP Network Local and Gateway Routing
In various embodiments, applications can use Internet Protocol (IP) addresses to identify other hosts of Hosts 110 and communicate with them. For example, users of an application may identify a destination either by a host name (10.example.com) or an IP address (192.168.1.1).
By way of illustration, when an application on host A (not shown in
Because the message is broadcast over Switch 120, any other Hosts 110 connected to the switch will also see the request from host A to identify which host is associated with host B's IP address. In the ARP protocol, any mappings seen (in this case, the mapping of host B's IP address to host B's MAC address) are remembered (stored) and replace any older mappings. Therefore, after the exchange described above, not only does host A know that host B's MAC address corresponds to host B's IP address, all other of Hosts 110 connected to Switch 120 know this as well. ARP table entries have a time to live, eventually expiring.
This process can be used to deliver packets to other Hosts 110 on the local network. That is, to other machines connected to Switch 120. Generally, at the IP level hosts that are on a common local network (connected to the same switch) have similar IP addresses. The space or range of valid IP addresses within the local network is referred to as a subnet. All hosts on the subnet (local network) can have an IP address within the range of the subnet. Hosts are each issued an IP address and a network mask, either when configured or at the time they boot, for example, using a protocol called Dynamic Host Configuration Protocol (DHCP). The combination of an IP address and netmask allows each host to identify the range of local network addresses (e.g., hosts on the local subnet). Given a destination IP address, a host may easily then determine if the destination address is on the same subnet and thus can be reached locally using the mechanism just described.
If the destination address is determined to not be within the local subnet, the messages cannot be delivered using the mechanism described earlier only. Instead, the packets can be delivered out of the local network, to the broader network (e.g., the Internet), where higher level protocols (the IP protocol) can deliver the packet to the destination.
Referring again to
The packet can then be delivered over the broader Network 140 after being delivered there by Gateway 150. The IP address of Remote Destination 130 is used to eventually deliver the packet to the local network where Remote Destination is located. Link-level addresses are again used between various devices in the Network (at each hop) to deliver the packet, and used by the gateway (not depicted in
DNS
Applications, particularly those interacting with human users, often do not directly use IP addresses, as they are difficult for humans to remember. Instead, users can provide the destination in the form of a hostname or URL containing a hostname. The hostname (or hostname portion of the URL) can be resolved or translated into an IP address at the time the device (host) wishes to connect. This name resolution is typically performed, for example, using the IETF's Domain Name System (DNS) protocol [DNS], in which a server called a name (or DNS) server (not shown in
For example, the name server is sent the hostname of the host, and returns the IP address (or an error if the name cannot be located) corresponding to the host. This IP address can then be used to request a MAC address corresponding to the host using ARP (for local addresses) or to forward a message to Remote Destination 130 via Gateway 150. The process of translating a human-readable hostname to an IP address is referred to as resolving the address.
DHCP
As mentioned earlier, Hosts 110 on the network may be preconfigured with the important network information needed to enable IP connectivity (e.g., IP address, netmask, gateway IP address, DNS server IP address, and the like), or may use the IETF's Dynamic Host Configuration Protocol (DHCP). An example, using IPv4, is as follows. Another example, using IPv6, can work in an analogous manner, with some differences. These differences are not described here for brevity.
When a host (of Hosts 110) using DHCP connects to a new network (e.g., to a network for the first time), it attempts to obtain an address for itself and other network parameters by sending a DHCP DISCOVER message to the IP address 255.255.255.255, which is delivered to all the other hosts (of Hosts 110) on the local subnet. The goal is to locate a DHCP server, which can service the request for an IP address and supporting information.
In response, one or more hosts (of Hosts 110), which can act as DHCP servers operating on the network, may offer a lease of an IP address to be used for a predefined period of time. If there are multiple DHCP servers, more than one may offer up an IP address to be used in a DHCP OFFER.
The above exchange provides the host (of Hosts 110) with other information needed along with the IP address, for example netmask, gateway, and DNS server addresses. For example, in a home network the DHCP server can be incorporated in the router and/or Wi-Fi access point (e.g., incorporated with a cable, Digital Subscriber Line (DSL), and the like modem).
ARP Poisoning/Spoofing
The mechanism of using ARP to broadcast a request for the host that is associated with a particular IP address leads to a class of security “attack” called ARP poisoning or ARP spoofing. ARP poisoning or spoofing is used for attacks from nefarious actors, but as described herein can also be used to add useful features to network devices.
As described above, a host (of Hosts 110) seeing a response to an ARP request—even one it did not initiate—will add an entry mapping to IP address to MAC address information provided in the response. This mechanism is important, as in many cases IP addresses are reused. For example, on a wireless network at a coffee shop or other public location, a fixed number of IP addresses are available, and are allocated (e.g., using DHCP) to machines as they join the network. As machines leave, the leases of an IP address provided by the DHCP server expire, and the addresses are given the other machines. These changes in IP address to a link-level (MAC) address for a host (of Hosts 110) are communicated to the other hosts (of Hosts 110) in the network as they see ARP responses propagate.
The mechanism described above also forms the basis for an ARP poisoning attack. For example, a spoofing host (of Hosts 110) on the network may broadcast unsolicited ARP responses, indicating that their MAC address is associated with a particular IP address, even if they are not configured to use that address and did not receive the address from the DHCP server. All Hosts seeing the unsolicited ARP response (can and most likely do) update their ARP table with this newly asserted mapping, as they have no way of knowing who is the “legitimate” holder of the IP address. If the spoofing host (of Hosts 110) sends unsolicited responses at regular intervals, as well as whenever a conflicting response might be seen (to replace it), the spoofing host (and/or another host of Hosts 110 collaborating with the spoofing host) may effectively steal an IP address, forcing all traffic (e.g., data packets) intended for that address to be delivered to the spoofing host (and/or collaborating host) instead. This attack may be used to impersonate any host (of Hosts 110), including the Gateway 150.
Beneficial Traffic Capture/Redirection
Having a secondary network available provides numerous advantages to an end user. Failures of the primary network may have results that range from inconvenient (e.g., losing a video game or not being able to watch an online video) to life-threatening (e.g., loss of alarm system connectivity during a robbery or loss of contact with a medical device requiring constant monitoring).
As described in U.S. patent application Ser. No. 16/011,479, filed Jun. 18, 2018, and U.S. patent application Ser. No. 14/708,132, filed May 8, 2015 and issued Dec. 13, 2016, as U.S. Pat. No. 9,521,069, the ability to switch from a primary network to one or more secondary network(s) when the primary network fails and/or degrades is highly useful. For example, metrics, such as Quality of Service (QoS) metrics, total packet loss rates, network latency measurements, and other approaches may be used to determine when a network has degraded to the point that it is no longer adequate for a particular use. In the case of such degradation, or complete failure, some or all traffic may be moved to a secondary network.
Connection of customer devices to the secondary network may not be straight forward. The topology of the network, that is, the way that the customer devices and the devices providing access to the primary and secondary network are arranged, can cause problems with access of the secondary network for some or all devices on the network. Several novel ways to allow either all or a majority of devices on a network to access the secondary network in various ways when needed, regardless of network topology, are described below.
In addition/alternative to capturing traffic to enable directing it to a secondary network, traffic may optionally be directed over various combinations and permutations of the primary and secondary networks. For example, the capture may be used to duplicate all traffic over one or more secondary network(s) for reliability; to send redundant data (other than full duplication, e.g., packets containing redundant or error correcting information) over one or more secondary network(s); and/or to break the data into multiple streams, delivering only some of the traffic over each connection (e.g. “striping” of data, for example for security or reliability purposes). For the purposes of illustration and not limitation, all data is described as being routed over either the primary or a secondary network, but mechanisms using multiple secondary networks; mechanisms duplicating the data over multiple networks; mechanisms striping the data over multiple networks; mechanisms extracting redundant information and delivering the redundant data over multiple networks; etc. may be additionally and/or alternatively performed.
Additionally or alternatively, in cases where a secondary network is available and those where it is not, being able to capture all traffic—even traffic that not would not flow through a particular network device normally—is desirable to facilitate packet marking and may be performed in some embodiments. For example, it may be desirable to mark packets for special treatment as they are delivered across the network to Remote Destination 130. An interactive communications provider or streaming media provider, for example, may want to preferentially mark their packets for higher priority routing (e.g., DiffServ or other QoS packet marking), and the ability to capture all packets and enforce marking is desirable. Note that it may be desirable to detect and remove markings from incorrectly (or nefariously) marked packets as well as to mark them.
Capture with Provider Hub at Network Edge
In some embodiments, the customer has both a Customer Router 210 and a Provider Hub 211 installed, for example, at a residence/home. Both Provider Hub 211 and Customer Router 210 can produce/control home networks to which Customer Devices 201 and/or Provider Hub Customer Devices 250 may connect. The home networks produced may take several forms, including wired Ethernet networks, Wireless (Wi-Fi) networks, DECT networks, ZigBee networks, Bluetooth networks, or other network types. The distinction between Customer Devices 201 and Provider Hub Customer Devices 250 relates to which of Customer Router 210 and Provider Hub 211 they are connected to.
Customer Router 210 can be a home router device, which is used to allow multiple devices to access a network connection provided to the customer's Internet service provider (ISP). Customer Router 210 can provide access internally using one or more network technologies (e.g., wired Ethernet, Wi-Fi, etc.), and can also provide other capabilities such as firewall, network address translation (NAT), filtering, security capabilities, etc. Devices which connect to Customer Router 210 are here referred to as Customer Devices 201. Network services are provided to Customer Devices 201 via Customer Router. In this example topology, the Customer Router itself is then connected to Provider Hub 211, which provides network services to the Customer Router 210.
Provider Hub 211 can be provided and/or managed by Service Provider 220. Provider Hub 211 can provide access to services offered by Service Provider 220, for example by the consumer directly interacting with the device, and/or via one or more of the Customer Devices 201 and/or Provider Hub Customer Devices 250 connected to Provider Hub 211. Devices connected directly to Provider Hub 211, rather than to the Customer Router 210 (and then on to Provider Hub), are referred to as Provider Hub Customer Devices 250.
In various embodiments, Service Provider 220 offers communications services (e.g., telephony, video services, and the like), and Provider Hub 211 enables communications devices (e.g., telephone handsets, video devices, network devices, etc.) on the premises (e.g., in or near the residence/home) to connect to the service provided by Service Provider 220. In the example case of a communications provider, in addition to IP network devices, Provider Hub 211 may have connections to allow analog telephone devices, and/or DECT wireless telephone devices in the premises (e.g., as another instance of Provider Hub Customer Devices 250) to connect to and use the services of Service Provider 220.
Additionally or alternatively, Provider Hub 211 can include at least some of the capabilities of Customer Router 210, such as facilitating network access over one or more access technologies, providing security and/or firewall services, etc. Because Provider Hub 211 can provide many or all the services provided by Customer Router 210, in some embodiments the customer router may not be needed and Provider Hub 211 instead provides these services for all Customer Devices 201. In such instances, all consumer devices are Provider Hub Customer Devices 250.
Service Provider 220 can be reached over the Internet 232. Access to Internet 232 for the end user can be over Access Network(s) 230, via Access Device(s) 231. For example, Access Network(s) 230 may be a cable, fiber, DSL, wireless, Wi-Max, and the like, accessed via an Access Device(s) 231, which may be cable modem, fiber modem, wireless router, and the like. Additionally or alternatively, Secondary Access Network(s) 241, accessed via Secondary Access Device(s) 240, can be provided. Secondary Access Network(s) 241 may be a second network of the same type (e.g., a second cable modem), but may also be a connection over a different network (e.g., different network technology and/or ISP). In various embodiments, the primary network (e.g., Access Network 230) is a wired network (e.g., cable, DSL, fiber, and the like), and secondary network (e.g., Secondary Access Network(s) 241) is a wireless backup network (e.g., 4G, WiMax, and the like). In some embodiments, the primary network (e.g., Access Network 230) is a wired network (e.g., cable, DSL, fiber, and the like), and secondary network (e.g., Secondary Access Network(s) 241) is a different network provider's wired backup network (e.g., cable, DSL, fiber, and the like). Note that in addition to Service Provider 220, Other Destinations 260 may also be reached for other service.
In the topology of network 200, Provider Hub 211 is connected to one or more Access Network(s) 230 and/or Secondary Access Network(s) 241 to reach the Internet 232 (and on to Service Provider 220 or Other Destination 260). Optionally, one or more Access Device(s) 231 and/or Secondary Access Device(s) 240 may be between the provider hub and the access network(s). For example, the network service for the customer is provided by a cable company ISP, and the access device takes the form of a cable modem. By way of further non-limiting example, the access network is a cellular network, for example an LTE network, and the access device is a modem to connect to the cellular network. In another example, the access device is a consumer device featuring a network connection which it can share with other devices. For example a mobile phone may share its broadband connection with provider hub and/or consumer router as a network connection (e.g., via a “hotspot”).
In some embodiments, features/functions of Access Device(s) 231 and/or Secondary Access Device(s) 240 may be integrated/included in Provider Hub 211 (and/or Customer Router 210, if connected directly to the access networks). Moreover, various combinations and permutations of stand-alone access device and similar technologies can be integrated into Provider Hub 211 and/or Customer Router 210 (e.g., a stand-alone access device in the form of a cable modem connected to the provider hub, as well as integrated hardware allowing access to a wireless LTE network included in the provider hub).
As depicted in
Provider Hub Transparently Manages
In network 200, Provider Hub 211 can control and direct all traffic (e.g., data packets)—whether from Customer Devices 201 attached to Customer Router 210 or from Provider Hub Customer Devices 250. Traffic from Provider Hub Customer Devices 201 can flow directly to Provider Hub 211, and Provider Hub 211 may direct that traffic over the Access Network(s) 230 and/or Secondary Access Network(s) 241. Similarly, since traffic from Customer Devices 201 flows to Customer Router 210, which then flows to Provider Hub, all traffic from these devices may be monitored and controlled by Provider Hub 211, and directed to either the Primary Access Network 230 or Secondary Access Network 241 (or a combination (e.g., duplication, striping, redundant data) of both).
When the optional Customer Router is not present, all devices are Provider Hub Customer Devices 250, and traffic flows through Provider Hub 211. In some embodiments, Provider Hub 211 also provides NAT capabilities, meaning that devices “behind” (that is, toward the customer side of) Provider Hub 211 typically will have a private, internal address that does not change when switching from Primary Access Network 230 to Secondary Access Network 241.
Traffic flows may be monitored, either by the Provider Hub 211 or by Service Provider 220. When failure or degradation of the Access Network(s) 230 is observed, some or all traffic can be moved to Secondary Access Network(s) 241. This determination may be made by either Provider Hub and/or by Service Provider.
When traffic flows over unreliable, non-stream-oriented connections (e.g., User Datagram Protocol (UDP)) without identifying information tied to the source, some or all traffic may be redirected over the Secondary Access Network(s) 241, as there is no correlation between traffic received over the network connection.
Analogously, some or all traffic may be moved back from Secondary Access Network(s) 241 to Primary Access Networks(s) 230 when it is determined (e.g., by Service Provider 220 and/or Provider Hub 211) that network conditions on the Primary Access Network(s) 230 have improved.
For protocols operating over stream-oriented transport protocols (e.g., Transmission Control Protocol (TCP)), or other protocols that maintain state or other options (e.g., sequence numbers, connection numbers, correlating the connection with source IP, etc.) there are several options. For example, the streams are maintained and managed by Provider Hub 211, with the customer device (of Customer Devices 250) having a stream between itself and the Provider Hub, rather than all the way to the stream destination.
Stream Customer Device 310 can establish a connection over a stream to Destination 320. Because all traffic flows through Provider Hub 211, the Provider Hub can intercept and manage this connection. For example, this is accomplished by simply providing an address for Provider Hub 211 to Stream Customer Device 310 to reach destination 320. By way of further non-limiting example, this is accomplished by providing DNS name resolution to Stream Customer Device 310 that provides Provider Hub's 211 internal address when resolving the URL for Destination 320. By way of additional example, Stream Customer Device is pre-provisioned with Provider Hub's internal address to reach the Destination.
In some embodiments, Stream Customer Device 310 attempts to establish the connection using Destination 320's address as normal, but because Provider Hub 211 is in the path of all traffic in this architecture, the traffic is intercepted by Provider Hub, without needing to provide Provider Hub's address to Stream Customer Device 310. The information contained in the messages intended for Destination 320 may be examined by Provider Hub 211, for example by use of deep packet inspection (DPI), and rather than forward this traffic to Destination 320 and allow the connection to be established between Destination 320 and Stream Customer Device 310, Provider Hub 211 acts as an endpoint and establishes the stream-oriented connection, Local Stream Connection 330, between Provider Hub 211 and Stream Customer Device 310. In this case, Stream Customer Device 310 believes it is connecting directly to the public address of Destination 320.
In the case of secure protocols, other steps may be indicated. For example, Provider Hub 211 may intercept earlier messages from Stream Customer Device 310 establishing encrypted connections, requesting certificates from public locations, etc., and in each case substitute its own connections or certificates as appropriate. In some embodiments, because Provider Hub 211 is provided by and operated by Service Provider 220 (an (exemplary) embodiment of Destination 320), Provider Hub 211 is provided with appropriate credentials to authenticate the communication.
While establishing Local Stream Connection 330, Provider Hub can also open Primary Stream Connection 340 between itself and Destination 320, over Access Network(s) 230 and Internet 232. For Destinations 320 that support multiple simultaneous streams, a Secondary Stream Connection 350 (and possibly even further parallel streams) over Secondary Access Network(s) 241 and Internet 232 may also be opened at this time. Traffic between Stream Customer Device 310 and Destination 320 is delivered over one or more of these connections, with Stream Customer Device 310 believing Local Stream Connection 330 is the actual connection to the Destination 320, and Destination 320 believing that Primary Stream Connection 340 (and/or Secondary Stream Connection 350) is the actual connection to the Stream Customer Device. Decisions as to whether delivery over the Primary Stream Connection 340 or Secondary Stream Connection 350 is appropriate may be made by Provider Hub 211, other customer devices (e.g., Customer Devices 201, Customer Router 210, Provider Hub Customer Devices 250) or Destination 320 depending on network quality, cost, etc.
For protocols and/or Destinations 320 that support multiple simultaneous streams (e.g., either explicitly, or by utilizing the IETF MPTCP [MPTCP] or similar protocols) Provider Hub 211 directs traffic over Primary Stream Connection 340 and/or Secondary Stream Connection 350 such as indicated by preconfigured options. In some embodiments, these options specify conditions under which the Primary Stream Connection is considered failed or degraded, and under these conditions, traffic is moved to Secondary Stream Connection 350. Traffic may be moved dynamically between the two stream connections as network conditions warrant. In other embodiments, cost, delay, utilization, utilization within a billing period (e.g., “how much of the data plan has been used?”) or other factors may also be used in deciding which stream to use. As in other embodiments, data may be simultaneously sent over a combination of the primary and secondary networks (e.g., duplication, striping, redundant data).
For protocols and/or Destinations 320 that do not support multiple simultaneous streams, Provider Hub 211 can terminate Primary Stream Connection 340, and establish Secondary Stream Connection 350 dynamically at the time that the network failure, degradation, or other reason (e.g. cost) indicates a need to switch to secondary network (e.g., Secondary Access Network 241). In some cases, this may be transparent to Stream Customer Device 310, which continues to send traffic over Local Stream Connection 330. Provider Hub 211 may buffer traffic as needed. In other cases, the protocol or application may need Provider Hub to signal Stream Customer Device indicating that Local Stream Connection 330 has failed or otherwise needs to be reestablished, terminate the Local Stream Connection, and/or in some other way force closure and/or reestablishment of Local Stream Connection 330, then re-establish over the secondary network (e.g., Secondary Access Network 241).
In architectures such illustrated in
In various embodiments, Provider Hub 211 does not itself become involved in the stream connections, but can manipulate the underlying network to direct traffic either over the primary or secondary network.
When the quality of Access Network(s) 230 (or other metrics, for example cost) force Provider Hub 211 to conclude traffic needs to be send over Secondary Network(s) 241 instead, Provider Hub 211 can terminate the connection, such as by disconnecting access to (primary) Access Network(s) and/or by a more sophisticated means. For example, Provider Hub 211 can examine the traffic (e.g., data packets) in Primary Stream Connection 340 and injecting traffic such as reset packets, and/or by selectively dropping packets that will cause mechanisms in the streaming protocol to terminate the connection.
When the connection fails, the Stream Customer Device 310 and/or Destination 320 will (eventually) attempt to reestablish the network connection. When Stream Customer Device 310 attempts to re-establish the connection, Provider Hub 211 can use the secondary network (e.g., Secondary Access Network 241) instead, resulting in Secondary Stream Connection 450 being established. Stream Customer Device 310 will notice no difference in the outbound connection. However, the public IP address that Destination 320 observes traffic originating from will be different, and will be an address on Secondary Access Network(s) 241, rather than Access Network(s) 230, allowing Destination 320 to observe the connection as being distinct.
In various embodiments, Provider Hub 211 maintains a set of mappings of internal IP addresses to use for mapping requests to the secondary network. These internal IP addresses are typically, but are not required to be, in a different address space (e.g., subnet) than those used to provide traditional NAT service to devices behind the Provider Hub 211. In other words, customer devices (e.g., one of either Customer Devices 201 or Provider Hub Devices 250) behind the NAT provided by Provider Hub 211 may be in a particular reserved address space (e.g., 192.168.0.0 with a netmask of 255.255.255.0-192.168.0.0/24), while the internal IP addresses used for mappings may be a different network (e.g., 10.0.0.0 with a netmask of 255.0.0.0-10.0.0.0/8). In some embodiments, the addresses reserved for link local connections (e.g., used by Microsoft's APIPA) (e.g., addresses 169.254.0.1-169.254.254.254 (169.245.0.0/16) in IPv4, and FE80::/10 in IPv6) may be used for this purpose, although there is risk that other protocols may use these addresses.
Provider Hub 211 can keep track of mappings using these internal IP addresses. The mappings may be defined by hard coding, by Provider Hub 211, an external service (e.g., Service Provider 220), and/or internal customer device (e.g., Provider Hub 211, Customer Router 210, Customer Devices 201, and/or Provider Hub Customer Devices 250) requesting a mapping to enable use of the outside address via Secondary Access Network(s) 241. This can occur when Provider Hub 211, external service (e.g., Service Provider 220), or customer device (e.g., one of either Customer Devices 201 or Provider Hub Devices 250) has noticed a network failure, network degradation, and/or cost/utilization issue that prompts a switch to the secondary network. This can be initiated by prompting the customer device to use the secondary network (e.g., Secondary Access Network 241) directly (by contacting the destination at the mapped local address, rather than the true public address), or by provisioning or configuring the device with the mapped secondary address as a “backup server,” which can be used when connections over the (primary) Access Network(s) 230 fails.
In various embodiments, Provider Hub 211 may (e.g., using techniques such as DPI or similar approaches) manipulate the data in Primary Stream Connection 440 and Secondary Stream Connection 450 (not depicted in
While process 500 can have Provider Hub 211 allocating the addresses, the allocation could also be controlled by Service Provider 220, or by another centralized entity that manages the available pool of addresses. In this case, the mappings can then be passed to Provider Hub 211 (not shown in
If the request is determined at step 620 to be for a mapped private address, then processing can move to step 640. At step 640, the public address associated with the mapped private address can be retrieved. At step 650, destination headers can be rewritten to use this public address obtained at step 640. Additionally, further rewriting of other portions of the packet, for example application level headers, can be performed at this step. At step 660, the packet (with translated headers) can be transmitted using Secondary Access Network(s) 241. Process 600 can continue to step 670, where the Provider Hub can return to waiting for new packets, moving to start.
Error processing (e.g., requests for invalid external addresses, for unmapped private addresses, and the like) is not shown in
According to some embodiments, packets are duplicated across both networks (not shown in
Inbound response messages from the destination can also have their headers re-written, to make them appear to originate from the mapped private address, rather than the mapped public address. Mappings maintained by the provider hub (e.g., Provider Hub 211) can map a private address (the “left hand side”) to a public address (the “right hand side”). E.g., YYY.YYY.YYY.YYY→XXX.XXX.XXX.XXX, where left hand side YYY.YYY.YYY.YYY is a private address, and XXX.XXX.XXX.XXX is a public address. All inbound messages can be examined, and those arriving on Secondary Access Network(s) 241 with source addresses matching a right hand side of a mapping are rewritten, replacing the source address with the left hand side.
If the message is determined to be from a mapped address (e.g., a right hand side) at step 720, then processing can move to step 740. At step 740, the mapped private address (left hand side) associated with the public address (right hand side) can be retrieved. At step 750, source headers can be rewritten to use this private address obtained at step 740. Additionally, further rewriting of other portions of the packet, for example application level headers, can be performed at this step. At step 760, the packet (with translated headers) can be forwarded to the destination. Process 700 can continue to step 770, where the Provider Hub can return to waiting for new packets, moving to start.
Error processing (e.g., requests from invalid external addresses, for unmapped private addresses, and the like) is not shown in
While not illustrated here, in some scenarios packets are duplicated, striped, or redundant information conveyed across both networks. In this scenario, the packets received may require processing to combine into a single packet stream before being delivered to the host.
In some embodiments, the (mapped) private addresses can be employed when using the (primary) Access Network(s), and the public addresses can be employed when using the Secondary Access Network(s), without loss of generality.
Provider Hub DNS Approach
Referring back to
When the customer device (e.g., one of either Customer Devices 201 or Provider Hub Devices 250) wishes to reach the destination, the customer device may have the destination (e.g., one of either Service Provider 220 or Other Destination 260) in the form of an IP address, in which case this may not apply.
However, when the device has the destination in the form of a hostname or URL, the hostname (or hostname portion of the URL) should be resolved or translated into an IP address using DNS, as described earlier. Here, the DNS server provided to the customer device can be controlled by Service Provider 220. For example, the customer device (e.g., one of either Customer Devices 201 or Provider Hub Devices 250) is hard coded to use a particular DNS server. By way of further non-limiting example, when a customer device boots and receives an IP address provided using DHCP, the IP address of an external DNS server is controlled (directly or indirectly) by Service Provider 220. By way of further non-limiting example, the customer device is hard coded with, or when a customer device boots and receives an IP address provided using DHCP, the IP address of Provider Hub 211 is given and Provider Hub 211 acts as the DNS server. Provider Hub 211 can incorporate a DNS server and/or proxy DNS requests to Service Provider 220 and/or a service on behalf of Service Provider 220.
When hostnames are resolved, the condition (or cost or other factors) of Access Network(s) 230 is considered by Service Provider 220 and/or Provider Hub 211. If the (primary) Access Network(s) (e.g., Primary Access Network(s) 230) connectivity, connection quality, cost, etc. are determined to be adequate, the name resolution returns the actual IP address for the destination. When the traffic for this address reaches Provider Hub 211, it is delivered as normal (e.g., without altering the data packet header), over Access Network(s) 230.
When the quality, cost, etc. of the (primary) Access Network(s) 230 is/are determined by Service Provider 220 and/or Provider Hub 211 to be inadequate at the time of name resolution, instead of returning the actual IP address of the destination, a different, private space address can be returned. For example, private space addresses as described in Request for Comment 1918 from the Internet Engineering Task Force (IETF) (RFC1918) can be used. This address space can be distinct from the range used for internal devices (e.g., customer devices) by the NAT built into Provider Hub 211. A mapping between the actual (public) address of the destination and this new (private) address provided to the device can be maintained by Provider Hub 211. For example, when the public address is XXX.XXX.XXX.XXX, a private address, e.g. 10.0.33.44 is provided to the device instead, and the mapping XXX.XXX.XXX.XXX→10.0.33.44 is maintained by Provider Hub 211 as discussed earlier.
When a request to connect to the (private) destination address (e.g. 10.0.33.44) is made by a device (e.g., of Customer Devices 201 and/or Provider Hub Devices 250), Provider Hub 211, recognizing that this address is within the private space reserved for this purpose, will retrieve the actual (public) address (e.g. XXX.XXX.XXX.XXX) and redirect traffic to this destination over Secondary Access Network 241, translating packet headers in the same way as discussed earlier. Note that in some scenarios when packets addressed to the private space are received by Provider Hub, packet duplication techniques using both networks (e.g., duplication, adding of redundancy, striping) may be used, in addition to simply determining the best network and sending traffic over that connection.
DNS address resolutions can be cached by the client (e.g., Customer Devices 201 and/or Provider Hub Devices 250) making the DNS resolution request. To facilitate this, yet allow hostname→address mappings to be changed, responses include a time to live, or TTL. In embodiments using TTL, the addresses provided can be changed whenever the network conditions (e.g., quality, connectivity, cost, etc.) change, the TTL returned should by necessity be very short. For example, this value is set to 60 seconds. If the device wishes to connect to the destination again after 60 seconds, the process can be repeated, allowing for a different address (using either the primary or secondary network) to be returned.
At step 830, the entity processing the DNS request can determine if the primary network (e.g., Primary Access Network(s) 230) should be used. The outcome may be because the primary network is degraded or non-functional, but may also be based on cost, utilization (e.g., how much of a monthly bandwidth allocation has been used) or other metrics.
If it is determined the primary network (e.g., Primary Access Network(s) 230) should be used at step 830, then flow can continue at step 840, where the public IP address identified at step 820 is returned to the device (e.g., Customer Devices 201 and/or Provider Hub Devices 250) requesting the name resolution. Flow can continue at step 880.
If it is determined the primary network (e.g., Primary Access Network(s) 230) should not be used (or that the primary network will be used in combination with the secondary network, for example using duplication, striping, and/or creation of redundant packets) at step 830, then flow can continue at step 850, where a private IP address is allocated, and the public IP address identified at step 820 is mapped to the allocated private address. At optional step 860 the mapping can be forwarded to Provider Hub 211. If Provider Hub 211 is serving as the DNS server and/or relaying the DNS requests, this step may be not be needed. At step 870 the private address can be returned to the device (e.g., Customer Devices 201 and/or Provider Hub Devices 250). Flow can then continue at step 880.
At step 880, method 800 can return to waiting for the next DNS request, and flow returns to the beginning of the process.
Although the process of allocating the private address mappings is shown as residing within the DNS server, other resources can be used. As with method 500, allocation can also be performed by Provider Hub 211, Service Provider 220, another centralized entity that manages the available pool of addresses, and the like. Although expiry of addresses after a period of disuse is not illustrated here for clarity, it can be included in method 800.
In method 800, the Provider Hub 211 can maintain the list of address translations and translates messages send to mapped private addresses to public addresses before sending them over Secondary Access Network 241 (see
Capture With Provider Hub Not at Network Edge
Provider Hub Customer Devices 250 can be connected to Provider Hub 211, which can serve as the gateway for those devices. When (primary) Access Network 230 is functional, Provider Hub relays traffic from Provider Hub Customer Devices to Customer Router 210 on their behalf, over Link(s) 910. When needed, traffic can also be sent over Secondary Access Network 240 (or in combination with the (primary) Access Network), connected to Provider Hub.
For Customer Router 210 devices, devices connected to its internal interfaces (e.g., Customer Devices 201 and Provider Hub 211) can be connected by a link-layer switch. As such, all of these devices can share an ARP broadcast space and see ARP requests from one another. In some cases, wireless devices connected to Customer Router can have a different ARP broadcast space than wired devices. In these instances, Provider Hub 211 can be connected with both wireless and wired connections (two instances of 910), enabling Provider Hub 211 to participate in both ARP broadcast spaces. If there are additional wireless and/or wired networks, for example multiple wireless networks, various wired technologies, etc., the Provider Hub 211 can maintain an instance of Link 910 to each of these networks, allowing access to all available ARP broadcast spaces.
Service Only to Provider Hub Devices
Some embodiments, when the (primary) Access Network 230 is functioning properly, all traffic flows through Customer Router 210. Customer Router serves as Gateway 150 (
When a failure, degradation, cost reason, or other factor causes Provider Hub 211 and/or Service Provider 220 to determine that the (primary) Access Network(s) 230 is no longer functioning as desired, Provider Hub 211 will redirect traffic over Secondary Access Network(s) 241 (or a combination of primary and secondary networks). However, in the network configuration shown in
Any of the mechanisms described earlier in relation to
According to various embodiments, only the devices connected to Provider Hub 211 (e.g., Provider Hub Customer Devices 250) will be able to use Secondary Access Network(s) 241. Because Customer Router 210 is the gateway for Customer Devices 201, their traffic may not be seen by Provider Hub, and therefore cannot be redirected to the Secondary Access Network(s) 241 (or a combination of primary and secondary networks).
Service Via ARP Spoofing
In some embodiments, ARP spoofing or poisoning is used by Provider Hub 211 in an architecture like network 900 in
In an environment like network 900 shown in
Periodically, Provider Hub 211 can send unsolicited “spoofed” ARP responses over Link 910, identifying its own MAC address as being the link layer address associated with the IP address Customer Devices 201 have configured for their gateway. When Customer Devices 201 see this response, they replace their entry for the gateway, previously mapping traffic to the link-level address for Customer Router 210, with the link-level address of Provider Hub 211. When this occurs, all external traffic from Customer Devices 201 will be delivered to Provider Hub 211 instead, which may then forward the traffic (“hairpin”) back to Customer Router 210 to be delivered over Access Network 230, can deliver the traffic over Secondary Access Network 241, or duplicate traffic over both links using duplication, striping, and/or redundant packet approaches.
Provider Hub 211 can also listen on the shared ARP broadcast space for any ARP requests for the IP address associated with the default gateway. In addition to replying to these requests, Provider Hub monitors to ensure that if any other host (e.g., Customer Router 210) replies with their own MAC address, the Provider Hub immediately sends another (unsolicited) ARP response immediately after detecting such a response.
Additionally or alternatively, Provider Hub 211 can monitor the shared ARP space for broadcasts. If Customer Router 210 or any other host sends (unsolicited) ARP response broadcasts claiming the address of the gateway, Provider Hub will immediately send another unsolicited ARP response claiming the address of the gateway, to ensure that all traffic will continue to arrive at Provider Hub.
As described above, Provider Hub 211 may have multiple Link(s) 910, enabling it to access multiple ARP broadcast spaces, for example for wired and wireless networks. In this situation, unsolicited ARP responses will be sent over each Link(s) 910 periodically, as well as immediately after any conflicting messages claiming the gateway address are sent by Customer Router 210 or any other device.
According to some embodiments, before relaying outbound traffic to Customer Router 210 to be delivered over Access Network 230, source addresses (e.g., link-layer/MAC, IP, application layer, the like, and combinations thereof) of traffic are spoofed (e.g., the packet header is changed) to show Provider Hub 211 as the source. This ensures return traffic is delivered to Provider Hub 211 when responses arrive. While not strictly required, this facilitates other actions (e.g., packet re-writing (e.g., headers), packet examination, etc.) that Provider Hub 211 may advantageously perform on the returning packets before sending to the ultimate destination. This can be needed if Customer Router 210 has filtering software that may detect and drop packets shown as originating from a switch link having a MAC address that is not currently associated with that switch link.
In various embodiments, Provider Hub 211 does not modify the source addresses (e.g., MAC, IP, and the like) before relaying traffic to Customer Router 210 for delivery over Access Network 230. Response traffic will then be delivered directly to the source by Customer Router 210.
Capture DNS Requests Using ARP Spoofing
In some embodiments, an internal DNS server is established, rather than use an external DNS server. Here, ARP spoofing may again be used, but rather than attempting to impersonate the gateway as described above, Provider Hub 211 uses ARP spoofing to claim traffic intended for the internal DNS server. Some or all of the techniques described above for using ARP spoofing to capture traffic intended for the gateway can be leveraged to capture traffic intended for the local DNS server. Once this is accomplished, DNS traffic may be manipulated as discussed earlier in the provider Hub DNS Approach.
If Customer Router 210 itself is the DNS server, then the IP address of the gateway and the DNS server are (likely to be) the same. Using ARP spoofing to capture IP address of the DNS server also captures the traffic that would (otherwise) be sent to the gateway. In that case, all traffic is captured and hairpinned, and the general ARP spoofing case above applies.
Capture DHCP Requests
According to various embodiments, Provider Hub 211 monitors the network for traffic from new Customer Devices 201 joining the network, in an attempt to intercept their DHCP requests and provide alternate results. This is performed (only) over Link(s) 910—this may not be needed for Provider Hub Customer Devices 250, traffic from which Provider Hub 211 already controls.
At boot time, Provider Hub 211 can use DHCP over Link 910 to obtain a valid IP address, subnet, gateway address, and DNS server address from Customer Router 210. This allows Provider Hub 211 to send traffic out over Access Network 230, as well as to identify the subnet being used by Customer Router 210 (e.g., determined based upon the address and netmask provided by Customer Router 210 in response to the Provider Hub's 211 DHCP request). This subnet is referred to as the Router Subnet here for clarity.
After obtaining an address, when Provider Hub 211 detects a DHCP request has been broadcast by a new Customer Device 201, it (immediately) responds to the message with a DHCP OFFER, offering an IP address in a different private subnet (e.g., range of private addresses), which is referred to as the Hub Subnet here for clarity. This subnet is different from the one maintained by Customer Router 210 (the Router Subnet). When providing this DHCP offer, in addition to providing an address in a different subnet, Provider Hub 211 presents itself as the gateway to be used with that private address and subnet, and may also identify itself as the DNS server.
If Customer Device 201 accepts the DHCP offer, Customer Device 201 now has an IP address on the Hub Subnet. Because Provider Hub 211 was presented as the gateway for this address, all outbound traffic from the new Customer Device 201 will be routed to Provider Hub, and may then be forwarded over Access Network(s) 230 via Customer Router 210 (optionally with re-written headers) or over Secondary Access Network(s) 241. By intercepting this DHCP traffic and providing alternate addresses to the Customer Device 201, Provider Hub 211 has (in effect) created a virtual (VLAN; a broadcast domain that is partitioned and isolated in a computer network at the data link layer), but for a very novel purpose, enabling control of Customer Device(s) 201 traffic, including enabling the use of the Secondary Access Network 241 for devices not located behind Provider Hub.
If Access Network 230 is functioning normally, Provider Hub 211 rewrites the traffic (e.g., data packet headers), replacing Customer Device's 201 Hub Subnet address with Provider Hub's 211 own Router Subnet address. The messages (traffic or data packets) are then passed to Customer Router 210 to relay it on to Access Network 230. Responses are returned to Provider Hub 211, which rewrites the packets back to the Hub Subnet address for Customer Device 201 and passes the message to Customer Device 201. This is a second layer of NAT translation, being performed within the same network, but for a unique purpose of capturing and forwarding traffic over a secondary network (when needed).
If Access Network 230 is not performing normally (e.g., failed, degraded, or some other metric indicates that network is undesirable), traffic (e.g., data packets) from Customer Device 201 delivered to Provider Hub 211 may instead be routed over Secondary Access Network 241 (or may be directed over a combination of primary and secondary networks, using techniques such as duplication, striping, and/or the creation of redundant packets).
A race condition may occur here. If Provider Hub 211 is unable to respond more quickly than Customer Router 210 (e.g., a home router) to DHCP requests, it is possible that Customer Router 210, rather than Provider Hub's DHCP response will be accepted. To prevent this, Provider Hub 211 tries (is configured to) to respond as quickly as possible, particularly over wired connections in a switched medium, as is common on modern switched wired Ethernet. However, for shared connections (e.g., wired networks connected with a hub or wireless networks), another unique mechanism can be used.
According to some embodiments, Provider Hub 211 watches for DHCP traffic over Link 910, where Link 910 is to a shared media (e.g., a wireless or hub-based network). When Provider Hub 211 sees a DHCP request from Customer Device 201, Provider Hub 211, rather than responding to the message immediately, it instead sends “jam” messages for the underlying link-layer protocol. For example, both hub-shared media Ethernet and Wi-Fi use CSMA/CD (carrier-sense multiple access with collision detection) to detect multiple devices attempting to communicate over a shared medium. When a collision is detected, the jam message is sent, instructing all devices to back off, wait a random time, and then retry to send their message. Provider Hub 211 immediately sends a DHCP OFFER as soon as it completes sending the jam message, while other senders, including the Customer Router 210, will be waiting a random time for the jam condition to clear. This helps ensure that the DHCP OFFER from Provider hub is likely to be accepted by the Customer Device.
Since there may be multiple isolated networks operated by Customer Router 210 (e.g., a wired and a wireless network), there may be multiple Link(s) 910 allowing Provider Hub 211 to connect to all of these isolated networks, and the DHCP behavior described above is performed by Provider Hub 211 on all Links, allowing intercept of DHCP requests from Customer Devices 201 on all networks.
Internal Provider Hub NAT-Like Mapping Approach
Some Customer Devices 201 are designed to allow multiple servers to be used in a failover scenario. For example, some Session Initiation Protocol (SIP) endpoints may be configured with a primary server as well as one or more secondary servers. According to various embodiments, Provider Hub 211, after obtaining an internal IP address from Customer Router 210, communicates this internal IP address to Service Provider 220, and Service Provider 220 and Provider Hub 211 cooperate to allocate a number of ports using Provider Hub's 211 internal address that are available. Customer Devices 201 communicating with Service Provider 220 are provided one of these internal address (of Provider Hub 211) and port pairs as a backup address for the application connecting to Service Provider. In the event that Customer Devices 201 are unable to communicate with Service Provider 220 normally (via Customer Router 210 over Access Network 230), these devices then use the backup address (of Provider Hub 211) and port for application connections to Service Provider. Traffic delivered to the Provider Hub on this special port can then be forwarded to Service Provider 220 over Secondary Network 241. Because port numbers are used as well, multiple Customer Devices 201 and/or multiple applications or services may have an internal backup address provisioned. Under such conditions, the secondary address used by the Customer Device 201 may not reach a different server, but rather the same remote server using the Secondary Network 241 via a mapped local address. Under such conditions, an actual second server may be provisioned in Customer Devices 201 as a third server address. A fourth backup server address may correspond to a local (mapped) address reaching the second server using the Secondary Network 241, etc.
The above approach may provide a backup address to applications running on Customer Device 201 that are aware of and working with Service Provider 220. Service Provider 220 provides the internal address of Provider Hub 211 (obtained from Provider Hub) to Customer Devices 201 which are explicitly aware to use this as a backup address. Because this requires some awareness on the part of the Customer Device 201 (e.g., being programmed explicitly with the mapped address as a backup server), unlike other approaches described above, this solution may not be a solution for general access of all applications to the Secondary Access Network 241.
When failures of Access Network 230 occur, Customer Devices 201 send application traffic to the pre-agreed port on Provider Hub 211. Provider Hub 211 forwards the traffic over Secondary Access Network 241, rewriting response packets to appear to originate from itself if/when needed. Responses may be similarly rewritten to appear to originate from Provider Hub 211. This is analogous to the process described in
Marking Captured Traffic
In addition/alternative to capturing traffic in numerous ways for the purpose of delivering it over a secondary network (or in combination with a secondary network) when a primary network is degraded or fails is described above, all traffic captured (including from devices that might otherwise not pass through Provider Hub 211, such as Customer Devices 201 in
According to some embodiments, as traffic is directed to Provider Hub 211, the packets are examined to determine if they should be marked in some way to indicate preferential routing treatment. For example, it may be desirable to mark devices that are sending real-time streaming information for preferential treatment. This marking facilitates improved QoS processing by devices further down the network path. Standardized markings such as DiffServ DSCP fields may be used for this purpose, or other mechanisms may be defined. In addition, since all traffic is captured, packets that have been marked, but should not be (e.g., from applications marking themselves to try to improve application performance) may be removed. Additionally, inbound packets may be marked or markings removed by the Provider Hub 211 for improved management by an internal network.
Marking can be combined with delivery over one or more secondary network(s). That is, marked packets may then be delivered over the (primary) Access Network(s) 230, over Secondary Access Network(s) 241 (if available), or over some combination of both networks, using replication techniques (e.g., duplication, striping, and/or creation of redundant information packets)
Provider Hub as Secondary Network
Some of Customer Routers 210 can include capabilities allowing them to use a secondary network (e.g., Secondary Access Network 241) directly. In some cases, this is via a connection allowing a second network to plug in via Ethernet. In other cases it can be via Universal Serial Bus (USB), allowing a secondary Access Device 240 (e.g., a WiMax, 4G, and the like modem) to be connected to provide a second network connection.
As shown in network 1000 in
In various embodiments, (all) traffic flows through Provider Hub 211 (that is, Provider Hub is on the “outside” of the network from Customer Router 210, but Provider Hub also maintains a connection back “inside” of the network of Customer Router 210).
However, in the architecture of network 200, Provider Hub 211 may not be able to send traffic directly to Customer Devices 201, particularly if Customer Router 210 incorporates firewall capabilities. This may undesirable.
For example, Service Provider 220 provides an Internet of Things (IoT) connected home service. While both Customers Devices 201 and Provider Hub Customer Devices 250 can communicate with Service Provider 220 in the architecture of network 200 presented in
Link(s) 1110 can be connections from Provider Hub 211 to the inside of Customer Router 210, making Provider Hub 211 serve as both an outbound gateway for Customer Router 210 and a host inside that network, like Customer Device (Customers Devices 201). Provider Hub 211 may relay traffic between Customer Devices 201 and Provider Hub Customer Devices 250, allowing communication between these devices. NAT-like behavior, described above, may be used to ensure IP addresses between Customer Devices 201 and Provider Hub Customer Devices 250 are properly translated, even if Customer Router 210 and Provider Hub 211 use different subnets for their respective internal devices.
Multiple links 1110 may be used, for example to connect to both wired and wireless networks operated by Customer Router 210.
The components shown in
Mass data storage 1230, which can be implemented with a magnetic disk drive, solid state drive, or an optical disk drive, is a non-volatile storage device for storing data and instructions for use by processor unit(s) 1210. Mass data storage 1230 stores the system software for implementing embodiments of the present disclosure for purposes of loading that software into main memory 1220.
Portable storage device 1240 operates in conjunction with a portable non-volatile storage medium, such as a flash drive, floppy disk, compact disk, digital video disc, or Universal Serial Bus (USB) storage device, to input and output data and code to and from the computer system 1200 in
User input devices 1260 can provide a portion of a user interface. User input devices 1260 may include one or more microphones, an alphanumeric keypad, such as a keyboard, for inputting alphanumeric and other information, or a pointing device, such as a mouse, a trackball, stylus, or cursor direction keys. User input devices 1260 can also include a touchscreen. Additionally, the computer system 1200 as shown in
Graphics display system 1270 include a liquid crystal display (LCD) or other suitable display device. Graphics display system 1270 is configurable to receive textual and graphical information and processes the information for output to the display device.
Peripheral device(s) 1280 may include any type of computer support device to add additional functionality to the computer system.
The components provided in the computer system 1200 in
Some of the above-described functions may be composed of instructions that are stored on storage media (e.g., computer-readable medium). The instructions may be retrieved and executed by the processor. Some examples of storage media are memory devices, tapes, disks, and the like. The instructions are operational when executed by the processor to direct the processor to operate in accord with the technology. Those skilled in the art are familiar with instructions, processor(s), and storage media.
In some embodiments, the computing system 1200 may be implemented as a cloud-based computing environment, such as a virtual machine operating within a computing cloud. In other embodiments, the computing system 1200 may itself include a cloud-based computing environment, where the functionalities of the computing system 1200 are executed in a distributed fashion. Thus, the computing system 1200, when configured as a computing cloud, may include pluralities of computing devices in various forms, as will be described in greater detail below.
In general, a cloud-based computing environment is a resource that typically combines the computational power of a large grouping of processors (such as within web servers) and/or that combines the storage capacity of a large grouping of computer memories or storage devices. Systems that provide cloud-based resources may be utilized exclusively by their owners or such systems may be accessible to outside users who deploy applications within the computing infrastructure to obtain the benefit of large computational or storage resources.
The cloud is formed, for example, by a network of web servers that comprise a plurality of computing devices, such as the computing system 1200, with each server (or at least a plurality thereof) providing processor and/or storage resources. These servers manage workloads provided by multiple users (e.g., cloud resource customers or other users). Typically, each user places workload demands upon the cloud that vary in real-time, sometimes dramatically. The nature and extent of these variations typically depends on the type of business associated with the user.
It is noteworthy that any hardware platform suitable for performing the processing described herein is suitable for use with the technology. The terms “computer-readable storage medium” and “computer-readable storage media” as used herein refer to any medium or media that participate in providing instructions to a CPU for execution. Such media can take many forms, including, but not limited to, non-volatile media, volatile media and transmission media. Non-volatile media include, for example, optical, magnetic, and solid-state disks, such as a fixed disk. Volatile media include dynamic memory, such as system random-access memory (RAM). Transmission media include coaxial cables, copper wire and fiber optics, among others, including the wires that comprise one embodiment of a bus. Transmission media can also take the form of acoustic or light waves, such as those generated during radio frequency (RF) and infrared (IR) data communications. Common forms of computer-readable media include, for example, a floppy disk, a flexible disk, a hard disk, magnetic tape, any other magnetic medium, a CD-ROM disk, digital video disk (DVD), any other optical medium, any other physical medium with patterns of marks or holes, a RAM, a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a Flash memory, any other memory chip or data exchange adapter, a carrier wave, or any other medium from which a computer can read.
Various forms of computer-readable media may be involved in carrying one or more sequences of one or more instructions to a CPU for execution. A bus carries the data to system RAM, from which a CPU retrieves and executes the instructions. The instructions received by system RAM can optionally be stored on a fixed disk either before or after execution by a CPU.
Computer program code for carrying out operations for aspects of the present technology may be written in any combination of one or more programming languages, including an object oriented programming language such as JAVA, SMALLTALK, C++ or the like and procedural programming languages, such as the “C” programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).
The corresponding structures, materials, acts, and equivalents of all means or step plus function elements in the claims below are intended to include any structure, material, or act for performing the function in combination with other claimed elements as specifically claimed. The description of the present technology has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the invention. Exemplary embodiments were chosen and described in order to best explain the principles of the present technology and its practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.
Aspects of the present technology are described above with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.
The computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present technology. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
The description of the present technology has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the invention. Exemplary embodiments were chosen and described in order to best explain the principles of the present technology and its practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.
This application is a continuation-in-part of U.S. patent application Ser. No. 16/011,479, filed Jun. 18, 2018 and issued Sep. 8, 2020 as U.S. Pat. No. 10,771,396, which is a continuation-in-part of U.S. patent application Ser. No. 15/974,308, filed May 8, 2018, which is a continuation of U.S. patent application Ser. No. 15/251,977, filed Aug. 30, 2016 and issued Jun. 26, 2018 as U.S. Pat. No. 10,009,286, which is a continuation-in-part of U.S. patent application Ser. No. 14/708,132, filed May 8, 2015 and issued Dec. 13, 2016, as U.S. Pat. No. 9,521,069, the disclosures of which are incorporated by reference for all purposes. This application is related to U.S. patent application Ser. No. 12/139,336, filed Jun. 13, 2008 and issued Aug. 12, 2014, as U.S. Pat. No. 8,804,697, the disclosure of which is incorporated by reference for all purposes.
| Number | Name | Date | Kind |
|---|---|---|---|
| 5323444 | Ertz et al. | Jun 1994 | A |
| 5425085 | Weinberger et al. | Jun 1995 | A |
| 5463595 | Rodhall et al. | Oct 1995 | A |
| 5519769 | Weinberger et al. | May 1996 | A |
| 5596625 | LeBlanc | Jan 1997 | A |
| 5598460 | Tendler | Jan 1997 | A |
| 5796736 | Suzuki | Aug 1998 | A |
| 5999611 | Tatchell et al. | Dec 1999 | A |
| 6023724 | Bhatia et al. | Feb 2000 | A |
| 6128481 | Houde et al. | Oct 2000 | A |
| 6148190 | Bugnon et al. | Nov 2000 | A |
| 6201856 | Orwick et al. | Mar 2001 | B1 |
| 6202169 | Razzaghe-Ashrafi | Mar 2001 | B1 |
| 6266397 | Stoner | Jul 2001 | B1 |
| 6377938 | Block et al. | Apr 2002 | B1 |
| 6487197 | Elliott | Nov 2002 | B1 |
| 6594246 | Jorgensen | Jul 2003 | B1 |
| 6615264 | Stoltz et al. | Sep 2003 | B1 |
| 6661340 | Saylor et al. | Dec 2003 | B1 |
| 6690932 | Barnier et al. | Feb 2004 | B1 |
| 6697358 | Bernstein | Feb 2004 | B2 |
| 6714545 | Hugenberg et al. | Mar 2004 | B1 |
| 6775267 | Kung et al. | Aug 2004 | B1 |
| 6778517 | Lou et al. | Aug 2004 | B1 |
| 6778528 | Blair et al. | Aug 2004 | B1 |
| 6781983 | Armistead | Aug 2004 | B1 |
| 6914900 | Komatsu et al. | Jul 2005 | B1 |
| 6934258 | Smith et al. | Aug 2005 | B1 |
| 7113090 | Saylor et al. | Sep 2006 | B1 |
| 7124506 | Yamanashi et al. | Oct 2006 | B2 |
| 7127043 | Morris | Oct 2006 | B2 |
| 7127506 | Schmidt et al. | Oct 2006 | B1 |
| 7154891 | Callon | Dec 2006 | B1 |
| 7280495 | Zweig et al. | Oct 2007 | B1 |
| 7295660 | Higginbotham et al. | Nov 2007 | B1 |
| 7342925 | Cherchali et al. | Mar 2008 | B2 |
| 7376124 | Lee et al. | May 2008 | B2 |
| 7394803 | Petit-Huguenin et al. | Jul 2008 | B1 |
| 7599356 | Barzegar et al. | Oct 2009 | B1 |
| 7733859 | Takahashi et al. | Jun 2010 | B2 |
| 7844034 | Oh et al. | Nov 2010 | B1 |
| 8098798 | Goldman et al. | Jan 2012 | B2 |
| 8140392 | Altberg et al. | Mar 2012 | B2 |
| 8180316 | Hwang | May 2012 | B2 |
| 8208955 | Nelson | Jun 2012 | B1 |
| 8331547 | Smith et al. | Dec 2012 | B2 |
| 8350694 | Trundle et al. | Jan 2013 | B1 |
| 8515021 | Farrand et al. | Aug 2013 | B2 |
| 8577000 | Brown | Nov 2013 | B1 |
| 8634520 | Morrison et al. | Jan 2014 | B1 |
| 8837698 | Altberg et al. | Sep 2014 | B2 |
| 8988232 | Sloo et al. | Mar 2015 | B1 |
| 9087515 | Tsuda | Jul 2015 | B2 |
| 9147054 | Beal et al. | Sep 2015 | B1 |
| 9179279 | Zussman | Nov 2015 | B2 |
| 9225626 | Capper et al. | Dec 2015 | B2 |
| 9386148 | Farrand et al. | Jul 2016 | B2 |
| 9386414 | Mayor et al. | Jul 2016 | B1 |
| 9426288 | Farrand et al. | Aug 2016 | B2 |
| 9521069 | Gillon et al. | Dec 2016 | B2 |
| 9560198 | Farrand et al. | Jan 2017 | B2 |
| 9633547 | Farrand et al. | Apr 2017 | B2 |
| 9667782 | Farrand et al. | May 2017 | B2 |
| 9787611 | Gillon et al. | Oct 2017 | B2 |
| 9826372 | Jeong | Nov 2017 | B2 |
| 9905103 | Hsieh | Feb 2018 | B2 |
| 9929981 | Gillon et al. | Mar 2018 | B2 |
| 10009286 | Gillon et al. | Jun 2018 | B2 |
| 10116796 | Im et al. | Oct 2018 | B2 |
| 10135976 | Farrand et al. | Nov 2018 | B2 |
| 10158584 | Gillon et al. | Dec 2018 | B2 |
| 10192546 | Piersol et al. | Jan 2019 | B1 |
| 10255792 | Farrand et al. | Apr 2019 | B2 |
| 10263918 | Gillon et al. | Apr 2019 | B2 |
| 10297250 | Blanksteen et al. | May 2019 | B1 |
| 10341490 | Im et al. | Jul 2019 | B2 |
| 10469556 | Frame et al. | Nov 2019 | B2 |
| 10553098 | Hart et al. | Feb 2020 | B2 |
| 10728386 | Farrand et al. | Jul 2020 | B2 |
| 10769931 | Krein et al. | Sep 2020 | B2 |
| 10771396 | Osterlund et al. | Sep 2020 | B2 |
| 10818158 | Farrand et al. | Oct 2020 | B2 |
| 20010053194 | Johnson | Dec 2001 | A1 |
| 20020016718 | Rothschild et al. | Feb 2002 | A1 |
| 20020035556 | Shah et al. | Mar 2002 | A1 |
| 20020037750 | Hussain et al. | Mar 2002 | A1 |
| 20020038167 | Chirnomas | Mar 2002 | A1 |
| 20020057764 | Salvucci et al. | May 2002 | A1 |
| 20020085692 | Katz | Jul 2002 | A1 |
| 20020130784 | Suzuki et al. | Sep 2002 | A1 |
| 20020133614 | Weerahandi et al. | Sep 2002 | A1 |
| 20020140549 | Tseng | Oct 2002 | A1 |
| 20020165966 | Widegren et al. | Nov 2002 | A1 |
| 20030027602 | Han et al. | Feb 2003 | A1 |
| 20030058844 | Sojka et al. | Mar 2003 | A1 |
| 20030099334 | Contractor | May 2003 | A1 |
| 20030119492 | Timmins et al. | Jun 2003 | A1 |
| 20030133443 | Klinker et al. | Jul 2003 | A1 |
| 20030141093 | Tirosh et al. | Jul 2003 | A1 |
| 20030158940 | Leigh | Aug 2003 | A1 |
| 20030164877 | Murai | Sep 2003 | A1 |
| 20030184436 | Seales et al. | Oct 2003 | A1 |
| 20030189928 | Xiong | Oct 2003 | A1 |
| 20040001512 | Challener et al. | Jan 2004 | A1 |
| 20040010472 | Hilby et al. | Jan 2004 | A1 |
| 20040010569 | Thomas et al. | Jan 2004 | A1 |
| 20040017803 | Lim et al. | Jan 2004 | A1 |
| 20040059821 | Tang et al. | Mar 2004 | A1 |
| 20040062373 | Baker | Apr 2004 | A1 |
| 20040086093 | Schranz | May 2004 | A1 |
| 20040090968 | Kimber et al. | May 2004 | A1 |
| 20040105444 | Korotin et al. | Jun 2004 | A1 |
| 20040160956 | Hardy et al. | Aug 2004 | A1 |
| 20040235509 | Burritt et al. | Nov 2004 | A1 |
| 20050027887 | Zimler et al. | Feb 2005 | A1 |
| 20050036590 | Pearson et al. | Feb 2005 | A1 |
| 20050053209 | D'Evelyn et al. | Mar 2005 | A1 |
| 20050074114 | Fotta et al. | Apr 2005 | A1 |
| 20050078681 | Sanuki et al. | Apr 2005 | A1 |
| 20050089018 | Schessel | Apr 2005 | A1 |
| 20050097222 | Jiang et al. | May 2005 | A1 |
| 20050105708 | Kouchri et al. | May 2005 | A1 |
| 20050141485 | Miyajima et al. | Jun 2005 | A1 |
| 20050169247 | Chen | Aug 2005 | A1 |
| 20050180549 | Chiu et al. | Aug 2005 | A1 |
| 20050222820 | Chung | Oct 2005 | A1 |
| 20050238034 | Gillespie et al. | Oct 2005 | A1 |
| 20050238142 | Winegarden | Oct 2005 | A1 |
| 20050246174 | DeGolia | Nov 2005 | A1 |
| 20050259637 | Chu et al. | Nov 2005 | A1 |
| 20050282518 | D'Evelyn et al. | Dec 2005 | A1 |
| 20050287979 | Rollender | Dec 2005 | A1 |
| 20060007915 | Frame | Jan 2006 | A1 |
| 20060009240 | Katz | Jan 2006 | A1 |
| 20060013195 | Son et al. | Jan 2006 | A1 |
| 20060059238 | Slater et al. | Mar 2006 | A1 |
| 20060071775 | Otto et al. | Apr 2006 | A1 |
| 20060092011 | Simon et al. | May 2006 | A1 |
| 20060114894 | Cherchali et al. | Jun 2006 | A1 |
| 20060140352 | Morris | Jun 2006 | A1 |
| 20060156251 | Suhail et al. | Jul 2006 | A1 |
| 20060167746 | Zucker | Jul 2006 | A1 |
| 20060187898 | Chou et al. | Aug 2006 | A1 |
| 20060187900 | Akbar et al. | Aug 2006 | A1 |
| 20060206933 | Molen | Sep 2006 | A1 |
| 20060243797 | Apte et al. | Nov 2006 | A1 |
| 20060251048 | Yoshino et al. | Nov 2006 | A1 |
| 20060258341 | Miller et al. | Nov 2006 | A1 |
| 20060259767 | Mansz et al. | Nov 2006 | A1 |
| 20060268828 | Yarlagadda | Nov 2006 | A1 |
| 20060268848 | Larsson et al. | Nov 2006 | A1 |
| 20070030161 | Yang | Feb 2007 | A1 |
| 20070032220 | Feher | Feb 2007 | A1 |
| 20070036314 | Kloberdans et al. | Feb 2007 | A1 |
| 20070037560 | Yun et al. | Feb 2007 | A1 |
| 20070037605 | Logan | Feb 2007 | A1 |
| 20070041517 | Clarke et al. | Feb 2007 | A1 |
| 20070049342 | Mayer et al. | Mar 2007 | A1 |
| 20070054645 | Pan | Mar 2007 | A1 |
| 20070061363 | Ramer et al. | Mar 2007 | A1 |
| 20070061735 | Hoffberg et al. | Mar 2007 | A1 |
| 20070067219 | Altberg et al. | Mar 2007 | A1 |
| 20070071212 | Quittek et al. | Mar 2007 | A1 |
| 20070118750 | Owen et al. | May 2007 | A1 |
| 20070121593 | Vance et al. | May 2007 | A1 |
| 20070121596 | Kurapati et al. | May 2007 | A1 |
| 20070132844 | Katz | Jun 2007 | A1 |
| 20070133757 | Girouard et al. | Jun 2007 | A1 |
| 20070135088 | Alessandro | Jun 2007 | A1 |
| 20070153776 | Joseph et al. | Jul 2007 | A1 |
| 20070165811 | Reumann et al. | Jul 2007 | A1 |
| 20070183407 | Bennett et al. | Aug 2007 | A1 |
| 20070203999 | Townsley et al. | Aug 2007 | A1 |
| 20070223455 | Chang et al. | Sep 2007 | A1 |
| 20070238472 | Wanless | Oct 2007 | A1 |
| 20070255702 | Orme | Nov 2007 | A1 |
| 20070283430 | Lai et al. | Dec 2007 | A1 |
| 20070298772 | Owens et al. | Dec 2007 | A1 |
| 20080016556 | Selignan | Jan 2008 | A1 |
| 20080036585 | Gould | Feb 2008 | A1 |
| 20080049748 | Bugenhagen et al. | Feb 2008 | A1 |
| 20080075248 | Kim | Mar 2008 | A1 |
| 20080075257 | Nguyen et al. | Mar 2008 | A1 |
| 20080084975 | Schwartz | Apr 2008 | A1 |
| 20080089325 | Sung | Apr 2008 | A1 |
| 20080097819 | Whitman, Jr. | Apr 2008 | A1 |
| 20080111765 | Kim | May 2008 | A1 |
| 20080118039 | Elliot et al. | May 2008 | A1 |
| 20080125095 | Mornhineway et al. | May 2008 | A1 |
| 20080125964 | Carani et al. | May 2008 | A1 |
| 20080144625 | Wu et al. | Jun 2008 | A1 |
| 20080144884 | Habibi | Jun 2008 | A1 |
| 20080159515 | Rines | Jul 2008 | A1 |
| 20080166992 | Ricordi et al. | Jul 2008 | A1 |
| 20080168145 | Wilson | Jul 2008 | A1 |
| 20080196099 | Shastri | Aug 2008 | A1 |
| 20080200142 | Abdel-Kader et al. | Aug 2008 | A1 |
| 20080205386 | Purnadi et al. | Aug 2008 | A1 |
| 20080225749 | Peng et al. | Sep 2008 | A1 |
| 20080247401 | Bhal et al. | Oct 2008 | A1 |
| 20080293374 | Berger | Nov 2008 | A1 |
| 20080298348 | Frame et al. | Dec 2008 | A1 |
| 20080309486 | McKenna et al. | Dec 2008 | A1 |
| 20080310599 | Purnadi et al. | Dec 2008 | A1 |
| 20080313297 | Heron et al. | Dec 2008 | A1 |
| 20080316946 | Capper et al. | Dec 2008 | A1 |
| 20090097474 | Ray et al. | Apr 2009 | A1 |
| 20090106318 | Mantripragada, Sr. et al. | Apr 2009 | A1 |
| 20090135008 | Kirchmeier et al. | May 2009 | A1 |
| 20090168755 | Peng et al. | Jul 2009 | A1 |
| 20090172131 | Sullivan | Jul 2009 | A1 |
| 20090175165 | Leighton | Jul 2009 | A1 |
| 20090186596 | Kaltsukis | Jul 2009 | A1 |
| 20090213999 | Farrand et al. | Aug 2009 | A1 |
| 20090224931 | Dietz et al. | Sep 2009 | A1 |
| 20090240586 | Ramer et al. | Sep 2009 | A1 |
| 20090253428 | Bhatia et al. | Oct 2009 | A1 |
| 20090261958 | Sundararajan et al. | Oct 2009 | A1 |
| 20090264093 | Rothschild | Oct 2009 | A1 |
| 20090295572 | Grim, III et al. | Dec 2009 | A1 |
| 20090303042 | Song et al. | Dec 2009 | A1 |
| 20090319271 | Gross | Dec 2009 | A1 |
| 20100003960 | Ray et al. | Jan 2010 | A1 |
| 20100034121 | Bozionek | Feb 2010 | A1 |
| 20100046530 | Hautakorpi et al. | Feb 2010 | A1 |
| 20100046731 | Gisby et al. | Feb 2010 | A1 |
| 20100077063 | Amit | Mar 2010 | A1 |
| 20100098034 | Tang et al. | Apr 2010 | A1 |
| 20100098058 | Delangis | Apr 2010 | A1 |
| 20100098235 | Cadiz et al. | Apr 2010 | A1 |
| 20100114896 | Clark et al. | May 2010 | A1 |
| 20100136982 | Zabawskyj et al. | Jun 2010 | A1 |
| 20100158223 | Fang et al. | Jun 2010 | A1 |
| 20100191829 | Cagenius | Jul 2010 | A1 |
| 20100195805 | Zeigler et al. | Aug 2010 | A1 |
| 20100215153 | Ray et al. | Aug 2010 | A1 |
| 20100220840 | Ray et al. | Sep 2010 | A1 |
| 20100229452 | Suk | Sep 2010 | A1 |
| 20100246781 | Bradbum | Sep 2010 | A1 |
| 20100261448 | Peters | Oct 2010 | A1 |
| 20100277307 | Horton et al. | Nov 2010 | A1 |
| 20100302025 | Script | Dec 2010 | A1 |
| 20110013591 | Kakumaru | Jan 2011 | A1 |
| 20110047031 | Weerasinghe | Feb 2011 | A1 |
| 20110054689 | Nielsen et al. | Mar 2011 | A1 |
| 20110111728 | Ferguson et al. | May 2011 | A1 |
| 20110140868 | Hovang | Jun 2011 | A1 |
| 20110151791 | Snider et al. | Jun 2011 | A1 |
| 20110170680 | Chislett et al. | Jul 2011 | A1 |
| 20110183652 | Eng et al. | Jul 2011 | A1 |
| 20110208822 | Rathod | Aug 2011 | A1 |
| 20110265145 | Prasad et al. | Oct 2011 | A1 |
| 20110286462 | Kompella | Nov 2011 | A1 |
| 20110320274 | Patil | Dec 2011 | A1 |
| 20120009904 | Modi et al. | Jan 2012 | A1 |
| 20120010955 | Ramer et al. | Jan 2012 | A1 |
| 20120027191 | Baril et al. | Feb 2012 | A1 |
| 20120035993 | Nangia | Feb 2012 | A1 |
| 20120036576 | Iyer | Feb 2012 | A1 |
| 20120047442 | Nicolaou et al. | Feb 2012 | A1 |
| 20120092158 | Kumbhar et al. | Apr 2012 | A1 |
| 20120099716 | Rae et al. | Apr 2012 | A1 |
| 20120166582 | Binder | Jun 2012 | A1 |
| 20120167086 | Lee | Jun 2012 | A1 |
| 20120177052 | Chen et al. | Jul 2012 | A1 |
| 20120178404 | Chin et al. | Jul 2012 | A1 |
| 20120180122 | Yan et al. | Jul 2012 | A1 |
| 20120213094 | Zhang | Aug 2012 | A1 |
| 20120265528 | Gruber et al. | Oct 2012 | A1 |
| 20120284778 | Chiou et al. | Nov 2012 | A1 |
| 20120320905 | Ilagan | Dec 2012 | A1 |
| 20120329420 | Zotti et al. | Dec 2012 | A1 |
| 20130018509 | Korus | Jan 2013 | A1 |
| 20130024197 | Jang et al. | Jan 2013 | A1 |
| 20130035774 | Warren et al. | Feb 2013 | A1 |
| 20130052982 | Rohde et al. | Feb 2013 | A1 |
| 20130053005 | Ramer et al. | Feb 2013 | A1 |
| 20130070928 | Ellis et al. | Mar 2013 | A1 |
| 20130111589 | Cho | May 2013 | A1 |
| 20130136241 | Dillon et al. | May 2013 | A1 |
| 20130154822 | Kumar et al. | Jun 2013 | A1 |
| 20130162160 | Ganton | Jun 2013 | A1 |
| 20130162758 | Shin | Jun 2013 | A1 |
| 20130214925 | Weiss | Aug 2013 | A1 |
| 20130229282 | Brent | Sep 2013 | A1 |
| 20130267791 | Halperin et al. | Oct 2013 | A1 |
| 20130272219 | Singh et al. | Oct 2013 | A1 |
| 20130276084 | Canard et al. | Oct 2013 | A1 |
| 20130288639 | Varsaysky Waisman-Diamond | Oct 2013 | A1 |
| 20130293368 | Ottah et al. | Nov 2013 | A1 |
| 20130336174 | Rubin et al. | Dec 2013 | A1 |
| 20140011470 | D'Amato et al. | Jan 2014 | A1 |
| 20140022915 | Caron et al. | Jan 2014 | A1 |
| 20140038536 | Welnick et al. | Feb 2014 | A1 |
| 20140066063 | Park | Mar 2014 | A1 |
| 20140084165 | Fadell et al. | Mar 2014 | A1 |
| 20140085093 | Mittleman et al. | Mar 2014 | A1 |
| 20140101082 | Matsuoka et al. | Apr 2014 | A1 |
| 20140120863 | Ferguson et al. | May 2014 | A1 |
| 20140129942 | Rathod | May 2014 | A1 |
| 20140156279 | Okamoto et al. | Jun 2014 | A1 |
| 20140169274 | Kweon et al. | Jun 2014 | A1 |
| 20140172953 | Blanksteen | Jun 2014 | A1 |
| 20140181865 | Koganei | Jun 2014 | A1 |
| 20140199946 | Flippo et al. | Jul 2014 | A1 |
| 20140206279 | Immendorf et al. | Jul 2014 | A1 |
| 20140207929 | Hoshino et al. | Jul 2014 | A1 |
| 20140222436 | Binder et al. | Aug 2014 | A1 |
| 20140253326 | Cho et al. | Sep 2014 | A1 |
| 20140266699 | Poder et al. | Sep 2014 | A1 |
| 20140273912 | Peh et al. | Sep 2014 | A1 |
| 20140273979 | Van Os et al. | Sep 2014 | A1 |
| 20140280870 | Shrivastava et al. | Sep 2014 | A1 |
| 20140306802 | Hibbs, Jr. | Oct 2014 | A1 |
| 20140334645 | Yun et al. | Nov 2014 | A1 |
| 20140358666 | Baghaie et al. | Dec 2014 | A1 |
| 20150065078 | Mejia et al. | Mar 2015 | A1 |
| 20150071450 | Boyden et al. | Mar 2015 | A1 |
| 20150082451 | Ciancio-Bunch | Mar 2015 | A1 |
| 20150086001 | Farrand et al. | Mar 2015 | A1 |
| 20150087280 | Farrand et al. | Mar 2015 | A1 |
| 20150088514 | Typrin | Mar 2015 | A1 |
| 20150089032 | Agarwal | Mar 2015 | A1 |
| 20150100167 | Sloo et al. | Apr 2015 | A1 |
| 20150117624 | Rosenshine | Apr 2015 | A1 |
| 20150138333 | DeVaul et al. | May 2015 | A1 |
| 20150145693 | Toriumi et al. | May 2015 | A1 |
| 20150177114 | Kapoor et al. | Jun 2015 | A1 |
| 20150200973 | Nolan | Jul 2015 | A1 |
| 20150221207 | Hagan | Aug 2015 | A1 |
| 20150229770 | Shuman et al. | Aug 2015 | A1 |
| 20150242932 | Beguin et al. | Aug 2015 | A1 |
| 20150244873 | Boyden et al. | Aug 2015 | A1 |
| 20150255071 | Chiba | Sep 2015 | A1 |
| 20150262435 | Delong et al. | Sep 2015 | A1 |
| 20150281450 | Shapiro et al. | Oct 2015 | A1 |
| 20150302725 | Sager et al. | Oct 2015 | A1 |
| 20150327039 | Jain | Nov 2015 | A1 |
| 20150334227 | Whitten et al. | Nov 2015 | A1 |
| 20150339912 | Farrand | Nov 2015 | A1 |
| 20150358795 | You et al. | Dec 2015 | A1 |
| 20150379562 | Spievak et al. | Dec 2015 | A1 |
| 20150381563 | Seo et al. | Dec 2015 | A1 |
| 20160006837 | Reynolds et al. | Jan 2016 | A1 |
| 20160012702 | Hart et al. | Jan 2016 | A1 |
| 20160036751 | Ban | Feb 2016 | A1 |
| 20160036962 | Rand | Feb 2016 | A1 |
| 20160066011 | Ro et al. | Mar 2016 | A1 |
| 20160078750 | King et al. | Mar 2016 | A1 |
| 20160117684 | Khor et al. | Apr 2016 | A1 |
| 20160142758 | Karp et al. | May 2016 | A1 |
| 20160150024 | White | May 2016 | A1 |
| 20160173693 | Spievak et al. | Jun 2016 | A1 |
| 20160219150 | Brown | Jul 2016 | A1 |
| 20160232774 | Noland et al. | Aug 2016 | A1 |
| 20160248847 | Saxena et al. | Aug 2016 | A1 |
| 20160260431 | Newendorp et al. | Sep 2016 | A1 |
| 20160260436 | Lemay et al. | Sep 2016 | A1 |
| 20160269882 | Balthasar et al. | Sep 2016 | A1 |
| 20160277573 | Farrand et al. | Sep 2016 | A1 |
| 20160300260 | Cigich et al. | Oct 2016 | A1 |
| 20160315909 | von Gravrock | Oct 2016 | A1 |
| 20160323446 | Farrand et al. | Nov 2016 | A1 |
| 20160330069 | Nordmark et al. | Nov 2016 | A1 |
| 20160330108 | Gillon et al. | Nov 2016 | A1 |
| 20160330319 | Farrand et al. | Nov 2016 | A1 |
| 20160330770 | Lee et al. | Nov 2016 | A1 |
| 20160373372 | Gillon et al. | Dec 2016 | A1 |
| 20170021802 | Mims | Jan 2017 | A1 |
| 20170024995 | Gu et al. | Jan 2017 | A1 |
| 20170034044 | Gillon et al. | Feb 2017 | A1 |
| 20170034045 | Gillon et al. | Feb 2017 | A1 |
| 20170034062 | Gillon et al. | Feb 2017 | A1 |
| 20170034081 | Gillon et al. | Feb 2017 | A1 |
| 20170084164 | Farrand et al. | Mar 2017 | A1 |
| 20170104875 | Im et al. | Apr 2017 | A1 |
| 20170188216 | Koskas et al. | Jun 2017 | A1 |
| 20170270569 | Altberg et al. | Sep 2017 | A1 |
| 20170272316 | Johnson et al. | Sep 2017 | A1 |
| 20170293301 | Myslinski | Oct 2017 | A1 |
| 20170339228 | Azgin et al. | Nov 2017 | A1 |
| 20180005125 | Fadell et al. | Jan 2018 | A1 |
| 20180061213 | Morehead | Mar 2018 | A1 |
| 20180075540 | Bernard et al. | Mar 2018 | A1 |
| 20180152557 | White et al. | May 2018 | A1 |
| 20180182380 | Fritz et al. | Jun 2018 | A1 |
| 20180262441 | Gillon et al. | Sep 2018 | A1 |
| 20180302334 | Osterlund et al. | Oct 2018 | A1 |
| 20180365969 | Krein et al. | Dec 2018 | A1 |
| 20180375927 | Nozawa | Dec 2018 | A1 |
| 20190014024 | Koshy | Jan 2019 | A1 |
| 20190028587 | Unitt et al. | Jan 2019 | A1 |
| 20190044641 | Trundle et al. | Feb 2019 | A1 |
| 20190045058 | Im et al. | Feb 2019 | A1 |
| 20190052752 | Farrand et al. | Feb 2019 | A1 |
| 20190190942 | Drummond et al. | Jun 2019 | A1 |
| 20190206227 | Farrand et al. | Jul 2019 | A1 |
| 20190222993 | Maheshwari et al. | Jul 2019 | A1 |
| 20190385435 | Farrand et al. | Dec 2019 | A1 |
| 20200004989 | Lockhart, III et al. | Jan 2020 | A1 |
| 20200105082 | Joao | Apr 2020 | A1 |
| 20200126388 | Kranz | Apr 2020 | A1 |
| 20200143663 | Sol | May 2020 | A1 |
| 20200168073 | Hart et al. | May 2020 | A1 |
| 20200186644 | White et al. | Jun 2020 | A1 |
| 20200219378 | Farrand et al. | Jul 2020 | A1 |
| 20200250957 | Krein et al. | Aug 2020 | A1 |
| 20200322283 | Osterlund et al. | Oct 2020 | A1 |
| Number | Date | Country |
|---|---|---|
| 2949211 | Feb 2019 | CA |
| 2954351 | Apr 2020 | CA |
| 2187574 | May 2010 | EP |
| 3050287 | Aug 2016 | EP |
| 3146516 | Mar 2017 | EP |
| 3167340 | May 2017 | EP |
| 3295620 | Mar 2018 | EP |
| 3050287 | Dec 2018 | EP |
| 3585011 | Dec 2019 | EP |
| WO2015041738 | Mar 2015 | WO |
| WO2015179120 | Nov 2015 | WO |
| WO2016007244 | Jan 2016 | WO |
| WO2016182796 | Nov 2016 | WO |
| WO2018044657 | Mar 2018 | WO |
| Entry |
|---|
| “International Search Report” and “Written Opinion of the International Searching Authority,” dated Nov. 7, 2014 for App. No. PCT/US2014/044945, filed Jun. 30, 2014. 12 pages. |
| “International Search Report” and “Written Opinion of the International Searching Authority,” dated Jul. 27, 2015 for App. No. PCT/US2015/029109, filed May 4, 2015, 12 pages. |
| “International Search Report” and “Written Opinion of the International Searching Authority,” dated Nov. 2, 2015 for App. No. PCT/US2015/034054, filed Jun. 3, 2015, 15 pages. |
| Life Alert. “Life Alert's Four Layers of Protection, First Layer of Protection: Protection at Home.” https://web.archive.org/web/20121127094247/http://www.lifealert.net/products/homeprotection.html. [retrieved Oct. 13, 2015], 4 pages. |
| “International Search Report” and “Written Opinion of the International Searching Authority,” dated Jun. 30, 2016 for App. No. PCT/US2016/030597, filed May 3, 2016, 12 pages. |
| “Extended European Search Report,” European Patent Application No. 14845956.3, dated Feb. 16, 2017, 8 pages. |
| “Office Action,” Canadian Patent Application No. 2949211, dated Aug. 16, 2017, 4 pages. |
| “Office Action,” Canadian Patent Application No. 2954351, dated Oct. 27, 2017, 3 pages. |
| “International Search Report” and “Written Opinion of the International Searching Authority,” Patent Cooperation Treaty Application No. PCT/US2017/048284, dated Nov. 8, 2017, 8 pages. |
| “Extended European Search Report,” European Patent Application No. 15796148.3, dated Jan. 8, 2018, 8 pages. |
| “Office Action,” European Patent Application No. 14845956.3, dated Apr. 9, 2018, 4 pages. |
| “Extended European Search Report,” European Patent Application No. 15818258.4, dated Feb. 26, 2018, 8 pages. |
| “Notice of Allowance,” European Patent Application No. 14845956.3, dated Jul. 11, 2018, 7 pages. |
| “Notice of Allowance”, Canadian Patent Application No. 2949211, dated Jul. 31, 2018, 1 page. |
| “Office Action,” Canadian Patent Application No. 2954351, dated Aug. 22, 2018, 4 pages. |
| Vaidya, Govind, “Automatic Object Detection and Recognition via a Camera System”, U.S. Appl. No. 16/163,521, filed Oct. 17, 2018, 40 pages. |
| “Partial Supplementary European Search Report,” European Patent Application No. 16793194.8, dated Nov. 19, 2018, 10 pages. |
| “Extended European Search Report,” European Patent Application No. 16793194.8, dated Feb. 26, 2019, 9 pages. |
| “Office Action,” European Patent Application No. 16793194.8, dated Jun. 9, 2020, 4 pages. |
| “Extended European Search Report,” European Patent Application No. 19187593.9, dated Nov. 13, 2019, 8 pages. |
| Takahashi et al. “A Hybrid FEC Method Using Packet-Level Convolution and Reed-Solomon Codes,” IEICE Transaction on Communications, Communications Society, vol. E89-B, No. 8, Aug. 1, 2006. pp. 2143-2151. |
| “Office Action,” Canadian Patent Application No. 2924631, dated Jul. 14, 2020, 5 pages. |
| Smarter Home Life: “Hello Bixby Samsung Launches 5th Virtual Assistant Platform, SmartThings—embedded Wi-Fi router,” [onlin], [retrieved on Jun. 18, 2020], Retrieved from the Internet: <URL: https://smarterhomelife.com/everything/2017/3/30/hello-bixby-samsung-launches-5th-virtual-assistant-platform-smartthings-embedded-wi-fi-router>. |
| “Notice of Allowance”, Canadian Patent Application No. 2954351, dated Aug. 27, 2019, 1 page. |
| “Office Action,” European Patent Application No. 15796148.3, dated Jan. 29, 2020, 6 pages. |
| “Office Action,” European Patent Application No. 15818258.4, dated Jan. 31, 2020, 5 pages. |
| “Notice of Allowance”, European Patent Application No. 15818258.4, dated Oct. 2, 2020, 7 pages. |
| Number | Date | Country | |
|---|---|---|---|
| 20180324105 A1 | Nov 2018 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 15251977 | Aug 2016 | US |
| Child | 15974308 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 16011479 | Jun 2018 | US |
| Child | 16034262 | US | |
| Parent | 15974308 | May 2018 | US |
| Child | 16011479 | US | |
| Parent | 14708132 | May 2015 | US |
| Child | 15251977 | US |
