Subnet-based Device Allocation Using Geofence Authentication

Abstract

An IoT hub including one or more servers and databases is configured to automatically assign IoT-enabled devices to IoT solutions based on the subnets to which Internet of Things (IoT) devices are connected. A user interface is configured to enable a user to define subnets within the customer's network environment and assign each subnet to an IoT solution. After the user establishes a network connection of an IoT device to a network device such as a router, the IoT device transmits its network information to the IoT hub. The IoT hub can then automatically assign the IoT device to a specific IoT solution without further user input or predict which IoT solution the IoT device is to utilize based on known parameters.

Description

Background Art

[0001] The Internet of Things (IoT) connects devices of various types, sizes, and functions via a network. For example, devices (or "things") in the IoT can be location tags, connected thermostats, monitoring cameras, sensor devices, industrial machines, or anything that can transmit data via a network connection. IoT devices typically have a way to connect to the Internet to report telemetry data to other devices and / or services and request / receive information from other devices or services.

[0002] IoT devices are typically connected to an IoT hub, which can be a collection of servers and databases operated by a cloud service provider, such that the IoT devices are associated with a customer account. This enables the customer to exercise control over the IoT devices and utilize the IoT solutions provided by the IoT hub. Summary of the Invention

[0003] The IoT hub is configured to automatically assign IoT devices to a specific IoT solution based on the subnet to which the IoT devices are connected. The IoT devices are configured for connectivity with networked devices (such as routers or gateways) that support forwarding packets to the IoT hub. At the initiation of a communication session, the IoT device sends network information to the IoT hub, which uses the network information to allocate a specific IoT solution for the IoT device. The IoT solution can include software configured to support and interoperate with specific IoT device functionality. For example, the IoT solution can include artificial intelligence and machine learning algorithms and processes, analytics tools, automated operations, and data storage, as well as other solutions. The IoT hub monitors to help customers maintain the health of their solutions by tracking events such as device creation, device failures, and device connections.

[0004] Subnets are generally defined by networked devices that the IoT devices use for network connectivity. In some embodiments, multiple subnets can be created behind a single networked device by using subnet masks and reconfiguring the IP (Internet Protocol) addresses for the host IoT devices. IoT device users (such as customers for IoT solutions) can use an IoT device management application capable of communicating with the service provider to set network configurations, create subnets, and assign IoT device subnets to specific IoT solutions.

[0005] Network configurations can include grouping codes for IoT devices, which IoT hubs can utilize to implement various IoT solution connectivity options. For example, options can include an IoT hub that automatically assigns newly connected IoT devices to an IoT solution to which existing device groups from the same subnet are connected. Additional options enabled by the grouping codes utilized by the IoT hub may involve the application of predictive algorithms. The IoT hub can apply algorithms to predict IoT devices and assign them to IoT solutions without relying on user input. The prediction can be performed using hard-coded rules or machine learning techniques (using various parameters available at the IoT hub). Illustrative machine learning parameters can include the IoT device serial number, type, model, type of sensors utilized, type of data aggregated, subnet to which the IoT device is connected, and the geofence within which the IoT device is located. The IoT hub can use the predicted device grouping to shorten the IoT device setup and deployment time and reduce the administrative overhead for customers.

[0006] By associating IoT devices with geofences (i.e., defined geographical areas), geofence authentication can also be used as a tool to simplify the verification of IoT devices while increasing device and network security for users. When the IoT device is within the geofence, the IoT hub enables connection to the appropriate IoT solution. Otherwise, the IoT hub rejects the IoT device connection.

[0007] Geofence authentication may occur when an IoT device initiates a connection request to the IoT hub. During this process, the IoT device transmits authentication credentials, network information (such as for the subnet-based assignment characteristics discussed above), and its current location that the IoT hub uses to confirm the location of the IoT device. The IoT device can transmit its current location periodically to enhance its security, thereby confirming that it has not been stolen, misplaced, or compromised, for example, by malware.

[0008] Alternatively, the entire connection request process can be performed periodically. For example, in response to verification, the IoT hub can assign a unique token to the IoT device, where the token is assigned a duration after which it expires. For an IoT device to continue using the IoT solution, it re-verifies its location with the IoT hub at least to receive another pair of time-sensitive tokens.

[0009] The assignment of IoT devices based on subnet connectivity and geofencing authentication features provides a simplified process for connecting, managing, and enhancing the security of IoT devices. Using subnet-based connectivity to an IoT solution enables fine-grained control of IoT devices using a hybrid of manual and automated methods, which can be supported by an IoT management application. The application can support a user interface (UI) that enables a user to manage their subnet-based IoT infrastructure. The IoT management application provides many technical benefits by reducing the setup time of the IoT network, accelerating IoT device implementation, and reducing errors when mapping an IoT solution to IoT devices.

[0010] The implementation of geofencing authentication also enhances network and device security by verifying that the IoT device location is within the defined geofence before granting a connection to the IoT solution. Periodic geofencing authentication can also improve security by enhancing the detection of lost, stolen, or compromised IoT devices.

[0011] The present invention content is provided to introduce a selection of concepts in a simplified form, which are further described in the detailed implementation below. The present invention content is neither intended to identify the key features or essential features of the claimed subject matter, nor is it intended to be used to assist in determining the scope of the claimed subject matter. In addition, the claimed subject matter is not limited to solving any or all of the disadvantages mentioned in any part of this disclosure. It should be understood that the subject matter described above can be implemented as a computer-controlled device, a computer process, a computing system, or implemented as an article of manufacture, such as one or more computer-readable storage media. These and various other features will become apparent by reading the following detailed implementation and reviewing the associated drawings. Brief Description of the Drawings

[0012] Figure 1 An illustrative environment is shown in which an IoT device is connected to a local area network to utilize an IoT solution provided by an IoT hub;

[0013] Figure 2 An illustrative architecture of an IoT device is shown;

[0014] Figure 3 An illustrative definition of a subnet is shown;

[0015] Figure 4 An illustrative network device that can include a local area network (LAN) is shown;

[0016] Figure 5 An illustrative environment is shown in which a group of IoT devices is connected to a specific IoT solution based on the subnet to which the IoT devices are connected;

[0017] Figure 6 illustrates an illustrative environment in which connection requests and authentication messages are exchanged between an IoT device and an IoT hub;

[0018] Figure 7 illustrates an illustrative graphical user interface through which a customer is provided with manual control over selecting a subnet-based IoT solution;

[0019] Figure 8 illustrates an illustrative taxonomy of grouping codes that can be executed by an IoT hub to assign IoT devices to IoT solutions;

