Patent ID: 12192889

To facilitate understanding, identical reference numerals have been used, where possible, to designate identical elements that are common to the figures. It is contemplated that elements disclosed in one embodiment may be beneficially used in other embodiments without specific recitation.

DESCRIPTION OF EXAMPLE EMBODIMENTS

Overview

One embodiment presented in this disclosure is a method that includes: in response to a triggering network condition occurring, initiating an exchange of a parameter file including non-layer two content via a Generic Advertisement Service (GAS) 802.11 message between an access point (AP) and a station (STA) connected to the AP; and in response to determining that the exchange was unsuccessful, terminating a connection between the AP and the STA.

One embodiment presented in this disclosure is a system that includes: a processor; a communication interface; and a memory storage device including instructions that when performed by the processor enable the system to perform an operation comprising: in response to a triggering network condition occurring, initiating an exchange of a parameter file including non-layer two content via a 802.11 message between an access point (AP) and a station (STA) connected to the AP; and in response to determining that the exchange was unsuccessful, terminating a connection between the AP and the STA.

One embodiment presented in this disclosure is a memory storage device including instructions that when performed by a processor enable the processor to: in response to a triggering network condition occurring, initiate an exchange of a parameter file via a Generic Advertisement Service (GAS) message between an access point (AP) and a station (STA) connected to the AP; and in response to determining that the exchange was successful, maintain the connection between the STA and the AP according to new configuration data included in the parameter file.

Example Embodiments

The present disclosure provides a gating mechanism by which a network can determine whether to persist or terminate a connection with a given STA through the transfer and automatic provisioning of configuration settings. Advantageously, different APs in the network can alter an initially configured connection profile when a STA is handed off to a new AP in the network or as network conditions change (while remaining connected to an initial AP).

As described herein, the network infrastructure (e.g., APs) directly request bundled STA changes through a general software update function to the STAs, which are then redistributed to the relevant layers. In some embodiments, which can be used for various types of gating data exchanges, parameters or a L7 file are exchanged between an STA and the APs. Doing so ensures that a push/pull of L7 data can be used as a gating condition for the continuation/termination of a connection with an STA, or to allow for different levels of ongoing service (e.g., 11v Basic Service Set (BSS) transition exchanges) according to updated QoS parameters. Further, IEEE 802.11 exchanges can be leveraged to allow the APs and the STA to communicate a need to update some STA software parameters. In some embodiments, these exchanges can be used to dynamically push a new QoS whitelist to the STA, thus extending the on-connection application differentiated treatment profile mechanism, for which the profile was pushed before associating the STA and AP. However, in general, this mechanism can be used to push any set of new parameters to the STA, in the form of individual parameters (at or beyond L2) or a container file (e.g., a driver update). This mechanism can also be used to retrieve a set of parameters from the STA (e.g., retrieving Long Term Evolution (LTE) cellular connection data over a prior interval, along with location).

FIG.1illustrates an example networking environment100, according to embodiments of the present disclosure. In the networking environment100, three APs110a-c(generally, AP110) provide three corresponding ranges120a-c(generally, range120) within a wireless network. Several client devices, referred to herein as STA130a-c(generally, STA130), are shown moving through the network environment100, and may transition from receiving service from one AP110to another AP110as the STA130move within or out of the corresponding ranges120in the network.

The APs110may include various networking devices configured to provide wireless networks according to various networking standards or Radio Access Technologies (RAT) (e.g., IEEE 802.11 or “WiFi” networks, BLUETOOTH® networks, “cellular” (including various generations and subtypes thereof, such as Long Term Evolution (LTE) and Fifth Generation New Radio (5G NR)) networks, Citizens Broadband Radio Service (CBRS) networks, proprietary networks). Example hardware as may be included in an AP110is discussed in greater detail in regard toFIG.5.

