Patent ID: 12225121

DESCRIPTION OF THE EXAMPLES

Reference will now be made in detail to the present examples, including examples illustrated in the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts.

Systems and methods are described for accessing resources of a UEM system through an enrolled device. In an example, an unenrolled device can be paired with an enrolled device. The unenrolled device can connect to the enrolled device on a local network. The enrolled device can verify the unenrolled device using a key provided during pairing. The unenrolled device can send requests for UEM resources to the enrolled device, which the enrolled device can send to a UEM server. The UEM server can send the requested UEM resources to the enrolled device, and the enrolled device can send the UEM resources to the enrolled device over the local network.

In another example, an IoT device can be registered with the UEM system. The IoT device can be unable to connect to the UEM server. The IoT device can scan for enrolled devices. Upon detecting an enrolled device, the IoT device can provide an ID that identifies the IoT device to the enrolled device. The enrolled device can connect to the UEM server, and the UEM server can open a data transfer session for the IoT device. The IoT device and the UEM server can exchange information through the enrolled device.

FIG.1is an illustration of an example system for performing accessing system resources through an enrolled user device.FIG.2is a flowchart of an example method for pairing an unenrolled device with an enrolled device so that the unenrolled device can access UEM resources through the enrolled device.FIG.3is a flowchart of an example method for accessing UEM resources from an unenrolled device through an enrolled device after the two devices are paired.FIG.4is a sequence diagram that illustrates the example method of device pairing described inFIG.2.FIG.5is a sequence diagram that illustrates the example method of accessing UEM resources through an enrolled device described inFIG.3.FIG.6is a sequence diagram of an example method for accessing system resources with an IoT device through an enrolled user device.FIG.7is a sequence diagram of an example method similar toFIG.6but includes stages where the IoT device loses connection with a first enrolled device and finishes a data transfer session with the UEM server with a second enrolled device.

FIG.1is an illustration of an example system for performing accessing system resources through an enrolled user device. The system can include a UEM system110, enrolled user devices120(hereinafter referred to as “enrolled devices120”), and unenrolled user devices130(hereinafter referred to as “unenrolled devices130”). The UEM system110can be a system that manages and secures user devices that enroll with the UEM system110. For example, the UEM system110can include a UEM server112. The UEM server112can be a single server or a group of servers, including multiple servers implemented virtually across multiple computing platforms. In an example, the UEM server112can manage enrolled user devices120by sending management instructions to a management application140installed on the enrolled user devices120. The enrolled user devices120can be one or more processor-based devices, such as a personal computer, tablet, or cell phone. The management application140can be a stand-alone application, part of an enterprise application, or part of an operating system of the enrolled devices120.

In an example, the management application140can be responsible for ensuring that the enrolled devices120are up to date with compliance and security settings prior to accessing enterprise data and resources. The management application140can communicate with the UEM server112, allowing UEM management of the enrolled devices120based on compliance and security settings at the UEM server112. The management application140can enforce compliance at the enrolled devices120, such as by wiping enterprise data when compliance standards are not met. Example compliance standards can include ensuring a device is not jailbroken, that particular encryption standards are used in enterprise data transmission, that the device does not have certain blacklisted applications installed or running, and that the device is located within a geofenced area when accessing certain enterprise resources.

The enrolled user device122is one example of the enrolled user devices120. The enrolled user device122can include the management application140and a UEM browser150a. The UEM browser150acan be a web browser application managed by the UEM system110. In one example, the enrolled device122can include other managed applications as well.

In an example, the unenrolled devices130can include user devices that are not enrolled with the UEM system110, like the unenrolled device132. Although, the unenrolled device132is not enrolled, it can include the UEM browser150b. The UEM browser150bcan be a secure web browser that allows the unenrolled device132to access UEM resources despite not being enrolled. For example, the UEM system110can allow the unenrolled device132to access certain UEM resources under certain conditions. As an example, the enrolled device122and the unenrolled device132can both belong to the same user. The user can log into the browser150bon the unenrolled device132under the same user profile used to enroll the enrolled device122. When the enrolled device122and unenrolled device132are connected to the same local network, or directly connected to each other, the UEM system110can allow the user to access UEM resources within the UEM browser150bthrough the enrolled device122. For example, the enrolled device122and unenrolled device132can establish a secure connection with other. The UEM browser150bcan send requests for UEM resources to the enrolled device122, which can in turn send the requests to the UEM server112. The UEM server112can send the UEM resources to the unenrolled device132through the enrolled device122.