[0020] Figure 9 illustrates an illustrative environment in which an IoT hub automatically assigns IoT devices to IoT solutions;

[0021] Figure 10 illustrates an illustrative environment in which an IoT hub uses a prediction algorithm to assign IoT devices to IoT solutions;

[0022] Figure 11 illustrates a taxonomy that can be utilized by a machine learning algorithm to predict parameters of an IoT solution for an IoT device;

[0023] Figure 12 and Figure 13 illustrates an illustrative scenario in which an IoT hub selects an IoT solution using exemplary real-world data;

[0024] Figure 14 illustrates an illustrative geofence that is used to authenticate an IoT device with an IoT solution;

[0025] Figure 15 illustrates an illustrative flowchart by which an IoT hub verifies an IoT device;

[0026] Figures 16 - 18 illustrates an illustrative process executed by one or more of an IoT hub, an IoT device, or a user computing device;

[0027] Figure 19 is a block diagram of an illustrative data center that can be used, at least in part, to implement an existing subnet-based device allocation that utilizes geofence authentication;

[0028] Figure 20 is a simplified block diagram of an illustrative computing system or server that can be used, in part, to implement an existing subnet-based device allocation that utilizes geofence authentication; and

[0029] Figure 21 is a simplified block diagram of an illustrative computer system that can be used in part to implement an existing subnet-based device allocation that utilizes geofence authentication.

[0030] In the figures, like reference numerals indicate like elements. The elements are not drawn to scale unless otherwise indicated. Detailed Description

[0031] Customers can implement IoT devices to communicate with an IoT hub to manage certain functions and operations for the IoT devices. For example, the HVAC (heating, ventilation, and air conditioning) industry can utilize sensors (such as thermometers, thermostats, humidity sensors, etc.) to monitor conditions in real time, automate processes, and perform real-time diagnostics as conditions change. The HVAC department can be a department within a university, a manufacturing plant, or other department or division organization that implements IoT devices to manage tasks and operations. Each department within an organization can implement a large number of IoT devices to track all aspects of its industry, business, or operations. In some embodiments, a cloud service provider can assign IoT devices to the geographically closest IoT hub and solution.

[0032] An IoT hub can include a collection of servers and databases that are used with IoT applications to securely connect, monitor, and manage up to billions of devices. The IoT hub can be implemented as a managed service hosted in the cloud, which acts as a central message center for two-way communication between IoT applications and the devices they manage. The IoT hub supports communication both from devices to the cloud and from the cloud to devices. The IoT hub can support multiple messaging modes, such as device-to-cloud telemetry, file uploads from devices, and request-response methods for controlling devices from the cloud.

[0033] As discussed in more detail below, in an existing subnet-based device allocation that utilizes geofence authentication, the IoT hub assigns IoT devices to IoT solutions and verifies the IoT devices, but in some embodiments, a provisioning service operating on a different server can perform these operations and operate in concert with the IoT hub. Thus, references to the IoT hub indicate operations performed by a remote server and can represent operations performed by the provisioning service, the IoT hub, or both the IoT hub and the provisioning service.

[0034] Turning now to the figures, Figure 1Illustrative environment 100 is shown, in which several Internet of Things (IoT)-configured devices 105 are adapted to communicate via network 125 with an IoT hub 130 provided by a cloud service provider, which may include one or more remote servers and databases, respectively. The IoT devices may be utilized at a customer's premises and connected to network devices 120 (such as routers, access points, edge gateway devices, or other types of network connections) within the customer's local area network (LAN) 110 to utilize the IoT solutions 135 proposed by the IoT hub. The network infrastructure of the LAN may include one or more subnets 115 utilized by the IoT devices. The subnets may be different networks on the LAN that separate groups of IoT devices. The LAN may communicate with a core network 125 via one or more edge gateway devices, and the core network 125 routes messages to and from the IoT hub and may include a wide area network (WAN) and the Internet.

[0035] Figure 2 An illustrative and general architecture 200 of the IoT device 105 is shown. The IoT device may be interconnected and / or communicate via various networks and generally utilizes one or more sensors to gather relevant data useful for a particular device for a particular reason. The IoT device may utilize various sensors, actuators, software, network connectivity, and connections to remote servers (such as the IoT hub) to support and establish comprehensive knowledge, understanding, or insight into the component or its environment. As Figure 2 schematically shown, an exemplary IoT device 105 may include a commercial machine (such as a crane) or a household item (such as a light bulb, thermostat, etc.). However, these devices are merely illustrative, as the number, variety, and / or type of objects or components that can be configured as IoT devices are virtually unlimited. An exemplary motherboard including a system-on-chip (SoC) configuration is schematically shown, which may implement the IoT device or enable a device, component, or object to be transformed into an IoT-configured device.

[0036] The architecture is arranged in layers and includes a hardware layer 215, an operating system (OS) layer 210, and an application layer 205. The hardware layer 215 provides an abstraction of the various hardware used by the IoT device 105 to the layers above it. In this illustrative example, the hardware layer supports one or more processors 220, a memory 225, a NIC (network interface controller) 240, a trusted platform module (TPM) 230, various sensors 235 for gathering data, and a location component, such as a global positioning system (GPS) 245.

[0037] The NIC may include interfaces such as radio transceivers and ports to enable Ethernet, mobile broadband, or Wi-Fi connections to a network router, cellular tower, or access point. The NIC may transport data frames between network nodes (such as routers, switches, access points, etc.) using, for example, MAC (Media Access Control) addressing. The TPM may provide a trusted execution environment within the IoT device to enable secure processing and, for example, authenticate the IoT device using unique keys stored therein. The GPS may operate periodically or cyclically to verify the location of the IoT device. Depending on the particular IoT device and its application, different sets of one or more sensors may be implemented with the IoT device, such as temperature sensors, pressure sensors, barometers, proximity sensors, etc.

[0038] In this illustrative example, the application layer 205 supports various applications 265 including the auto-provisioning application 260. Any number of applications may be utilized by the IoT device 105, whether proprietary or third-party applications. The applications may be implemented using locally-executed code. However, in some situations, the applications may rely on services and / or remote code execution provided by a remote server or other computing platform. The auto-provisioning application may be a stand-alone application or a module within a larger application that performs various processes and tasks for the IoT device (collectively or individually referred to as the "auto-provisioning application"). The auto-provisioning application may be responsible for transmitting various information to the IoT hub 130 ( Figure 1 ) such as access credentials, location data, and network information such as the subnet to which the IoT device is connected.