The networking environment100is illustrated according to the collective ranges120of the AP110disposed in the environment. The APs110offer the various STAs130within the corresponding ranges120network connectivity for various services including voice communication (e.g., telephony services), text communication (e.g., paging functionality, short message service (SMS), multimedia message service (MMS)), and data transmission (e.g., wireless internet access). In various embodiments, the ranges120may represent individual networks or may represent different nodes of a shared network.

Each of the APs110may be provided by different entities in a shared public space and/or may set different rules for how devices are to interact in the networking environment100. For example, a STA130connected to a first AP110amay be allowed or required to act differently than when that same STA130is connected to a second AP110bin the same network. In some aspects, two APs110in the same network may have different whitelists for services that a STA130can connect to, different configuration settings, or the like. For example, an AP110located in a busy intersection that expects multiple STAs130to connect for short periods of time (e.g., while transiting to a destination) may limit the QoS for connected STAs130to thereby accommodate more STAs130at a given time than compared to an AP110located in a secluded location where STAs130are expected to remain stationary for longer periods of time.

The STA130may include any computing device that is configured to wirelessly connect to one or more APs110in the networking environment100. Example STAs130can include, but are not limited to: smart phones, feature phones, tablet computers, laptop computers, desktop computers, Internet of Things (IoT) devices, and the like. Example hardware as may be included in a STA130is discussed in greater detail in regard toFIG.5.

At a high level, the STAs130exchange frames with the APs110to send/receive configuration settings and logs for the network. In one embodiment, the AP110automatically exchanges the configuration settings or logs that the STA130needs to establish/maintain a connection with that AP110, thus dynamically expressing (i.e., with values that may change over time) networking restrictions to a STA130for a particular application (e.g., a web browser, telephony application, conferencing application, email application, game, or any other software requesting/receiving data over a network with the AP110). Additionally, a Mobile Device Management (MDM) device or solution can send configuration settings to a STA130, inline or offline or without auto-provisioning depending on administrator preferences, thus allowing the networking infrastructure (i.e., the APs110—not the MDM server/solution) to change all or a part of the ruleset on the STA130, thus resulting in conditions that are specific to that STA130at that point in time and space. Stated differently, the APs110can control which STAs130remain connected to the network and how those STAs130behave while connected to the network on the fly in response to changes in local conditions observed by the STA130and/or the AP110.

In various embodiments, the local conditions and criteria are based on criteria local to the wireless network (not just based on an enterprise general policy), the position of the device in the network (signal level, form factor, etc.), the locations of neighboring APs110, number of devices connected to the network, available bandwidth in the network, etc., although enterprise level policies (e.g., blocking certain applications, allowing access to certain services/sites, etc.) can also be included in the configuration and profile information in some embodiments.

The profiles can dictate various behaviors of a given STA130while associated with or connected to a given AP110, such as, for example, various QoS levels allowed for individual applications running on the STA130; whitelists or blacklists for various features, applications, or service providers; device driver settings; etc.

In one embodiment, the profile can be exchanged as early in the connection as at association time (i.e., after association has happened). At that time, the AP110to STA130relationship is either to be encrypted (in which case the profile exchange, following unicast frame processes, is also encrypted) or Open. If the network is open, then no data exchanged between the AP110and the STA130are encrypted, and all of the data transmitted are visible and exposed. In some embodiments, the AP110pushes a profile to the STA130at the earliest possible opportunity without user intervention (i.e., without the need for a user to click a link, separately submit credentials, etc.), and can repeatedly push a new profile whenever needed or in response to an update or change in the criteria of the network. As such, the present disclosure provides a mechanism that not only provides an element of automation, but also a choreography where the success of the exchange is verified. For example, after a STA130receives and applies a profile, the AP110notices the STA130behaving as directed in the new profile, whereas if the STA130does not receive (or receives and does not apply) the profile, the AP110can also notice the noncompliant behavior and may take remedial action as necessary (e.g., dropping the STA130from the network).