The unenrolled devices130can also include nonstandard computing devices, like the IoT device134. The IoT device134can be one or more processor-based devices that can connect to a network and has data transfer capabilities. Examples of the IoT device134can include sensors, cameras, vehicles, appliances, security systems, thermostats, and more. Where the IoT device134is in a location where it cannot access a network, the IoT device134can be configured to access the UEM system110through enrolled devices120. For example, the IoT device134can be configured to broadcast a signal that enrolled devices120are configured to detect. When an enrolled device122detects the broadcast, the IoT device134and the enrolled device122can establish a connection with each other. In an alternative example, the enrolled devices120can broadcast the signal that the IoT device134detects. After the connection is established, the enrolled device122can be configured to contact the UEM server112and request a data transfer session for the IoT device134. The session can be a temporary and interactive information interchange whereby the IoT device134and UEM server112can exchange information through the enrolled device122. The UEM server112can open a session, and the IoT device134and the UEM server112can then exchange data through the enrolled device122. If the session gets interrupted, such as where the enrolled device122moves out of range from the IoT device134, the UEM server112can save the session so that it can be continued when the IoT device134finds another enrolled device122to connect to.

FIG.2is a flowchart of an example method for pairing the enrolled device122and the unenrolled device132so that the unenrolled device132can access system resources through the enrolled device122. At stage210, the enrolled device122can provide a local network address of the enrolled device122to the unenrolled device132. For example, the enrolled device122and unenrolled device132can both be connected to the same local network. The local network can include two or more devices connected to each other such that they can exchange electronic communications. For example, the local network can include a local area network (“LAN”), a wireless local area network (“WLAN”), a virtual private network (“VPN”) internet connection, or two or more devices connected directly, such as through BLUETOOTH, WIFI DIRECT, or near-field communications (“NFC”). The network can include one or more nodes, such a routers or switches, that assign IP addresses to connect devices. The local network address of the enrolled device122can be its locally assigned IP address, in an example. If the enrolled device122permits, other devices on the local network can see and communicate with the enrolled device122using the local IP address of the enrolled device122.

In one example, the enrolled device122can display the IP address on a display. For example, the management application140can have a feature that a user can select to initiate the pairing process with an unenrolled device. As part of the process, the management application140can retrieve the IP address from the network settings of the enrolled device122and display it on the display of the enrolled device122. The user can then enter the IP address into the UEM browser150bon the unenrolled device132. In another example, the management application140can display a code, such as a bar code or Quick Response (“QR”) code, that has the IP address embedded within. The user can scan the code with the unenrolled device132, which can cause the UEM browser150bto send a connection request to the local IP address.

At stage220, the enrolled device122can receive a connection request from the unenrolled device132. In one example, the request can come from the UEM browser150b. The user can be required to use the UEM browser150b, in an example. For example, the UEM browser150bcan be managed by the UEM system110and configured to prevent any other applications or services from accessing information within the UEM browser150b, such as by encrypting any data related to the UEM system110. In one example, the enrolled device122can verify that the connection request came from a UEM browser150bbefore allowing the unenrolled device132to connect.

In one example, the UEM browser150bcan be configured to send the connection request to a specific port that the enrolled device122is configured to receive connection requests on. For example, the enrolled device122can listen for connection requests on the specified port, and any requests received on another port can be denied.

In an example, upon receiving the proper connection request, the enrolled device122can verify the request. For example, the UEM browser150bcan perform one or more security protocols, such as sending a certificate, encrypting the request or certificate with an encryption key that the enrolled device122can decrypt, or hashing the request or certificate with a has function that is known and trusted by the enrolled device122. If the enrolled device122can verify unenrolled device132, then the enrolled device122can establish the connection.

At stage230, the enrolled device122can display a prompt with a randomly generated number. For example, to verify that the enrolled device122is connecting to the correct device, the enrolled device122can generate a random number and send it to the unenrolled device132. The enrolled device122and unenrolled device132can then display the random number on their respective displays so that the user can verify that they match. In one example, the random number can be generated by the UEM browser150band sent to the enrolled device122.