[0039] Among other operations, the OS layer 210 also supports managing the operating system 250 and the operating applications 255. The OS layer may interoperate with the application layer and the hardware layer to support the execution of programs and perform various functions and features.

[0040] Figure 3 An illustrative diagram depicting the subnet 115 is shown, which provides the IoT device access to the LAN 110 ( Figure 1) access. A subnet can be defined as a part of a larger network (such as a WAN, LAN, etc.). In some embodiments, the subnet is formed by a gateway or network device 305 to which IoT devices are connected. For example, one or more IoT devices connected to the same router can be on the same subnet. One or more other IoT devices connected to different routers can be on separate subnets. A subnet can also be defined in a scenario where a subnet mask is utilized on a network device for IoT devices sharing the network prefix and subnet number in their IP (Internet Protocol) addresses, as representatively shown by the numeral 310. Thus, IoT devices connected to the same router can be divided into different subnets. An exemplary common subnet number (.83) for two different IoT devices or hosts connected to the same router is shown inside block 315. According to this common subnet number, the IoT devices for two corresponding IP addresses are on the same subnet. Thus, when using a subnet mask and a subnetting process, multiple subnets can be derived from a single network device.

[0041] Figure 4 An exemplary local area network (LAN) 405 is shown, which includes an edge gateway device 410, one or more routers 415, and subnets 420, which can be separate networks on the same router. Although Figure 4 a router with multiple subnets is shown, depending on the specific configuration of the router, the router may not be divided into separate subnets, or alternatively may be divided into more or fewer subnets. The router can communicate with the edge gateway device, which ultimately routes messages between the IoT hub and the routers within the LAN. As Figure 4 shown, each router and edge gateway device can also be considered a subnet for the LAN. Thus, although subnets can be based on different networks on the same router, the router itself can equally be a single subnet.

[0042] Figure 5Illustrates an illustrative environment in which a group 535 of IoT devices 105 are connected to specific IoT solutions based on the subnet to which the IoT devices are connected and utilize these specific IoT solutions. Each subnet 505, subnet 510, and subnet 515 may be associated, for example, with a specific department or division within an organization (such as an HVAC department, a technology department, and a manufacturing department), respectively. The IoT solutions utilized by the respective departments are analytics 520, data storage 525, and machine learning 530. Thus, since each department may use cloud services for different purposes, the IoT solutions used for a specific department may vary. The assignment of subnet-based IoT solutions supports a device-based virtual local area network (VLAN) environment. That is, the VLAN is composed of groups of IoT devices based on the subnet to which the IoT devices are connected, which can be divided by department or division, as illustratively shown.

[0043] Figure 6 Illustrates an illustrative environment in which an IoT device 105 uses an automatic assignment application 260 to transmit a connection request 605 to a cloud service provider. While Figure 6 Illustrates an IoT device transmitting a connection request to an IoT hub, but in some embodiments, the IoT device may transmit the connection request to a provisioning service (not shown), which verifies the IoT device before enabling the IoT device to use IoT solutions from the IoT hub 130. The IoT hub or the provisioning service each operate on one or more servers having a database to communicate with the IoT device and verify the IoT device. References to the IoT hub indicate operations performed by a remote server and may represent operations performed by the provisioning service, the IoT hub, or both the IoT hub and the provisioning service.

[0044] Using the connection request, the IoT device transmits authentication credentials 610, a current location 615, and network information 620. The authentication credentials may include a private key within the TPM of the IoT device as well as other unique information for the IoT hub to identify, authenticate, and grant access to the IoT solution. The network information may include an assigned IP (Internet Protocol) address, which can be used to identify the network to which the IoT device is connected, such as a subnet. Subnet information can be parsed from the provided IP address to support subnet-based allocation to specific IoT solutions. The current location may be geographic coordinates, such as latitude and longitude obtained from a GPS within the IoT device.

[0045] In response to receiving a connection request and associated details, the IoT Hub executes grouping code 625 to identify the IoT solution to which the IoT device is assigned. This enables rapid setup and operability of the IoT device with the IoT Hub, in response to connecting to a LAN. After the IoT Hub validates the IoT device using the information received from the connection request, the IoT Hub transmits a validation message 630 to grant the IoT device access to the IoT solution and IoT solution assignment 635. Details regarding the IoT Hub's selection of an IoT solution for the IoT device are provided in more detail below.

[0046] The IoT Hub can provide input fields to the customer to define its subnets and assign each subnet to an IoT solution. Figure 7 An illustrative graphical user interface (GUI) 705 that can be accessed by the customer's computing device 720 using, for example, an IoT solution manager application or a browser 715 is shown. The GUI provides an input field 710 that allows the user to select a specific IoT solution operating on the IoT Hub for the customer's subnet. Although the GUI shows multiple subnets for network devices, in other exemplary depictions, a network device can also be considered its own subnet such that IoT devices connected to the network device are part of a single subnet. While the GUI is shown in Figure 7 , other types of user interfaces arranged to enable the user to control subnet and IoT solution mapping can also be utilized, depending on the requirements of a particular embodiment.

[0047] Figure 8 A taxonomy of the characteristics of the grouping code is shown that supports rapid setup of IoT devices and assignment to IoT solutions. For example, after a customer's subnet is associated with a particular IoT solution, the grouping code 625 can include implementation options 815 that utilize separate processes for selecting an appropriate IoT solution for the IoT device. The customer can utilize one or more implementation options based on its specific configuration and change the order in which they are utilized. The order of the implementation options can be set by default or customized by the customer. For example, Figure 8 the implementation options depicted in

[0048] One implementation option performed by the IoT Hub includes automatically grouping IoT devices that are part of the same subnet or utilize the same network device (e.g., an edge gateway device or a router), as representatively shown by the numeral 805. As shown by Figure 9depicted by the number 905 in, in response to the IoT device connecting to the subnet, the IoT hub receives the network information 620 in the connection request and automatically assigns the IoT device 105 to the associated IoT solution. The automatically assigned IoT solution can be based on the user's configuration 910 derived from the user's selection ( Figure 7 ).

[0049] The implementation option can alternatively or additionally use the subnet information to predict device grouping, as Figure 8 representatively shown by the number 810 in. Figure 10 An illustrative environment is shown where the IoT hub uses the received network information 620 and the executed grouping code 625 makes a prediction 1005 using hard-coded rules 1010 or machine learning techniques 1015. The hard-coded rules can be a series of if... then conditions that automatically connect IoT devices using logical inference. For example, if a customer utilizes a single IoT solution, then the IoT hub can automatically associate the IoT device with the IoT solution. The machine learning techniques can utilize various parameters 1020 from one or more customers or different customers and make inferences by learning and identifying patterns based on the collected or crowdsourced data.