In one embodiment, the configuration only applies to the current SSID and L2 session/connection. For example, when a STA130enters a mall, stadium, campus, or other public space with an available network, the STA130can receive the policy from the AP110for that network's SSID/WLAN, but the rules may change as the user walks around to different locations in the public space served by different APs110or as time progresses and networking conditions change. These rules cease to be applied and are removed from the STA130when the STA130disconnects from the SSID/WLAN. Stated differently, the rules are not installed ‘forever’ on the STA130; the rules are just applied during the session in which the rules are appropriate and/or required by a given AP110to which the STA130is connected. In various embodiments, the configuration file/parameters are received by the 802.11 device driver on the STA130and stored in local RAM (i.e., non-persistent storage) on a per SSID/WLAN basis in the Wi-Fi connection cache of the STA1130and replaced in memory by updates received for the same SSID/WLAN. Accordingly, this configuration only persists for the duration of an association/disassociation cycle and does not survive device resets, etc. In some embodiments, the rules are defined per SSID and BSSID so that the rules can be updated as the STA130moved from one AP110to another. In some embodiments, the rules are defined temporally and locally, so that the AP110can update the rules during a single session at various times. This temporary rule set mitigates any form of synchronization, segment tracking or versioning problems prevalent in other forms of “file download” and minimizes message exchanges during all of the critical association processes.

FIG.2illustrates a field delineation of an 802.11 message200(generally, message200) sent between an AP110and a STA130, according to embodiments of the present disclosure. The message200can be a GAS (Generic Advertisement Service) message that transports an Access Network Query Protocol Message (ANQP) to provide information about the network that the AP110is a part of and that the STA130seeks to connect to (or remain connected to), although the present disclosure contemplates various other types of frames as possible for transmitting messages for auto-provisioning (e.g., Cisco Compatible extension (CCX) exchange, data frame with specific flag or Information Element (IE) identified by the other side as an exchange marker, etc.). The message200carries non-layer 2 (non-L2), which may include parameter files and other payloads associated with different networking layer data.

A message200from the STA130to the AP110can request additional/updated parameters or indicate that the STA130is capable of receiving updated parameters, according to the present disclosure. In some embodiments, the STA130indicates that the message200is expected to be a public or a protected/private action frame (e.g., in a category field210of the message200) and that the message200is transmitted in an initial request format or in a comeback request format (e.g., in an action field220of the message200). The message200includes data to transmit to the AP110as a piggybacked payload290(e.g., in a protocol field240of the message200as part of a protocol tuple260) that uses a vendor-specific format and that requests a response from the AP110(e.g., in a query request field250of the message200).

A message200from the AP110to the STA130can communicate parameter information for the network and respond to the STA130to indicate that future updates may be pushed to the STA130from the AP110, according to the present disclosure. In some embodiments, the AP110indicates that the message200is expected to be a public or private/protected action frame (e.g., in a category field210of the message200) and that the message200is transmitted in an initial response format or in a comeback response format (e.g., in an action field220of the message200) and indicates that a request message200from the STA130was (or was not) successfully received (e.g., in a status code field230). The message200includes data to transmit to the STA130as a piggybacked payload290(e.g., in a protocol field240of the message200as part of a protocol tuple) that uses a vendor-specific format and that requests a response from the AP110(e.g., in a query request field250of the message200).

Although not illustrated, the message200can include other fields, such as, for example, response delay fields, dialog tokens, length fields, checksum fields, and the like. Additionally, the values held in the various fields, the relative positions in the message200of the various fields, and the sizes/lengths of the various fields may differ between various embodiments based on the standard or protocol used for communicating between the AP110and the STA130