At stage240, the enrolled device122can receive input indicating the random number displayed on the enrolled device122and the unenrolled device132match. For example, the enrolled device122can display the randomly generated number in a graphical user interface (“GUI”) that includes buttons that allow the user to indicate whether the numbers match. In one example, the randomly generated number can be displayed on one of the two devices, and the user can be required to input the displayed number into the other device. For example, the enrolled device122can generate the random number and send it to the unenrolled device132. In one example, the unenrolled device132can display the random number and the enrolled device122can prompt the user to enter the random number. Alternatively, the enrolled device122can display the number and the unenrolled device132can prompt the user to enter the number.

At stage250, the enrolled device122can exchange public keys with the unenrolled device132. In an example, the public keys can be part of an asymmetric encryption key pair. The private keys can be stored on the respective devices. The public key can be used to encrypt data with a one-way encryption algorithm so that the corresponding private key is the only key that can decrypt the data.

The keys can be generated in response to the connection request or already be stored on the devices122and132. For example, the enrolled device122can generate its key pair after enrolling with the UEM system110and the UEM browser150bon the unenrolled device132can generate its key pair when the UEM browser150bis installed. The keys can later be used to authenticate the devices122and132and encrypt data exchanged between them.

At stage260, the enrolled device122can receive a random key from the unenrolled device132. For example, the UEM browser150bcan use a random number generator (“RNG”) or a pseudorandom number generator (“PRNG”) to generate a random number that corresponds to the random key. The random key can be used by the enrolled device122to identify and authenticate requests from the unenrolled device132for UEM resources. This is explained is greater detail below regardingFIG.3.

FIG.3is another flowchart of an example method for the unenrolled device132accessing UEM system resources through the enrolled device122. The example method described below can occur after the enrolled device132has already established trust with the unenrolled device132. For example, the method illustrated inFIG.3can occur after the enrolled device122and unenrolled device132have paired using the method described inFIG.2above.

At stage310, the enrolled device122detect the random key from the unenrolled device132. The user can request UEM resources from the UEM browser150bon the unenrolled device132. The UEM browser150bcan then broadcast the random key. For example, the UEM browser can cause the unenrolled device132to send the broadcast over a local network that the unenrolled device132is connected to, such as a home, work, or public network.

At stage320, the enrolled device122can respond to the broadcast by providing its local network address, such as its local IP address. In one example, the broadcast from the unenrolled device132can include the local network address of the unenrolled device132, which the enrolled device122can use to send its own local network address.

In one example, the enrolled device122can identify the unenrolled device132based on the broadcast including the random key. For example, when the enrolled device122is connected to a network, the enrolled device122can be configured to listen for a broadcast the includes a random key of another device that the enrolled device122has previously paired with. The enrolled device122can identify the device associated with the broadcast based on the random key. For example, the enrolled device122can store a table that maps random keys with their associated unenrolled devices130.

At stage330, the enrolled device122can receive a request for a UEM resource from the unenrolled device132. The requested UEM resource can include any data, application, or other resource managed by the UEM system110. For example, UEM resources can include a document, image, video, a web application, or an internal web site. The unenrolled device132can send the request to the enrolled device122over the local network that both devices122and132are connected to. In one example, the UEM system110can require that both devices122and132are connected to the same local network for the enrolled device122to be permitted to send UEM resources to the132. In another example, the UEM system110can allow the enrolled device122to send UEM resources to the unenrolled device132if the two devices122and132are directly connected, such as through BLUETOOTH, WIFI DIRECT, or NFC.

In one example, the enrolled device122can authenticate the unenrolled device132. For example, the unenrolled device132can send the request with a certificate encrypted using the public key previously provided by the enrolled device122. The enrolled device122can decrypt the certificate to authenticate the unenrolled device132. In another example, the unenrolled device132can append the resource request with the random key.

In one example, the enrolled device122can determine how secure the local network is before processing the UEM resource request. For example, the enrolled device122can determine whether the local network is a preapproved network, determine whether the network is open or closed, determine what kind of security encryption the network uses, and identify any potentially malicious devices connected to the network. In on example, the UEM server112can provide instructions for determining the safety level of networks, and the enrolled device122can allow or reject the UEM resource request based on whether the local network meets the required security level.