[0050] Depending on the given scenario, various unsupervised, supervised, and reinforcement learning techniques can be implemented, including for example clustering, classification, and regression. Thus, the IoT hub can receive data from the customer and implement various machine learning techniques to organize, parse, learn, and utilize the data in order to identify, select an IoT device, and assign the IoT device to an appropriate IoT solution.

[0051] Figure 11 A taxonomy of illustrative parameters 1020 is shown that can be utilized by and influence the machine learning decision processes. Parameters for the IoT device can include serial number 1105, type 1110, model 1115, sensors and / or the aggregated data 1120, the subnet to which the IoT device is connected 1125, and the geographical area or geofence within which the IoT device is located 1130. The utilization of the parameters in combination with the subnet known for the IoT device can provide useful information about the system settings of the organization for the corresponding customer.

[0052] Using various parameters, if the data collected indicates that similar IoT devices with heterogeneous characteristics are connected to the same IoT solution, then IoT devices with heterogeneous characteristics can still be connected to the same IoT solution. For example, in some scenarios, proximity sensors and temperature sensors can be utilized by customers to gather an overall representation of the environment. Although proximity sensors and temperature sensors are different types of sensors and gather different data, they can still utilize the same IoT solution. Predictions can be made to correctly select a suitable IoT solution for two different IoT devices based on the known grouping of those sensors being connected to the same subnet and using the same IoT solution.

[0053] Figure 12 and Figure 13 illustrates illustrative scenario 1200 and illustrative scenario 1300 in which predictions of IoT solutions are made. In Figure 12 this case, the available information indicates that the IoT device is a thermostat that collects temperature data, is connected to subnet 3, and has a model number of XXQ. Parsing this information together with other relevant information enables the IoT hub to make a prediction 1205 that the IoT device can be connected to and use data storage IoT solution 1210. The prediction can be based on one, more than one, or all fields of the information provided. The utilization of subnet 3 by the thermostat and the collection of temperature data can indicate and strengthen the proposition that this is the HVAC department using the data storage IoT solution at least with respect to this IoT device on subnet 3.

[0054] In Figure 13 this case, the available information indicates that the IoT device is a crane at a facility in the northwest region, the crane is connected to subnet 2, and has a serial number of 789 - 284. Based on the subnet utilized, the type of device, and the geographical location, the IoT hub can know that other available cranes within that region or geofence utilize analytics IoT solution 1310, and thus make this prediction 1305.

[0055] Figure 14 illustrates an illustrative diagram in which the location of the IoT device is used as part of a geofencing authentication process to enhance security over IoT devices used by a company. For example, for an organization, IoT-enabled devices (such as machinery or equipment ranging from hospital equipment to construction equipment) can be expensive. Some devices are more transportable than others, but many devices can be accidentally misplaced or may be stolen. Figure 14An illustrative defined geographic area or geofence 1405 is shown, which can be used to confirm that the IoT device is correctly located. The defined area or geofence can be inside a building 1420, inside a department of a building (such as a floor, a section of a building, a room, or other partition) 1425, inside a defined perimeter 1430, a defined geographic area (such as a section of a country, state, or town within a measured distance, etc.) 1435, or according to some other definition 1440.

[0056] The current location of the IoT device can be transmitted during the connection request process ( Figure 6 ), and can thus be used as part of the process. If the IoT device is not inside the defined area or geofence, then the IoT hub can choose to invalidate the IoT device and thus prohibit the device from using the IoT solution. If the IoT device is inside the defined area or geofence, then the IoT hub can verify the IoT device and authorize the IoT device to use the IoT solution. IoT device 1410 is inside the defined area 1405 and is thus a valid location, while IoT device 1415 is outside the defined area and is thus an invalid location.

[0057] Figure 15 A flowchart of an illustrative method for verifying an IoT device is shown. Unless otherwise specified, the methods or steps shown in the flowchart and described in the accompanying text are not limited to a particular order or sequence. Additionally, depending on the requirements of such an implementation, some of its methods or steps can occur or be executed simultaneously, and not all methods or steps must be executed in a given implementation, and some methods or steps can optionally be utilized.

[0058] In step 1505, the IoT device transmits a connection request to the IoT hub. This step can be comparable to the step Figure 6 depicted therein, where the IoT device transmits authentication credentials, current location, and network information. In step 1510, the IoT hub verifies the credentials of the IoT device (such as the private key, subscription information, customer payment is up - to - date). In step 1515, the IoT hub verifies that the IoT device is inside the authorized area or geofence ( Figure 14 ). In step 1520, the IoT hub verifies the IoT device based on the subnet to which the IoT device is connected and assigns it to the IoT solution. The IoT hub can re - verify the IoT device periodically, and thus the process starts again at step 1505.

[0059] IoT devices can automatically re - authenticate themselves or do so in response to a request from the IoT hub. In some embodiments, the IoT device receives a short - term token that is assigned a duration before expiration. When the token expires, the customer is prohibited from using the IoT solution until re - authentication with the IoT hub. After re - authentication, an update of the token or receipt of a new token from the IoT hub may occur. Re - authentication can be completed according to Figure 15 the steps shown therein, or alternatively can be completed by one or more steps such as verifying the location of the IoT device. In this embodiment, the IoT device can transmit its current location to the IoT hub for verification that it is within its geofence or defined area. In response to verification, the IoT device can be assigned a new short - term token.

[0060] Figure 16 FIG. Figure 16 is a flowchart of an illustrative method 1600 that can be performed by the IoT hub using one or more servers. In step 1605, the IoT hub receives a connection request and network information from the IoT device. In step 1610, the IoT hub uses the network information to identify the subnet from which the IoT device is connecting. In step 1615, in response to the received connection request and based on the identified subnet, a particular IoT solution among a plurality of different IoT solutions to connect to the IoT device is selected. In step 1620, the IoT hub connects the IoT device to the selected IoT solution.

[0061] Figure 17 FIG. is a flowchart of an illustrative method 1700 that can be performed by the IoT hub using one or more servers. In step 1705, the IoT hub performs automatic grouping of IoT devices or grouping of IoT devices based on prediction. The grouped IoT devices can be connected to a common IoT solution at the IoT hub. In step 1710, the IoT hub receives a request from the IoT device to connect to the IoT hub. In step 1715, the IoT hub verifies that the requested IoT device is within a geofence that sets boundaries for approved operations. In step 1720, in response to verification, the IoT hub connects the requested IoT device to the selected IoT solution.