FIG.3is a flowchart of a method300, according to embodiments of the present disclosure. Method300optionally begins at block310, where the AP110and the STA130use a negotiated mutual identification mechanism that enables both the AP110and the STA130to know that a later exchange may potentially be needed/requested in the currently provided network. In one embodiment, the STA130uses a STA-side specific IE to signal support for the features enabled by auto-provisioning and later exchanges (e.g., through specific messages, or specific bits (e.g., extension bits) or fields in upstream frames). For example, extension bits can be used for mutual recognition between the STA-side IE and the AP-side IE. In another embodiment, specific bits in the AP-side IE and in the STA-side specific IE can also be used to trigger the exchange. This phase can help identify subsets of devices that may use or rely on the exchange. Block310is optional and may be omitted in some embodiments, as the exchange process is individual to a given STA-AP connection, and some embodiments of method300may therefore begin instead with block320.

At block320, the STA130triggers an exchange in response to detecting specific triggering conditions. For example, the triggering conditions can be a new association or roaming to a new BSSID, a WiFi failure rate beyond target threshold, or the like. The STA130can also communicate various thresholds to the AP110for the AP110to observe as triggering conditions on behalf of the STA130(e.g., network congestion rates). In some embodiment, the STA130provides information about the hardware, software, or user of the STA130to the AP1110, and identification or authentication of which can act as a triggering condition (e.g., recognizing a user type or trusted hardware associated with privileged access, recognizing a deprecated software version associated with restricted access). In response to detecting the triggering conditions, the STA130uploads or downloads a set of parameters or a file to/from the AP110(that the STA130is currently connected to) in a message200. In various embodiments, the exchange request can occur at association time, at roaming time, or can be triggered by either side (STA130or AP110) at any point of the association phase or during the session. In one embodiment, the AP/wireless LAN controller (WLC) can gate a STA's continued association with a file exchange. For example, association continues only if a QoS whitelist is pushed to the STA130; or, WiFi exchange will be allowed only if the STA130uploads LTE connection parameters to the AP110. The AP/WLC can contain the file locally, or retrieve it from a server for retransmission to the STA130. The AP110then acts as a proxy between a data retrieving standard technique over the wire (e.g., File Transfer Protocol (FTP)) and L2 exchange of that file over the radio link with the STA130.

In various embodiments, a request triggered by the STA130can include the STA130sending a GAS initial request publicly (i.e., unencrypted) or privately (e.g., in a protected mode (i.e., encrypted)). In summary, the query request element carries the request type indicating at least upload/download direction of exchange and a data type to exchange.

At block330, the STA130determines whether the data to be exchanged will be short enough to be contained in a single message to/from the AP110or too long to be contained in a single message to/from the AP110. In various embodiments, the message is the body of a GAS response (as a vendor specific content field), and the threshold amount of data that can be contained therein is 255 octets. When the amount of data is at or below the threshold, method300proceeds to block350. When the amount of data is above the threshold, method300proceeds to block360.

At block340, when the message200can contain all of the data to be exchanged, the message200is exchanged with the data included therein. The information included in the message identifies a type of the data being exchanged, a separator, and the payload data. For example, in one embodiment, the data type is set to “QoS whitelist,” the separator is a checksum byte, and the payload is the list of application bundle identifiers (IDs) to include in the whitelist for the local SSID (e.g., two bytes per bundle ID). In contrast to other solutions, the STA130does not need to transmit the entire profile (e.g., an xml file), but simply the marker of where the data fits (e.g., the QoS section of targeted SSID) in an existing file along with an encoding of the data (e.g., bundle IDs instead of application names). Advantageously, method300allows for the transmission of elements that are not L2, including whether these elements have consequences on the L2 behavior. For example, a QoS whitelist is not L2. For example, the content can be a driver update (L7 executable file) that will change the STA130L2 behavior.

At block350, when the data are too long to fit in a single message200(e.g., a signal log upload case), the STA130determines how to indicate and transmit the data over multiple messages200based on network settings including whether the connection is protected (e.g., open versus encrypted). The STA130may elect to proceed to block360when the messages200are protected (i.e., encrypted) or to block370when the messages200are either open or protected.