At stage340, the enrolled device122can send the resource request to the UEM server112. The type of request sent can depend on the resource requested. For example, the enrolled device122can make an Application Programming Interface (“API”) call to the UEM server122to access files like documents are videos. In one example, where resource request is for an internal web site or web application, the enrolled device122can make an API call that includes the uniform resource locator (“URL”) of the web site or make a hypertext transfer protocol (“HTTP”) request to the corresponding UEM web server.

At stage350, the enrolled device122can receive the requested resource from the UEM server112. For example, the UEM server112can retrieve the requested resource over the Internet. For example, the UEM server112can send a hypertext markup language (“HTML”) file, Extensible Markup Language (“XML”) file, or a JavaScript Object Notation (“JSON”) file.

At stage360, the enrolled device122can send the requested resource to the unenrolled device132. For example, the unenrolled device132can send its own local IP address to the enrolled device122during one of the previous stages, which the enrolled device122can use to send the UEM resource. In one example, the enrolled device122can encrypt the UEM resource using the public key of the unenrolled device132before sending the UEM resource. The unenrolled device132can then decrypt the UEM resource using its private key.

In one example, the enrolled device122can continue to channel communications between the unenrolled device132and the UEM server112. For example, where the UEM resource is a web application, the user can use the web application on the unenrolled device132. As the user interacts with the web application, the unenrolled device132can send the user's inputs and any needed requests associated with the web application to the enrolled device122, which can relay them to the UEM server112. The UEM server112can send responses to the unenrolled device132through the enrolled device122.

FIG.4is a sequence diagram of an example method for pairing the unenrolled device132and the enrolled device122for accessing system resources through the enrolled device122. At stage402, the enrolled device122can provide its local IP address to the unenrolled device132. For example, the enrolled device122and unenrolled device132can both be connected to the same local network, such as a home and work network. The network can include one or more nodes, such a routers or switches, that assign IP addresses to connect devices. The local network address of the enrolled device122can be its locally assigned IP address, in an example. If the enrolled device122permits, other devices on the local network can see and communicate with the enrolled device122using the local IP address of the enrolled device122.

In one example, the enrolled device122can display the IP address on a display, and the user can input the IP address into the unenrolled device132. Alternatively, the management application140can display a code, such as a bar code or QR code, that has the IP address embedded within. The user can scan the code with the unenrolled device132, which can cause the UEM browser150bto send a connection request to the local IP address.

At stage404, the unenrolled device132can connect to the enrolled device122using the local IP address. For example, the unenrolled device132can send a connection request through the local network using IP address of the enrolled device122. One or more network nodes in the local network can route the request to the enrolled device.

In one example, the enrolled device132can verify the unenrolled device132prior to accepting the request. For example, the user can log into the UEM browser150busing credentials associated with the same user profile used to enroll the enrolled device122. After logging in to the UEM browser150b, the UEM server112can send a certificate to the UEM browser150bthat can be used to authenticate the enrolled device132. The unenrolled device132can send the certificate with the connection request, which the enrolled device122can authenticate.

At stage406, the enrolled device122can generate a random number. For example, to verify that the enrolled device122is connecting to the correct device, the enrolled device122can generate a random number and send it to the unenrolled device132at stage408. The enrolled device122and unenrolled device132can then display the random number on their respective displays at stages410aand410b. If the numbers match, the user can confirm at stage412. For example, the enrolled device122can prompt the user in a GUI to indicate whether the unenrolled device132is displaying the same number, such as by selecting a button. If the user confirms that the numbers match, at stage414, the enrolled device122can notify the unenrolled device132of the confirmation, such as by sending a message.

At stages416aand416b, the enrolled device122(stage416b) and the unenrolled device132(stage416a) can each generate an encryption key pair. The encryption key pairs can include a private key and a corresponding public key. The public key can be used to encrypt data with a one-way encryption algorithm so that the corresponding private key is the only key that can decrypt the data. The keys can be generated in response to the connection request or already be stored on the devices122and132. For example, the enrolled device122can generate its key pair after enrolling with the UEM system110and the UEM browser150bon the unenrolled device132can generate its key pair when the UEM browser150bis installed. The keys can later be used to authenticate the devices122and132and encrypt data exchanged between them. At stage418, the enrolled device122and the unenrolled device132can exchange their public keys.