[0062] Figure 18FIG. 1800 is a flow diagram of an illustrative method 1800 that may be performed by an IoT device communicating with an IoT hub. At step 1805, the IoT device connects to a network. At step 1810, in response to connecting to the network, the IoT device initiates an authentication process with the IoT hub. At step 1815, when the IoT hub verifies that the IoT device is within a defined geofence, the IoT device initiates communication with the IoT hub. At step 1820, the IoT device continues communication with the IoT hub by periodically reinitiating the authentication process with the IoT hub. The reinitiated authentication process may include at least transmitting a current location to the IoT hub to confirm that the IoT device remains within the defined geofence.

[0063] Figure 19 FIG. 1900 is a high-level block diagram of an illustrative data center 1900 that provides cloud computing services or distributed computing services that may be used to implement current subnet-based device allocation utilizing geofence authentication. A plurality of servers 1901 are managed by a data center management controller 1902. A load balancer 1903 distributes requests and computational workloads over the servers 1901 to avoid situations where a single server may become overwhelmed. The load balancer 1903 maximizes the available capacity and performance of resources in the data center 1900. A router / switch 1904 supports data traffic between the servers 1901 and between the data center 1900 and external resources and users (not shown) via an external network 1905, which may be, for example, a local area network (LAN) or the Internet.

[0064] The servers 1901 may be stand-alone computing devices, and / or they may be configured as individual blades in a rack of one or more server devices. The servers 1901 have input / output (I / O) connectors 1906 that manage communication with other database entities. One or more host processors 1907 on each server 1901 run a host operating system (O / S) 1908 that supports a plurality of virtual machines (VMs) 1909. Each VM 1909 may run its own O / S such that each VM O / S 1910 on the server is different or the same or a mixture of both. The VM O / S 1910 may be, for example, different versions of the same O / S (e.g., different VMs running different current versions and legacy versions of an operating system). Additionally or alternatively, the VM O / S 1910 may be provided by different manufacturers (e.g., some VMs run an operating system while other VMs run an operating system operating system). Each VM 1909 can also run one or more applications (App) 1911. Each server 1901 also includes a storage device 1912 (such as a hard disk drive (HDD)) and a memory 1913 (such as RAM) that can be accessed and used by the host processor 1907 and the VM 1909 for storing software code data, etc. In one embodiment, the VM 1909 can employ a data plane API as disclosed herein.

[0065] The data center 1900 provides pooled resources on which customers can dynamically provision and scale applications as needed without adding servers or additional networking. This allows customers to obtain the computing resources they need without having to acquire, provision, and manage infrastructure on an ad hoc basis for each application. The cloud computing data center 1900 allows customers to dynamically scale resources up or down to meet their current business requirements. Additionally, the data center operator can provide usage-based services to these customers so that they only pay for the resources they use when they need to use them. For example, a customer can initially use a VM 1909 on a server 1901 l to run its application 1911. When the demand for the application 1911 increases, the data center 1900 can start additional VMs 1909 on the same server 1901 l and / or new servers 1901 N as needed. If the demand for the application later decreases, then these additional VMs 1909 can be deactivated.

[0066] The data center 1900 can provide guaranteed availability, disaster recovery, and backup services. For example, the data center can designate a VM 1909 on a server 1901 l as the primary location for a customer's application and can start a second VM 1909 on the same or a different server as a standby or backup in case the first VM or the server 1901 l fails. The data center management controller 1902 automatically shifts incoming user requests from the primary VM to the backup VM without customer intervention. Although the data center 1900 is illustrated as a single location, it should be understood that the servers 1901 can be distributed across multiple locations globally to provide additional redundancy and disaster recovery capabilities. Additionally, the data center 1900 can be a dedicated private system that provides services to a single enterprise user, or can be a publicly accessible distributed system that provides services to multiple unrelated customers, or can be a combination of both.

[0067] The Domain Name System (DNS) server 1914 resolves domain names and host names into IP (Internet Protocol) addresses for all roles, applications, and services in the data center 1900. The DNS log 1915 maintains records of domain names that have been resolved by role. It should be understood that DNS is used as an example in this document, and other name resolution services and domain name logging services can be used to identify relevance.

[0068] Data center health monitoring 1916 monitors the health of the physical systems, software, and environment in the data center 1900. When problems are detected with servers, blades, processors, or applications in the data center 1900 or when network bandwidth or communication problems occur, the health monitoring 1916 provides feedback to the data center manager.

[0069] Figure 20FIG. 0 is a simplified block diagram of an illustrative computer system 2000, such as a PC, client machine, or server, in which a current subnet-based device allocation using geofencing authentication can be implemented. The computer system 2000 includes a processor 2005, a system memory 2011, and a system bus 2014 that couples various system components including the system memory 2011 to the processor 2005. The system bus 2014 can be any of several types of bus structures, including a memory bus or memory controller using any of a variety of bus architectures, a peripheral bus, or a local bus. The system memory 2011 includes read-only memory (ROM) 2017 and random access memory (RAM) 2021. A basic input / output system (BIOS) 2025 is stored in the ROM 2017 and contains basic routines that help to transfer information between elements within the computer system 2000, such as during startup. The computer system 2000 may also include: a hard disk drive 2028 for reading from and writing to an internally positioned hard disk (not shown); a disk drive 2030 for reading from or writing to a removable disk 2033, such as a floppy disk; and an optical disk drive 2038 for reading from or writing to a removable optical disk 2043, such as a CD (compact disc), DVD (digital versatile disc), or other optical medium. The hard disk drive 2028, disk drive 2030, and optical disk drive 2038 are connected to the system bus 2014 via a hard disk drive interface 2046, a disk drive interface 2049, and an optical disk drive interface 2052, respectively. The drives and their associated computer-readable storage media provide non-volatile storage of computer-readable instructions, data structures, program modules, and other data for the computer system 2000. Although the illustrative example includes a hard disk, a removable disk 2033, and a removable optical disk 2043, other types of computer-readable storage media that can store data accessible by a computer, such as magnetic tape cartridges, flash memory cards, digital video discs, data tapes, random access memory (RAM), read-only memory (ROM), etc., may also be used in some applications of the current subnet-based device allocation using geofencing authentication. Additionally, as used herein, the term computer-readable storage medium includes one or more instances of a media type (e.g., one or more disks, one or more CDs, etc.). For the purposes of this specification and the claims, the phrase "computer-readable storage medium" and its variants are intended to cover non-transitory embodiments and do not include waves, signals, and / or other transient and / or intangible communication media.