At block360, the STA130splits the data into multiple payloads290that can each fit into an associated message200. The payload290includes an exchange ID that uniquely identifies the data to be sent (e.g., a size and exchange checksum). One or more data frames follow the initial exchange, either in a burst of several sequential frames or in non-sequential frames (e.g., temporally spaced apart) that each include an associated payload290representing a portion of the data to be transferred. The exchange ID value is present in the message200and allows the AP110to identify which portion of the data a given payload290represents.

At block370, the STA130adds a comeback message identifier to the message200to signal the need for more frames to transmit all of the data. The comeback exchange is used iteratively (e.g., send, receive confirmation, send next, receive next confirmation, etc.) to complete the exchange until an EndOfFile signal is received.

Method300proceeds from blocks340,360, and370to block380, where (once the exchange completes) an optional dialog (e.g., a GAS request/response with response with null data type) is transmitted to ensure that the data transfer is completed. When the data transfer is completed successfully, the STA130remains connected to the AP110, and implements the profile information transferred thereto, and method300may conclude.

When the data transfer did not complete successfully, one of the AP110and the STA130can signal the other that the exchange did not complete successfully. An unsuccessful transfer can happen when the local device cannot successfully consume the data received, or because an external device (e.g., a network server) signals that the data received did not fulfil one or more requirements. If the exchange fails, method300returns to block320, where the STA130re-attempts the exchange. The STA130may re-attempt the exchange up to a predefined number of times (e.g., retry up to X times) before proceeding to block390, where the connection between the STA130and the AP110is terminated and method300may then conclude. The STA130may later attempt to connect to the AP110, and can then receive the updated parameters at re-association.

FIG.4is a flowchart of a method400from the perspective of the AP110rather than the STA130as in method300, according to embodiments of the present disclosure. Method400optionally begins at block410, where the AP110and the STA130use a specific mutual identification mechanism that enables both sides to know that a later exchange is potentially needed in the currently provided network. In one embodiment, the AP110uses an AP-side specific IE to signal support for the features enabled by auto-provisioning and later exchanges (e.g., through specific messages, or specific bits or fields in downstream frames). For example, extension bits can be used for mutual recognition between the STA-side IE and the AP-side IE. In another embodiment, specific bits in the AP-side IE and in the STA-side specific IE can also be used to trigger the exchange. This phase can help identify subsets of devices that may need the exchange. Block410is optional and may be omitted in some embodiments, as the exchange process is individual, and some embodiments of method400may therefore begin instead with block420.

At block420, the AP110triggers an exchange in response to detecting specific triggering conditions. For example, the triggering conditions can be a new association with a new STA130, a STA130with an existing association disconnecting from the AP110, QoS thresholds reached by or changed by the STA130(or an application thereon), the AP110recognizing a user type for the STA130(e.g., guest versus employee), a length of time for the connection between the AP110and the STA130(e.g., improve QoS after M minutes, degrade QoS after H hours), or the AP110recognizing a STA type or set of characteristics (chipset type, etc.). The AP110then requests a push or pull of parameters or a file from the STA130. The exchange can be an initial exchange or a gating for continuation of the STA130association. One advantage here is that a file or parameter (L7) exchange determines the continuation of the L2 session, without the requirement of an external server (e.g., posture) returning a success condition to the network element. Here the infrastructure is independently managing the exchange and the successful conclusion (or failure) thereof. In one embodiment, the AP/WLC can gate the continued association with the STA130with a file exchange. For example, association continues only if a QoS whitelist is pushed to the STA130; or, WiFi exchange will be allowed only if the STA130uploads LTE connection parameters to the AP110. The AP/WLC can contain the file locally to push, or retrieve that file from a server. The AP110then acts as a proxy between a data retrieving standard technique over the wire (e.g., FTP) and L2 exchange of that file over the radio link.