At stage420, the unenrolled device132can generate a random key. For example, the UEM browser150bcan use an RNG or a PRNG to generate a random number. The random key can be used by the enrolled device122to identify and authenticate requests from the unenrolled device132for UEM resources. At stage422, the unenrolled device132can send the random key to the enrolled device122. The enrolled device122can use the random key to identify electronic transmissions sent from the unenrolled device132.

FIG.5is a sequence diagram of an example method for accessing system resources by the unenrolled device132through the enrolled device122. In an example, the method illustrated inFIG.5can occur after the enrolled device122and the unenrolled device132have paired using the method described above regardingFIG.4. For example, the unenrolled device132can be in possession of the public key from the enrolled device122, and the enrolled device122can be in possession of the public key and the random key from the unenrolled device132.

At stage502, the unenrolled device132can broadcast the random key. For example, the unenrolled device132can broadcast the random key on a local network that it is connected to or using a localized wireless communication method like BLUETOOTH LOW ENERGY (“BLE”). In an example, the unenrolled device132can broadcast the random key in response to user input. For example, when the user opens the UEM browser150bor inputs a URL into the UEM browser150b, the UEM browser150bcan cause the unenrolled device132to broadcast the random key to see if there is an enrolled device122available to operate through.

At stage504, the enrolled device122can detect the broadcasted random key. For example, the management application140on the enrolled user device122can be configured to listen for the random key on the local network. The enrolled device122can detect the broadcast and, based on the random key, determine that the broadcast came from the unenrolled device132that it previously paired with.

At stage506, the enrolled device122can send its local IP address to the unenrolled device132. For example, the enrolled device122can be assigned a local IP address from a local network node like a switch or a router. At stage508, the unenrolled device132can connect to the enrolled device122using the local IP address. In examples where the enrolled device122and the unenrolled device132connect directly, such as through BLUETOOTH, NFC, or WIFI DIRECT, the two devices122,132can connect without the local IP address.

At stage510, the unenrolled device132can send an encrypted request for UEM resources to the unenrolled device132. In an example, the request can be encrypted using the public key of the enrolled device122. For example, the user can enter a URL for a UEM web application into the UEM browser150b. The UEM browser150bcan encrypt the URL using the public key of the enrolled device122and send the encrypted request to the enrolled device122.

At stage512, the enrolled device122can verify the resource request. For example, the unenrolled device132can include the random key with the resource request, and the enrolled device122can verify that the request came from the unenrolled device132based on the random key. In one example, the enrolled device122can send an encrypted security certificate to the unenrolled device132when the pair, and the unenrolled device132can include the certificate with the request.

At stage514, the enrolled device122can decrypt the resource request. For example, the public key used by the unenrolled device132to encrypt the request can correspond to the private key at the enrolled device122, and the enrolled device122can decrypt the request using the private key. Decrypting the request can reveal which resource the unenrolled device132is requesting so that the enrolled device122knows where to send the request.

At stage516, the enrolled device122can send the resource request to the UEM server112. The UEM server112that receives the request can depend on the request. In an example where the request includes a URL for a UEM web application, and the UEM server112can be a web server that hosts the web application. The UEM web application can send an HTTP request to the UEM server112using the provided URL. In one example, the request can identify a UEM resource, and the enrolled device122can send an identifier of the UEM resource to the UEM server112. In one example, this can be done using an API call to the UEM server112. The UEM server112can then identify another server or device within the UEM system110that provides the request UEM resource. In one example, the enrolled device122can send the resource request to the UEM server112using a secure channel, such as through an established VPN connection open with the UEM server112.

At stage518, the UEM server112can send the requested resource to the enrolled device122. In one example, the UEM server112can send a data file corresponding to the UEM resource. As an example, the UEM server112can send an HTML, XML, or JSON file corresponding to or including the UEM resource. The UEM server112can send the UEM resource using an HTTP request, API call, or other network transmission protocol. In one example, the UEM server112can send the UEM resource through a secure VPN connection with the enrolled device122.

At stage520, the enrolled device122can encrypt the UEM resource. For example, the enrolled device122can encrypt the UEM resource using the public key received from the unenrolled device132during the pairing process. This public key can correspond to a private key securely stored at the unenrolled device132.

