Patent Description:
(<NUM>) Point of sale devices often support multiple communication channels, such as ethernet, Wi-Fi, GSM radio, and Bluetooth. Should one of these channels fail or be compromised, it may go unnoticed until the next transaction attempt. This may lead to transaction delays.

<CIT> discloses monitoring a device Wi-Fi connection status by a broker device using a probe.

Preferred embodiments are specified by the dependent claims.

For a more complete understanding of the present invention, the objects and advantages thereof, reference is now made to the following descriptions taken in connection with the accompanying drawings in which:.

Embodiments are directed to systems and methods for device connectivity management.

Referring to <FIG>, a block diagram of a system for device connectivity management is disclosed according to one embodiment. System <NUM> may include a plurality of clients (<NUM><NUM>, <NUM><NUM>,. <NUM>n), a plurality of agents (<NUM><NUM>, <NUM><NUM>,. <NUM>n), cloud <NUM>, broker <NUM> hosted in cloud <NUM>, and central monitoring service <NUM> also hosted in cloud <NUM>. Clients <NUM><NUM>, <NUM><NUM>,. <NUM>n may support one or more communication channels, including Ethernet, WiFi, GSM radio, Bluetooth, etc., for communicating with broker <NUM>.

In one embodiment, broker <NUM> and/or central monitoring service <NUM> may be hosted one or more datacenter (not shown).

In one embodiment, each client <NUM><NUM>, <NUM><NUM>,. <NUM>n may include an agent <NUM><NUM>, <NUM><NUM>,. <NUM>n that may execute a service that may check in with broker <NUM> over each supported communication channel. In one embodiment, clients <NUM><NUM>, <NUM><NUM>,. <NUM>n may check in at regular intervals, at irregular intervals, on demand, or as otherwise necessary and/or desired.

In one embodiment, browser <NUM> may implement the MQTT messaging protocol, and clients <NUM><NUM>, <NUM><NUM>,. <NUM>n may subscribe to receiving messages from broker <NUM>. In one embodiment, each client <NUM><NUM>, <NUM><NUM>,. <NUM>n may subscribe to broker <NUM> over each of its supported communication channels. For example, if client <NUM> supports Ethernet, WiFi, and GSM, client <NUM> may send a separate subscription message to broker <NUM>.

Although the MQTT protocol is discussed herein, it should be recognized that other protocols may be used as is necessary and/or desired.

In one embodiment, each client <NUM><NUM>, <NUM><NUM>,. <NUM>n may send a "last will and testament," or LWT, message to broker <NUM>. The LWT message is distributed to all other subscribed clients if the sending client does not respond to a "keep alive" message from broker <NUM>.

In one embodiment, broker <NUM> may communicate the keep alive message to each client <NUM><NUM>, <NUM><NUM>,. <NUM>n over each of the client's subscribed communication channels. For example, if client <NUM> supports Ethernet, WiFi, and GSM, broker <NUM> sends a keep alive message to client <NUM> over each of these communication channels.

(<NUM>) Each client <NUM><NUM>, <NUM><NUM>,. <NUM>n may respond to the keep alive message within a certain period. If one of the clients <NUM><NUM>, <NUM><NUM>,. <NUM>n does not respond over one of its subscribed communication channels, broker <NUM> may determine that the client or the communication channel is offline.

In one embodiment, central monitoring service <NUM> may also subscribe to broker <NUM> and may monitor any messages published by broker <NUM>. In one embodiment,.

In one embodiment, central monitoring service <NUM> may receive maintenance update information (e.g., WiFi maintenance), service outage information (e.g., GSM outage information for a certain region), etc. Based on this information and/or messages published by broker <NUM>, central monitoring service <NUM> may provide status updates, instructions, commands, etc. to clients <NUM><NUM>, <NUM><NUM>,. <NUM>n and/or agents <NUM><NUM>, <NUM><NUM>,. <NUM>n through any suitable communication network, including email, SMS, etc..

In one embodiment, agents <NUM><NUM>, <NUM><NUM>,. <NUM>n may take an appropriate action in response to not receiving a keep alive message from broker <NUM>, such as changing the active communication channel. Agents <NUM><NUM>, <NUM><NUM>,. may also execute commands or instructions provided by central monitoring service <NUM>.

Referring to <FIG>, a schematic diagram of an agent is provided according to one embodiment. Agent <NUM> may support a plurality of connections (e.g., Wi-Fi, GSM, Ethernet, etc.). Agent <NUM> may include local monitoring service (LMS) <NUM> that subscribes to, and receives event information, from broker <NUM> in cloud <NUM>.

Although LMS <NUM> is illustrated as being part of agent <NUM>, it should be recognized that LMS <NUM> may be part of a separate entity (not shown) that is executed by client <NUM>. Other configurations may be used as is necessary and/or desired.

Agent <NUM> may manage client <NUM>'s connections to broker <NUM> and may run LMS <NUM> to act on events that are of interest in managing connectivity. For example, the events received from broker <NUM> may relay information about connection interfaces, or about configuration, for example, "connective <NUM> down", or "switch connection <NUM> to primary/preferred path".

Referring to <FIG>, a method for device connectivity management is disclosed according to one embodiment. In step <NUM>, a client, such as a point of sale device, may come online. For example, the client may be powered up.

In step <NUM>, the client may subscribe to a broker over each supported communication channel. For example, the client may subscribe to broker over ethernet, WiFi, GSM, Bluetooth, or any other suitable communication channel.

In one embodiment, the client may communicate a LWT message using the MQTT protocol. Other messaging protocols may be used as is necessary and/or desired.

In step <NUM>, the broker may send a keep alive message to each client over each subscribed communication channel. In one embodiment, the keep alive message may be sent periodically, aperiodically, on demand, or as otherwise necessary and/or desired.