When the AP110detects a STA130requiring a new data exchange phase (e.g., because the STA130is initially detected in the range120of the AP110by probes, the association moves to an association or a request phase), the AP110can respond to a query from the STA130with a “no data” message200if no information is available on the infrastructure side about possible content to push to the STA130. Alternatively, the AP110can respond with a “wait” message200, while the AP110retrieves content to push specifically to the STA130. In some embodiments, the AP110runs a quick identity check on the STA130, for example because a message received from the STA130(e.g., according to method300discussed in relation toFIG.3) identifies a tie to a specific realm (e.g., a publicly accessible profile repository, or a customer-specific profile repository matching the station realm or identity) where profiling for various types of STAs130are contained (e.g., either direct content, or association between STA types and content types). This verification may condition the response of the AP110(“no data” or content specific to the STA type or returned realm). Additionally, individual user authentication (e.g., Remote Authentication Dial-In User Service (RADIUS)) may also trigger the return of a profile that contains an indication for specific content to push to the STA130from the AP110.

At block430, the AP110determines whether the data to be exchange will be short enough to be contained in a single message to/from the STA130or too long to be contained in a single message to/from the STA130. In various embodiments, the message is the body of a GAS response (as a vendor specific content field), and the threshold amount of data that can be contained therein is 255 octets. When the amount of data is at or below the threshold, method400proceeds to block440. When the amount of data is above the threshold, method400proceeds to block450.

At block440, when the message200can contain all of the data to be exchanged, the message200is exchanged with the data included therein. The information included in the message identifies a type of the data being exchanged, a separator, and the payload data. For example, in one embodiment, the data type is set to “QoS whitelist,” the separator is a checksum byte, and the payload is the list of application bundle identifiers (IDs) to include in the whitelist for the local SSID (e.g., two bytes per bundle ID). In contrast to other solutions, the AP110does not need to transmit the entire profile (e.g., an xml file), but simply the marker of where the data fits (e.g., the QoS section of targeted SSID) in an existing file along with an encoding of the data (e.g., bundle IDs instead of application names). Advantageously, method400allows for the transmission of elements that are not L2, including whether these elements have consequences on the L2 behavior. For example, a QoS whitelist is not L2. For example, the content can be a driver update (L7 executable file) that will change the STA130L2 behavior.

At block450, when the data is too long to fit in a single message200(e.g., a signal log upload case), the AP110determines how to indicate and transmit the data over multiple messages200. The AP110may elect to proceed to block460when the messages200are protected (i.e., encrypted) or to block470when the messages200are open or protected.

At block460, the AP splits the data into multiple payloads290that can each individually fit into an associated message200. The payload290includes an exchange ID that uniquely identifies the data to be sent (e.g., a size and exchange checksum). One or more data frames follow the initial exchange, either in a burst of several sequential frames or not (e.g., temporally spaced apart), which each include an associated payload290representing a portion of the data to be transferred. The exchange ID value is present in a message200and allows the STA130to identify which portion of the data a given payload290represents.

At block470, the AP110adds a comeback message identifier to the message200to signal the need for more frames to transmit all of the data. The comeback exchange is used iteratively (e.g., send, receive confirmation, send next, receive next confirmation, etc.) to complete the exchange until an EndOfFile signal is received.

Method400proceeds from blocks440,460, and470to block480, where (once the exchange completes) an optional dialog (e.g., a GAS request/response with response with null data type) is transmitted to ensure that the data transfer is completed. Alternatively, one of the AP110and the STA130can signal the other that the exchange did not complete successfully. This phase can happen when the local device cannot successfully consume the data received, or because an external device (e.g., a network server) signals that the data received did not fulfil one or more requirements. If the exchange fails, method400returns to block420, where the AP110re-requests the exchange. Otherwise, method400may conclude.

Method400proceeds from blocks440,460, and470to block480, where (once the exchange completes) an optional dialog (e.g., a GAS request/response with response with null data type) is transmitted to ensure that the data transfer is completed. When the data transfer is completed successfully, the AP110maintains the connection with the STA130, and method300may conclude.