At stage522, the enrolled device122can send the encrypted resource to the unenrolled device132. For example, when the unenrolled device132connects to the enrolled device122at stage508, the unenrolled device132can provide its local IP address to the enrolled device122. The enrolled device122can then send the encrypted UEM resource to the unenrolled device132using that local IP address. In some examples, the enrolled device122can send the encrypted UEM resource using other network transmission methods, such as BLE, WIFI DIRECT, or NFC.

At stage524, the unenrolled device132can decrypt the UEM resource. For example, the unenrolled device132can decrypt the UEM resource with the private key generated during the pairing process. The UEM browser150bcan then display the resource on the unenrolled device132for the user. In an example, the user can continue to access UEM resources at the unenrolled device132using the method described above. For example, where the UEM resource is a web application, the user can use the web application within the UEM browser150b. When a user interaction with the web application requires additional resources, the unenrolled device132can request and receive the additional resources as needed using the method described above.

In an example, the user can freely access UEM resources, such as freely using a UEM web application, on the unenrolled device132so long as certain conditions are met. For example, the unenrolled device132can continue to request and receive UEM resources so long as both devices122,132are connected to the same local network, the local network continues to meet security requirements, and the devices122,132continue to meet security requirements. For example, the management application140can continuously monitor the local network and devices122,132, and if any of them fail UEM security requirements, the management application140can restrict the unenrolled device's132access to the UEM system110. In one example where a security flaw is detected, the management application140can instruct the UEM browser150bto wipe any UEM resources previously sent to the unenrolled device132.

FIG.6is a sequence diagram of an example method for accessing UEM system resources with the IoT device134through the enrolled device122. At stage602, the IoT device134and the enrolled device122can establish a connection with each other. For example, a user can connect the enrolled device122to the IoT device134using a direct connection method, such as BLE, WIFI DIRECT, or ZIGBEE. As an example, the user can put the IoT device134into a pairing mode based on specifications of the IoT device134, and the user can instruct the enrolled device122to search for new devices from within the management application140. The management application140can detect the IoT device134and establish a connection.

At stage604, the IoT device134can send a unique ID to the enrolled device122. In an example, the unique ID can be a hardware ID, such as a vendor-defined string of alphanumeric characters that identifies the IoT device134, such as a serial and model number, an International Mobile Equipment Identity (“IMEI”) number, or a vendor-specific ID type.

At stage606, the enrolled device122can register the IoT device134with the UEM server112. For example, the enrolled device122can send a registration request for the IoT device134to the UEM server112that includes the unique ID. The UEM server112can store the unique ID so that the IoT device134can be identified and verified later for data transmissions. In one example, the enrolled device122can install a certificate or encryption key at the IoT device134that can be used for verification. For example, the enrolled device122can install a Transport Layer Security (“TLS”) certificate, a symmetric key, or an asymmetric key. The certificate or encryption key can be provided by the UEM server112, in an example.

At stage608, the IoT device134can detect the enrolled device122. For example, the IoT device134can scan for nearby enrolled devices122. The IoT device134can perform the scan continuously, periodically, on a schedule, on demand, or some combination of these. For example, the IoT device134can be configured to scan for enrolled devices120during times when enrolled devices120are most likely to be nearby, such as during business hours. In another example, the IoT device134can scan for enrolled devices120when it has a payload to send to the UEM server112.

In an example, the enrolled devices120can be configured to send a broadcast that IoT devices134can detect. In one example, the enrolled devices120can send the broadcast using a low-energy method like BLE. When the enrolled device122is close enough that the IoT device134can detect the broadcast, the IoT device134can detect the broadcast. In some examples, the IoT device134can send the broadcast and the enrolled device122can be configured to listen for such broadcasts.

At stage610, the IoT device134can connect to the enrolled device122and send the unique ID. In one example, the IoT device134can send a connection request in response to detecting the enrolled device122. The IoT device134can send its unique ID so that the enrolled device122can verify the IoT device134at stage612. For example, the enrolled device122can send the unique ID to the UEM server112at stage614, and at stage616the UEM server112can check the unique ID against known unique IDs of IoT devices134to verify the IoT device134. In one example, the IoT device134can also send a certificate to the enrolled device122, which the enrolled device122can send to the UEM server112. The UEM server112can authenticate the IoT device134using the certificate, including ensuring that the certificate matches the proper unique ID of the IoT device134.