Each client may respond to each keep alive message that it receives over each subscribed communication channel.

In step <NUM>, the broker may determine whether it received responses to the keep alive messages on the subscribed communication channels from each client. If a response is not received on a communication channel, in step <NUM>, the broker may publish a status of the non-responding client(s) and/or communication channel(s) to the responding clients.

In step <NUM>, an agent on the client with a non-responsive communication channel may take an action in response to publication. For example, the client may select a communication channel to use other than the non-responsive communication channel.

In another embodiment, a client may not receive a keep alive message on its GSM communication channel, but may receive a keep alive message on its WiFi communication channel. This may trigger the client to switch or reprioritize the communication channels.

(<NUM>) In step <NUM>, agents on other clients may evaluate the publication and may take a suitable action, such as changing communication channels, reprioritizing communication channels, etc. For example, if the agent determines that, in view of the publication, the ethernet communication channel may be compromised, it may switch to the WiFi communication channel.

In step <NUM>, the broker may wait for the non-responding client to subscribe again over the non-responsive communication channel, indicating that the communication channel in question has been restored. If, in step <NUM>, it has, the process may repeat.

In step <NUM>, the client may subscribe to a broker over each supported communication channel. For example, the client may communicate over ethernet, WiFi, GSM, Bluetooth, or any other suitable communication channel.

In step <NUM>, the broker may determine whether it received responses to the keep alive messages on the subscribed communication channels. For example, a client may not receive a keep alive message on its GSM communication channel, but may receive a keep alive message on its WiFi communication channel.

If a response is not received on a communication channel, in step <NUM>, the broker may publish a status of the non-responding client(s) and/or communication channel(s) to the responding clients.

In step <NUM>, a central monitoring service, which may also be a subscriber to the broker, may receive the publication and may determine what action, if any to take. For example, the central monitoring service may instruct the non-responsive client to use a communication channel other than the one that is nonresponsive. As another example, the central monitoring service may instruct other clients to use other communication channels. Other actions may be identified as is necessary and/or desired.

In one embodiment, the central monitoring service may receive other information, such as maintenance information, service outage information, and may use this information and/or the status messages to determine an action to instruct the clients to take. In one embodiment, the information may come from a network provider, from a maintenance provider, etc..

In another embodiment, the central monitoring service may receive updated channel priority policies, and may communicate those policies to the clients.

In step <NUM>, the central monitoring service may communicate the action to the client(s). In one embodiment, the communication may occur over any suitable communication channel, including a separate communication channel, such as SMS, email, etc..

In step <NUM>, the client(s) may take action in response to the communication from the central monitoring service.

In step <NUM>, the broker may wait for the non-responding client to subscribe again over the non-responsive communication channel. If, in step <NUM>, it has, the process may repeat.

Referring to <FIG>, a method for device connectivity management is disclosed according to one embodiment.

In step <NUM>, a client, such as a point of sale device, may come online. For example, the client may be powered up.

In one embodiment, the LMS on the client may subscribe to the broker.

In step <NUM>, the broker may detect an event from the broker. In one embodiment, the event may be an event that affects communications, such as a GSM jam or cellular outage event, etc. In another embodiment, the event may be a maintenance event (e.g., WiFi maintenance), a security event (e.g., security keys compromised, etc.). Any other suitable events may be included as is necessary and/or desired.

In step <NUM>, the broker and/or the central management service may communicate the event and/or instructions to the LMS of affected subscribed clients. For example, the central management service may communicate the event type, one or more action to take (e.g., change connection type, such as change from GSM to WiFi), execute maintenance (e.g. switch traffic to different connection type and publish complete message when maintenance is completed), etc..

In step <NUM>, the LMS for the clients may take the appropriate action. For example, an agent executed by the client may interpret the event and may take an appropriate action. In another embodiment, the client may execute the action provided by the central management service.

In one embodiment, machine learning may be used to improve connectivity. For example, data, such as connection times and other telemetry, may be harvested and events may be detected based on past events. In one embodiment, machine learning may be used for the client and/or central management system may use statistical techniques to develop thresholds, rules, etc..

It will be appreciated by persons skilled in the art that the present invention is not limited by what has been particularly shown and described hereinabove. Rather the scope of the present invention includes both combinations and sub-combinations of features described hereinabove and variations and modifications thereof which are not in the prior art. It should further be recognized that these embodiments are not exclusive to each other.

It will be readily understood by those persons skilled in the art that the embodiments disclosed here are susceptible to broad utility and application. Many embodiments and adaptations of the present invention other than those herein described, as well as many variations, modifications will be apparent from or reasonably suggested by the present invention and foregoing description thereof, without departing from the scope of the invention.

Claim 1:
A system (<NUM>) for device connectivity management, comprising:
a plurality of client devices, each client device supporting a plurality of communication channels; and
a broker (<NUM>) in communication with each of the client devices over each supported communication channel, the broker (<NUM>) comprising at least one computer processor;
wherein:
each client device is configured to send a subscription message to the broker (<NUM>) over each supported communication channel;
the broker (<NUM>) is configured to initiate and send each subscribed client device a keep alive message over each of the subscribed device's subscribed supported communication channels;
each subscribed client device is configured to respond to the keep alive message over each of the subscribed device's subscribed supported communication channels that received the keep alive message;
the broker (<NUM>) is configured to publish a status message comprising a status of non-responding subscribed client devices and a status of each non-responding communication channel of each of the subscribed client devices to each subscribed client device over each of the supported communication channels; and
one of the plurality of subscribed client devices is configured to execute an action in response to the status message, wherein the one of the plurality of subscribed client devices is a responding subscribed client device with a non-responding supported communication channel.