[0070] Multiple program modules can be stored on a hard disk, disk 2033, optical disk 2043, ROM 2017, or RAM 2021, including an operating system 2055, one or more application programs 2057, other program modules 2060, and program data 2063. A user can enter commands and information into the computer system 2000 through an input device (such as a keyboard 2066) and a pointing device 2068 (such as a mouse). Other input devices (not shown) can include a microphone, joystick, game pad, satellite antenna, scanner, trackball, touchpad, touch screen, touch-sensitive device, voice command module or device, user movement or user gesture capture device, etc. These and other input devices are typically connected to the processor circuit 2005 through a serial port interface 2071 coupled to the system bus 2014, but can be connected through other interfaces (such as a parallel port, game port, or Universal Serial Bus (USB)). A monitor 2073 or other type of display device is also connected to the system bus 2014 via an interface (such as a video adapter 2075). In addition to the monitor 2073, a personal computer typically includes other peripheral output devices (not shown), such as speakers and printers. Figure 20 The illustrative example shown also includes a host adapter 2078, a Small Computer System Interface (SCSI) bus 2083, and an external storage device 2076 connected to the SCSI bus 2083.

[0071] The computer system 2000 can operate in a networked environment using a logical connection to one or more remote computers (such as the remote computer 2088). The remote computer 2088 can be selected as another personal computer, server, router, network PC, peer device, or other common network node, and typically includes many or all of the elements described above with respect to the computer system 2000, but only a single representative remote memory / storage device 2090 is Figure 20 shown in Figure 20 The logical connections depicted in include a Local Area Network (LAN) 2093 and a Wide Area Network (WAN) 2095. Such a networked environment is typically deployed in, for example, offices, enterprise-wide computer networks, intranets, and the Internet.

[0072] When used in a LAN networking environment, computer system 2000 is connected to local area network 2093 through network interface or adapter 2096. When used in a WAN networking environment, computer system 2000 typically includes broadband modem 2098, a network gateway, or other components for establishing communications over wide area network 2095 (such as the Internet). Broadband modem 2098, which can be internal or external, is connected to system bus 2014 via serial port interface 2071. In a networking environment, program modules or portions thereof related to computer system 2000 can be stored in remote memory storage device 2090. It should be noted that Figure 20 The network connections shown are illustrative, and other means of establishing a communication link between computers can be used depending on the specific requirements of the application that utilizes current subnet-based device allocation with geofencing authentication.

[0073] Figure 21 Illustrative architecture 2100 of a computing device (such as a laptop or personal computer) or an IoT device capable of executing the various components described herein for subnet-based device allocation with geofencing authentication is shown. Figure 21 The architecture 2100 illustrated therein includes one or more processors 2102 (such as a central processing unit, a dedicated AI chip, a graphics processing unit, etc.), system memory 2104 including RAM (random access memory) 2106 and ROM (read-only memory) 2108, and a system bus 2110 that operatively and functionally couples the components in architecture 2100. The basic input / output system is typically stored in ROM 2108 and contains basic routines that facilitate the transfer of information between elements within architecture 2100 (such as during startup). Architecture 2100 also includes a mass storage device 2112 for storing software code or other computer-executable code used to implement applications, file systems, and operating systems. Mass storage device 2112 is connected to processor 2102 through a mass storage controller (not shown) connected to bus 2110. Mass storage device 2112 and its associated computer-readable storage medium provide non-volatile storage for architecture 2100. Although the description of computer-readable storage medium herein refers to mass storage devices such as hard drives or CD-ROM drives, those skilled in the art should understand that computer-readable storage medium can be any available storage medium accessible by architecture 2100.

[0074] By way of example, and not limitation, a computer-readable storage medium can include volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules or other data. By way of example, and not limitation, computer-readable media include, but are not limited to, RAM, ROM, EPROM (erasable programmable read-only memory), EEPROM (electrically erasable programmable read-only memory), flash memory or other solid state memory technologies, CD-ROM, DVD, HD-DVD (high definition DVD), Blu-ray or other optical storage devices, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and that can be accessed by the architecture 2100.

[0075] According to various embodiments, the architecture 2100 can operate in a networked environment using a logical connection to a remote computer through a network. The architecture 2100 can be connected to the network through a network interface unit 2116 connected to the bus 2110. It should be appreciated that the network interface unit 2116 can also be used to connect to other types of networks and remote computer systems. The architecture 2100 can also include an input / output controller 2118 for receiving and processing inputs from a plurality of other devices, the input / output controllers including a keyboard, a mouse, a touchpad, a touch screen, control devices such as buttons and switches, or an electronic pen (not shown in Figure 21 ). Similarly, the input / output controller 2118 can provide outputs to a display screen, a user interface, a printer, or other types of output devices (not shown in Figure 21 either).

[0076] It should be understood that the software components described herein, when loaded into the processor 2102 and executed, can transform the processor 2102 and the overall architecture 2100 from a general-purpose computing system into a special-purpose computing system customized to support the functionality presented herein. The processor 2102 can be constructed from any number of transistors or other discrete circuit elements that can individually or jointly assume any number of states. More specifically, in response to executable instructions contained within the software modules described herein, the processor 2102 can operate as a finite state machine. These computer-executable instructions can transform the processor 2102 by specifying how the processor 2102 makes transitions between states, thereby transforming the transistors or other discrete hardware elements that make up the processor 2102.

[0077] Encoding the software modules presented herein can also transform the physical structure of the computer-readable storage medium presented herein. In different embodiments of this specification, the specific transformation of the physical structure can depend on various factors. Examples of such factors can include, but are not limited to, the technology used to implement the computer-readable storage medium, whether the computer-readable storage medium is characterized as a main storage device or an auxiliary storage device, etc. For example, if the computer-readable storage medium is implemented as a semiconductor-based memory, then the software disclosed herein can be encoded on the computer-readable storage medium by transforming the physical state of the semiconductor memory. For example, the software can transform the state of transistors, capacitors, or other discrete circuit elements that make up the semiconductor memory. The software can also transform the physical state of such components in order to store data thereon.

[0078] As another example, the computer-readable storage medium disclosed herein can be implemented using magnetic technology or optical technology. In such an embodiment, when the software is encoded in a magnetic medium or an optical medium, the software presented herein can transform the physical state of the magnetic medium or the optical medium. These transformations can include changing the magnetic properties of a specific location within a given magnetic medium. These transformations can also include changing the physical characteristics or properties of a specific location within a given optical medium in order to change the optical properties of these locations. Using the foregoing examples provided only to support this discussion, other transformations of the physical medium are possible without departing from the scope and spirit of this specification.