When the data transfer did not complete successfully, one of the AP110and the STA130can signal the other that the exchange did not complete successfully. An unsuccessful transfer can happen when the local device cannot successfully consume the data received, or because an external device (e.g., a network server) signals that the data received did not fulfil one or more requirements. If the exchange fails, method400returns to block420, where the AP110re-attempts the exchange. The AP110may re-attempt the exchange up to a predefined number of times (e.g., retry up to X times) before proceeding to block490, where the connection between the STA130and the AP110is terminated and method400may then conclude.

FIG.5illustrates hardware of a computing device500, as may be used in an AP110or a STA130described in the present disclosure. The computing device500includes a processor510, a memory520, and communication interfaces530. The processor510may be any processing element capable of performing the functions described herein. The processor510represents a single processor, multiple processors, a processor with multiple cores, and combinations thereof. The communication interfaces530facilitate communications between the computing device500and other devices. The communications interfaces530are representative of wireless communications antennas and various wired communication ports. The memory520may be either volatile or non-volatile memory and may include RAM, flash, cache, disk drives, and other computer readable memory storage devices. Although shown as a single entity, the memory520may be divided into different memory storage elements such as RAM and one or more hard disk drives.

As shown, the memory520includes various instructions that are executable by the processor510to provide an operating system521to manage various functions of the computing device500and one or more applications522to provide various functionalities to users of the computing device500, which include one or more of the functions and functionalities described in the present disclosure. Additionally, the memory520includes one or more parameter files523indicating the rules sets that the STA130is to use while connected to the AP110. As will be appreciated, when the parameter files523are held in a short term or non-persistent memory (e.g., a RAM device), the parameter files523may be updated with relative ease (compared to long term memory or storage), and can be cleared when the memory520cycles power, thus mitigating any form of synchronization, segment tracking or versioning problems prevalent in other forms of “file downloads” and minimizing message exchanges during association processes. Additionally, the parameter file523that is transmitted can represent a reduced data set from a full parameter file523maintained on the AP110, including just the updated or new configuration data and omitting configuration data that have not changed since the last exchange (i.e., repeated configuration data).

In the current disclosure, reference is made to various embodiments. However, the scope of the present disclosure is not limited to specific described embodiments. Instead, any combination of the described features and elements, whether related to different embodiments or not, is contemplated to implement and practice contemplated embodiments. Additionally, when elements of the embodiments are described in the form of “at least one of A and B,” it will be understood that embodiments including element A exclusively, including element B exclusively, and including element A and B are each contemplated. Furthermore, although some embodiments disclosed herein may achieve advantages over other possible solutions or over the prior art, whether or not a particular advantage is achieved by a given embodiment is not limiting of the scope of the present disclosure. Thus, the aspects, features, embodiments and advantages disclosed herein are merely illustrative and are not considered elements or limitations of the appended claims except where explicitly recited in a claim(s). Likewise, reference to “the invention” shall not be construed as a generalization of any inventive subject matter disclosed herein and shall not be considered to be an element or limitation of the appended claims except where explicitly recited in a claim(s).

As will be appreciated by one skilled in the art, the embodiments disclosed herein may be embodied as a system, method or computer program product. Accordingly, embodiments may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” Furthermore, embodiments may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.

Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

Computer program code for carrying out operations for embodiments of the present disclosure may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).

Aspects of the present disclosure are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatuses (systems), and computer program products according to embodiments presented in this disclosure. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the block(s) of the flowchart illustrations and/or block diagrams.

These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other device to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the block(s) of the flowchart illustrations and/or block diagrams.

The computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process such that the instructions which execute on the computer, other programmable data processing apparatus, or other device provide processes for implementing the functions/acts specified in the block(s) of the flowchart illustrations and/or block diagrams.

The flowchart illustrations and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments. In this regard, each block in the flowchart illustrations or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the Figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustrations, and combinations of blocks in the block diagrams and/or flowchart illustrations, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

In view of the foregoing, the scope of the present disclosure is determined by the claims that follow.