At stage618, the enrolled device122can send a session request to the UEM server112. The session request can be on behalf of the IoT device134. For example, the IoT device134may not have network capabilities that allow it to connect to the UEM server112. The requested session can be a temporary and interactive information interchange whereby the IoT device134and UEM server112can exchange information through the enrolled device122.

At stage620, the UEM server112can open the request data transfer session. The UEM server112can notify the enrolled device122, which can in turn notify the IoT device134.

At stage622, the IoT device134can send IoT data to the UEM server112through the enrolled device122. For example, the IoT device134can send data to the enrolled device122, and the enrolled device122in turn can send the data to the UEM server112. The IoT data that the IoT device134sends can be based on instructions from the UEM server112. For example, when the IoT device134is registered at stage606, the UEM server112can send instructions to the IoT device134through the enrolled device122that indicate what data to collect and send. For example, the UEM server112can instruct the IoT device134to send event logs, telemetry data, and other data. Alternatively or additionally, the UEM server112can request certain information after the session is opened with the IoT device134.

At stage624, the UEM server112can send UEM data to the IoT device134through the enrolled device122. UEM data can include data collection instructions, firmware updates, security updates, and updated security certificates, as some examples. For example, where the UEM server112has a firmware update for a type of IoT device134, the UEM server112can wait for the IoT device134to open a session through an enrolled device122. Once the session is opened, the UEM server112can send the firmware update file to the enrolled device122, and the enrolled device122can transfer the firmware update file to the IoT device134.

At stage626, the UEM server112can close the session. For example, the IoT device134and the UEM server112can each confirm that the data transfer is complete. In response, the UEM server112can close the session. In an example, closing the session can include sending instructions to the enrolled device122to terminate its connection with the IoT device134.

FIG.7is a sequence diagram of another example method for accessing system resources with the IoT device134through enrolled devices122. In this example method, the IoT device134can already be registered with the UEM system110. For example, as described in stages602,604, and606ofFIG.6above, the IoT device134can have already connected to an enrolled device122and provided a unique ID to the enrolled device122. The enrolled device122can have registered the IoT device134with the UEM server112, provided the unique ID to the UEM server112, and provided any security certificates to the IoT device134.

At stage702, the IoT device134can detect a first enrolled device122. The first enrolled device122can be any device that is enrolled with the UEM system110and has permissions to facilitate data transfer sessions with IoT devices134. In one example, the IoT device134scan for nearby enrolled devices122. The first enrolled device122can be configured to send a broadcast that IoT devices134can detect, such as a BLE broadcast. When the first enrolled device122is close enough to the IoT device134, the IoT device134can detect the broadcast. In an alternative example, the IoT device134can send the broadcast and the first enrolled device122can be configured to listen for such broadcasts. This can be more efficient in examples where the IoT device134has a continuous power source and battery life is not a concern for the IoT device134.

At stage704, the IoT device134can connect to the first enrolled device122. In one example, the IoT device134can send a connection request in response to detecting the first enrolled device122. After connecting, at stage706, the IoT device134can send its unique ID to the first enrolled device122. In one example, the IoT device134can also send any security certificate that it received during registration.

At stage708, the first enrolled device122can verify the IoT device134. For example, the enrolled device122can send the unique ID and any certificates to the UEM server112at stage710. Then, at stage712, the UEM server112can check the unique ID against known unique IDs of registered IoT devices134to verify the IoT device134. The UEM server112can also verify any certificates received from the IoT device134.

At stage714, the first enrolled device122can send a session request to the UEM server112. The session request can be on behalf of the IoT device134. For example, the IoT device134may not have network capabilities that allow it to connect to the UEM server112. The requested session can be a temporary and interactive information interchange whereby the IoT device134and UEM server112can exchange information through the first enrolled device122. At stage716, the UEM server112can open a data transfer session with the IoT device134through the first enrolled device122. The UEM server112can notify the enrolled device122, which can in turn notify the IoT device134.