[0079] The architecture 2100 may also include one or more sensors 2114 or a battery or power source 2120. The sensors can be coupled to the architecture to pick up data about the environment or components, including temperature, pressure, etc. The power supply can be adapted for portability using an AC power cord or a battery (such as a rechargeable battery).

[0080] In view of the foregoing, it should be understood that many types of physical transformations occur in the architecture 2100 in order to store and execute the software components presented herein. It should also be understood that the architecture 2100 can include other types of computing devices, including wearable devices, handheld computers, embedded computer systems, smart phones, PDAs, and other types of computing devices known to those skilled in the art. It is also contemplated that the architecture 2100 may not include Figure 21 all of the components shown in Figure 21 may include other components not explicitly shown in Figure 21 or may utilize an architecture completely different from the architecture shown in

[0081] Various exemplary embodiments of existing subnet-based device allocation using geofence authentication are now presented by way of illustration and not as an exhaustive listing of all embodiments. Examples include a method performed by an Internet of Things (IoT) hub, the IoT hub being configured using one or more servers, the one or more servers being operably coupled to a wide area network, the method comprising: receiving a connection request and network information from an IoT device; using the network information, identifying the subnet from which the IoT device is connecting, wherein the subnet provides an interface to the wide area network to enable communication between the IoT device and the IoT hub; in response to the received connection request, selecting, based on the identified subnet, an IoT solution among a plurality of different IoT solutions to connect to the IoT device; and connecting the IoT device to the selected IoT solution.

[0082] In another example, the method further comprises: verifying that the IoT device is in an acceptable location defined by a geofence; receiving location information from the IoT device; using the received location information to confirm that the IoT device is within the established geofence; if the location of the IoT device is within the established geofence, then connecting the IoT device to the selected IoT solution; and if the location of the IoT device is outside the established geofence, then rejecting the connection and utilization of the determined IoT solution with the IoT device. In another example, the IoT device location information and network information are included with the initiation of the connection request. In another example, the method further comprises: receiving user input for the assignment of a subnet to a corresponding IoT solution, and wherein the selected IoT solution is based on the assignment. In another example, the selection of the IoT solution is automatically performed in response to the IoT device connecting to the subnet. In another example, the subnet is identified based on the networking device to which the IoT device is connected, or based on a network prefix and subnet number included within an Internet Protocol (IP) address for the IoT device. In another example, the method further comprises: analyzing parameters for a group of IoT devices; and predicting, based on the analyzed parameters, an IoT solution to connect to the IoT device. In another example, the parameters are grouped by individual IoT devices within the group of IoT devices, and the parameters include one or more of the following: type of IoT device, serial number, model number, one or more sensors utilized, type of data aggregated, current subnet utilization, or geographical region or geofence within which the IoT device is located. In another example, IoT devices having heterogeneous characteristics are grouped into the same IoT solution.

[0083] Another example includes an Internet of Things (IoT) hub that includes one or more servers. The IoT hub is configured to provide various IoT solutions to IoT devices based on IoT device configurations, including: one or more processors; and one or more hardware-based memory devices storing computer-readable instructions that, when executed by the one or more processors, cause the IoT hub to: perform automatic grouping of IoT devices or perform grouping of IoT devices based on prediction, where the grouped IoT devices can be connected to a common IoT solution at the IoT hub; receive requests from IoT devices for connection to the IoT hub; verify that the requested IoT device is located inside a geofence that defines a boundary for approved operations; and in response to verifying, connect the requested IoT device to the common IoT solution, where IoT devices behind a common subnet are automatically grouped, and where subnet information associated with the requested IoT device is used by the IoT hub to perform the predicted grouping.

[0084] In another example, the automatic grouping and the predicted grouping are implemented using grouping codes, where the grouping codes are unique for each customer having a group of IoT devices connected to various IoT solutions provided by the hub. In another example, the request for connection to the IoT hub includes transmission of network information that includes identification of one or more of the following: a subnet number within an Internet Protocol (IP) address, a router, a wireless access point, or an edge gateway device. In another example, the identification of the router or the wireless access point includes a Service Set Identifier (SSID) or a Basic Service Set Identifier (BSSID). In another example, the executed instructions further cause the IoT hub to: periodically receive location information from each IoT device; and in response to receiving the location information, verify that each IoT device is located inside the approved boundary defined by the geofence. In another example, the executed instructions further cause the IoT hub to transmit a token to the verified IoT device, where the transmitted token is configured to expire after a set duration, after which the verified IoT device re-transmits the location information for a new token. In another example, the executed instructions further cause the IoT hub to be accessible by a remote computing device using a browser or a client application and having scalability to the IoT hub, and the executed instructions further cause the IoT hub to: transmit at least a portion of a user interface (UI) to the remote computing device for managing the connection of IoT devices to the IoT hub, where the UI is configured to receive user input for assigning a subnet to a specific IoT solution.

[0085] Another example includes one or more hardware-based non-transitory computer-readable memory devices storing instructions that, when executed by one or more processors disposed in an Internet of Things (IoT) device including hardware for network connectivity, cause the IoT device to: connect to a communication network; in response to connecting to the network, initiate an authentication process using an IoT hub, where the authentication process includes transmitting access credentials, the current location of the IoT device, and network information to the IoT hub to verify the IoT device and connect the IoT device to an IoT solution; when the IoT hub verifies that the IoT device is located inside a defined geofence, initiate communication with the IoT hub, where the communication includes one or more of: transmitting data to the IoT hub or receiving data from the IoT hub; and continue communication with the IoT hub by periodically reinitiating an authentication process that at least includes transmitting the current location to the IoT hub to verify that the IoT device is within the geofence.

[0086] In another example, when the duration associated with a locally stored token expires, the IoT device reinitiates the authentication process, and the instructions executed also cause the IoT device to receive a new token in response to verification by the IoT hub. In another example, the transmitted network information includes an identification of one or more of a network or subnet that may include a gateway edge device, router, wireless access point, modem, or switch, and where the IoT solution to which the IoT device is connected is determined based on the transmitted network information. In another example, the IoT device is configured to automatically initiate an authentication process for verification using the IoT hub in response to establishing a connection to the network such that the IoT device is configured to operate in response to verification and, if the verification fails, is denied communication with the IoT solution.

[0087] Although the subject matter has been described in language specific to structural features and / or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims

1. A method performed by an Internet of Things (IoT) hub, the IoT hub being configured using one or more servers, the one or more servers being operatively coupled to a wide area network, the method comprising: Receiving, from an IoT device, a request to connect to an IoT solution among a plurality of different IoT solutions, the request including network information and location information of the IoT device, wherein the network information includes an Internet Protocol (IP) address of the IoT device; Identifying an existing subnet among a plurality of different existing subnets based on a network prefix and subnet number included within the IP address of the IoT device, wherein the identified existing subnet provides an interface to the wide area network to enable communication between the IoT hub and the IoT device; Using the received location information to verify that the IoT device is within a geofence; In response to the verification, adding the IoT device to a corresponding group of IoT devices; Mapping a unique IoT solution among the plurality of different IoT solutions to the corresponding group of the IoT device based on the identified existing subnet, wherein each IoT unique solution among the plurality of different IoT solutions includes software configured to interoperate with functions supported by the corresponding group of IoT devices, and Connecting the unique IoT solution to the IoT device based on the mapping.

2. The method according to claim 1 further comprises: Receiving user input for assignment of an existing subnet to a corresponding IoT solution, and wherein the IoT solution is selected based on the assignment.

3. The method according to claim 1, wherein the connection of the unique IoT solution to the IoT device is automatically performed in response to receiving the request from the IoT device.

4. The method according to claim 3, wherein the existing subnet is identified based on a networking device to which the IoT device is connected.

5. The method according to claim 1, further comprising: Analyzing parameters for a group of IoT devices; And Predicting an IoT solution to be connected to the IoT device based on the analyzed parameters.

6. The method according to claim 5, wherein the parameters are grouped by individual IoT devices within the group of IoT devices, and the parameters include one or more of the following: type of IoT device, serial number, model number, one or more sensors utilized, type of data aggregated, current utilization of the subnet, or a geographical area or geofence within which the IoT device is located.

7. The method according to claim 5, wherein IoT devices having heterogeneous characteristics are grouped into the same IoT solution.

8. An Internet of Things (IoT) hub including one or more servers, the IoT hub being configured to provide an IoT solution to an IoT device, comprising: One or more processors; And One or more hardware-based memory devices storing computer-readable instructions, the computer-readable instructions when executed by the one or more processors cause the IoT hub to: Automatically add IoT devices to different groups of IoT devices based on the corresponding existing subnet among multiple different existing subnets to which each IoT device belongs; Receive, from an IoT device, a request to connect to an IoT solution among multiple different IoT solutions, the request including network information, the network information including the Internet Protocol IP address of the IoT device and the location information of the IoT device; Identify an existing subnet based on the network prefix and subnet number included within the IP address of the IoT device, the IoT device using the existing subnet to connect to the IoT hub; Use the location information to verify that the IoT device is located inside a geofence that defines a boundary for approved operations; In response to the verification, add the IoT device to the corresponding group of IoT devices; Map a unique IoT solution among the multiple different IoT solutions to the corresponding group of IoT devices based on the identified existing subnet; and Connect the unique IoT solution to the IoT device based on the mapping, where each unique IoT solution among the multiple different IoT solutions includes software configured to interoperate with functions supported by the corresponding group of IoT devices.

9. The IoT hub according to claim 8, wherein the different groups of IoT devices are implemented using group codes, where the group codes are unique for each customer having a group of IoT devices connected to the multiple different IoT solutions provided by the hub.

10. The IoT hub according to claim 8, wherein the network information includes an identification of one or more of the following: a router, a wireless access point, or an edge gateway device.

11. The IoT hub according to claim 10, wherein the identification for the router or wireless access point includes a Service Set Identifier SSID or a Basic Service Set Identifier BSSID.

12. The IoT hub according to claim 8, wherein the instructions executed further cause the IoT hub to: Periodically receive location information from each IoT device; and In response to receiving the location information, verify that each IoT device is located inside the boundary defined by the geofence.

13. The IoT hub according to claim 12, wherein the instructions executed further cause the IoT hub to transmit a token to the verified IoT device, where the transmitted token is configured to expire after a set duration, after which the verified IoT device transmits location information again for a new token.

14. The IoT hub according to claim 8, wherein the instructions executed further cause the IoT hub to be accessible by a remote computing device using a browser or a client application and having scalability to the IoT hub, and the instructions executed further cause the IoT hub to: Transmit at least a portion of a user interface (UI) to a remote computing device for managing a connection of an IoT device to the IoT hub, where the UI is configured to receive user input for assigning an existing subnet to a specific IoT solution.

15. One or more hardware-based non-transitory computer-readable memory devices storing instructions that, when executed by one or more processors disposed in an Internet of Things (IoT) device including hardware for network connectivity, cause the IoT device to: Connect to a communication network that includes a plurality of different existing subnets, where IoT devices in each of the plurality of different existing subnets are differently grouped based on the corresponding existing subnet among the plurality of different existing subnets to which each IoT device in the IoT devices belongs, and where a unique IoT solution among a plurality of different IoT solutions is mapped to each of the different groupings of IoT devices based on the corresponding existing subnet, where each unique solution among the plurality of different IoT solutions includes software configured to interoperate with functions supported by the grouping of IoT devices; In response to connecting to one of the plurality of different existing subnets, initiate an authentication process with an IoT hub, where the authentication process includes transmitting access credentials, the current location of the IoT device, and network information to the IoT hub to verify the IoT device and connect the IoT device to the unique IoT solution, where the transmitted network information includes a network prefix and subnet number within the IP address of the IoT device for identifying the existing subnet to which the IoT device is connected from the plurality of different existing subnets; When the IoT hub verifies that the IoT device is located inside a defined geofence, initiate communication with the IoT hub, where the communication includes one or more of: transmitting data to the IoT hub or receiving data from the IoT hub; Continue communication with the IoT hub by periodically reinitiating the authentication process that at least includes transmitting the current location to the IoT hub to verify that the IoT device is within the geofence; And Receive an IoT solution from the IoT hub at the IoT device based on the mapping.

16. The one or more hardware-based non-transitory computer-readable memory devices according to claim 15, where when the duration associated with a locally stored token expires, the IoT device reinitiates the authentication process, and the executed instructions further cause the IoT device to receive a new token in response to verification by the IoT hub.

17. One or more hardware-based non-transitory computer-readable memory devices according to claim 15, wherein the transmitted network information includes the identification for: the existing subnet among the plurality of different existing subnets, the existing subnet including one of the following: a gateway edge device, a router, a wireless access point, a modem, or a switch, and wherein the IoT solution to which the IoT device is connected is determined based on the transmitted network information.

18. One or more hardware-based non-transitory computer-readable memory devices according to claim 15, wherein the IoT device is configured to automatically initiate an authentication process for leveraging the authentication of the IoT hub in response to establishing the connection with the communication network, such that the IoT device is configured to: operate in response to authentication and, if the authentication fails, then be denied communication with the IoT solution.

Images