At stage718, the IoT device134can send IoT data to the UEM server112through the first enrolled device122. For example, the IoT device134can send data to the first enrolled device122, and the first enrolled device122in turn can send the data to the UEM server112. The IoT data that the IoT device134sends can be based on instructions from the UEM server112. For example, during registration, the UEM server112can send instructions to the IoT device134through the registering enrolled device122that indicate what data to collect and send. For example, the UEM server112can instruct the IoT device134to send event logs, telemetry data, and other data. Alternatively or additionally, the UEM server112can request certain information after the session is opened with the IoT device134.

In an example, stage718can include the UEM server112sending UEM data to the IoT device134. UEM data can include data collection instructions, firmware updates, security updates, and updated security certificates, as some examples. For example, where the UEM server112has a firmware update for a type of IoT device134, the UEM server112can wait for the IoT device134to open a session through an enrolled device122. Once the session is opened, the UEM server112can send the firmware update file to the enrolled device122, and the enrolled device122can transfer the firmware update file to the IoT device134.

At stage720, the IoT device134can lose connection with the first enrolled device122. For example, the first enrolled device122can be moved away from the IoT device134and out of data transfer range or the first enrolled device122can be powered down. As an example, the first enrolled device122can belong to a user that walks near the IoT device134while in possession of the first enrolled device122. The IoT device134can connect to the first enrolled device122and begin exchanging data with the UEM server112. Before the session ends (i.e., before the IoT device134and the UEM server112are done sending data), the user can walk out of transmission range with the first enrolled device122.

At stage722, the UEM server112can detect the lost connection. In one example, the UEM server112can lose connection with the first enrolled device122. Alternatively, the first enrolled device122can notify the UEM server112that it lost connection with the IoT device134.

At stage724, the UEM server112can save the session information. For example, the UEM server112can create a log that indicates what data it successfully received from and sent to the IoT device134. In one example, the first enrolled device122can inform the UEM server112what data it successfully sent to the IoT device134before the disconnection occurred. The UEM server112can use the saved session information to continue the data transfer the next time the IoT device134is able to reconnect to the UEM server112.

For example, at stage726, the IoT device134can detect a second enrolled device122. The second enrolled device122can be the same or different from the first enrolled device122, depending on the example. Similar to stage702, the IoT device134or the second enrolled device122, depending on the example, can send a broadcast that can be detected by other enrolled or registered devices.

At stage728, the IoT device134can connect to the second enrolled device122. In one example, the IoT device134can send a connection request in response to detecting the second enrolled device122, or vice versa. After connecting, at stage730, the IoT device134can send its unique ID to the second enrolled device122. In one example, the IoT device134can also send any security certificate that it received during registration.

At stage732, the second enrolled device122can verify the IoT device134. For example, the enrolled device122can send the unique ID and any certificates to the UEM server112at stage734. Then, at stage736, the UEM server112can check the unique ID against known unique IDs of registered IoT devices134to verify the IoT device134. The UEM server112can also verify any certificates received from the IoT device134. At stage738, the second enrolled device122can send a session request to the UEM server112. Like in stage714, the session request can be on behalf of the IoT device134.

At stage740, the UEM server112can detect the previously saved session. For example, the UEM server112can check the unique ID of the IoT device134against saved logs of previous incomplete sessions. In doing so, the UEM server112can detect the session saved at stage724. Then, at stage742, the UEM server112can reopen the previous session with the IoT device134, except this session can be opened through the second enrolled device122.

At stage744, the IoT device134can finish sending IoT data to the UEM server112through the second enrolled device122. In one example, stage744can include the UEM server112sending any unsent UEM data to the IoT device134.

In some examples, the IoT device134can lose connection again before finishing the data transfer. In such examples, the method can return to stage720and proceed through the remaining stages again, except the IoT device134can connect to a third enrolled device122to establish the session. This cycle can be repeated until the all the necessary data is exchanged between the IoT device134and the UEM server112.

Other examples of the disclosure will be apparent to those skilled in the art from consideration of the specification and practice of the examples disclosed herein. Though some of the described methods have been presented as a series of steps, it should be appreciated that one or more steps can occur simultaneously, in an overlapping fashion, or in a different order. The order of steps presented are only illustrative of the possibilities and those steps can be executed or performed in any suitable fashion. Moreover, the various features of the examples described here are not mutually exclusive. Rather any feature of any example described here can be incorporated into any other suitable example. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the disclosure being indicated by the following claims.