Systems and methods for dynamic congestion management in communications networks

Systems and methods for dynamic congestion management in communications networks are disclosed herein. According to an aspect, a method can include determining traffic statistics of at least one node in a communications network. The method can also include determining whether the at least one node is congested based on the traffic statistics. Further, the method can include dynamically changing or provisioning a set of at least one traffic shaping rule for application to the at least one node in response to determining that the at least one node is congested.

CROSS REFERENCE TO RELATED APPLICATION

The present application claims priority to the commonly owned U.S. Provisional Patent Application No. 61/420,272, titled SYSTEMS AND METHODS FOR DYNAMIC CONGESTION MANAGEMENT IN COMMUNICATIONS NETWORKS and filed Dec. 6, 2010, which is incorporated herein by reference in its entirety.

TECHNICAL FIELD

The presently disclosed subject matter relates to communications networks. Particularly, the presently disclosed subject matter relates to dynamic congestion management in communications networks.

BACKGROUND

During times of communications network congestion, subscribers using more than their fair share of bandwidth can impact the quality of experience (QoE) of all active subscribers. In addition, certain applications may unnecessarily consume a large portion of bandwidth during times of congestion, thereby impacting the responsiveness and QoE for more interactive applications. These problems may exist even where traffic and policy management (TPM) systems have been deployed.

Provisioning of deep packet inspection (DPI)-enabled traffic management policies to address data network congestion is often an imprecise, iterative science: policies are statically provisioned, results are observed, conclusions drawn regarding the need for further policy changes, and the cycle may then begin again. When congestion occurs despite enforcement of policies currently in place, manual provisioning of policy changes may be required; but this often occurs after the congestion has passed or, at best, with some delay in response to an alarm being raised. Sometimes it is the reoccurring pattern of network congestion that predicates manual provisioning changes, but the network operations staff must first recognize the pattern and assess what changes are needed.

Accordingly, there is a continuing need for improving systems and methods for congestion management in communications networks.

SUMMARY

Disclosed herein are systems and methods for dynamic congestion management in communications networks. According to an aspect, systems and methods disclosed herein may, during times of congestion, dynamically limit bandwidth usage of subscribers using more than their fair share of bandwidth. Such congestion management may be dynamically or automatically implemented so as to address congestion at various points in a network hierarchy.

According to an aspect, a method can include determining traffic statistics of at least one node in a communications network. The method can also include determining whether the at least one node is congested based on the traffic statistics. Further, the method can include dynamically changing or provisioning a traffic shaping rule for application to the at least one node in response to determining that the at least one node is congested.

The presently disclosed subject matter provides: automated detection and mitigation of network congestion by dynamic provisioning of DPI-enabled traffic management policies, so as to address network congestion events in a more timely fashion; and automated evaluation of (possibly repeated) dynamic policy changes and their effectiveness, so as to expedite the provisioning of any necessary, corresponding statically provisioned policies that may mitigate future congestion events in real time.

DETAILED DESCRIPTION

FIG. 1illustrates a block diagram of an exemplary communications network100in which the presently disclosed subject matter may be deployed for dynamic congestion management in accordance with embodiments of the present disclosure. Referring toFIG. 1, a DPI module102having a TPM function104is deployed behind a GGSN106on Gi (GGSN-to-PDN (public data network) interface). In this example, the TPM policy of the TPM function104is not controlled by a policy, charging, and rules function (PCRF). Various embodiments for dynamically managing congestion at one or more nodes in accordance with the present disclosure may be implemented by the TPM function104of the DPI module102; however, any other suitable function of another suitable device or component may be used for dynamically managing congestion at one or more nodes.

In this example, the network100includes various other communications networks such as, but not limited to, the Internet108, a packet core network110, and a radio access network (RAN)112. Computing devices114-128may utilize the Internet108, the packet core network110, and the RAN112for accessing various computing services or content. For example, the Internet108may be communicatively connected to servers130-138that are configured to provide computing services to devices such as the computing devices114-128. For example, the server130may provide a video subscription service, the server132may provide an Internet search service, the server134may provide a peer-to-peer file-transfer service, the server136may provide a video sharing service, and the server138may provide a video subscription service.

Network traffic between the computing devices114-128and the servers130-138may be managed and handled by nodes of the Internet108, the packet core network110, and the RAN112. For example, the Internet may include various network nodes for handling the transmission of data between the servers130-138and the GGSN106. The packet core network110may include network nodes for handling the transmission of data between the GGSN106and serving GPRS support nodes (SGSNs)140, which may communicate with radio network controllers (RNCs)142for the transmission of data. Further, the RAN112may include backhaul network nodes for handling the transmission of data between the RNCs142and NodeBs144. Each RNCs142is configured to control one or more NodeBs144that are connected to it. These networks and nodes may be targeted for dynamic congestion management of network traffic between the computing devices114-128and the servers130-138or other components in the network100in accordance with embodiments of the present disclosure.

It is noted that examples described herein involve a mobile communications network; however, any other suitable communications network may be used to implement system and method embodiments of the presently disclosed subject matter. For example, the presently disclosed subject matter may also be applied to fixed broadband (e.g., DSL technologies (xDSL), fiber-to-the-home (FTTH), and the like), cable networks, or any other suitable type of communications network.

As referred to herein, the term “computing device” should be broadly construed. It can include any type of device capable of communicating with other devices, network nodes, and/or networks. For example, a computing device may be a mobile device such as, for example, but not limited to, a smart phone, a feature (cell) phone, a pager, a personal digital assistant (PDA), a tablet, a mobile computer, or some other device with a wireless or cellular network interface card (NIC). A computing device can also include any type of conventional computer, for example, a desktop computer or a laptop computer. A typical mobile computing device is a wireless data access-enabled device (e.g., an iPHONE® smart phone, a BLACKBERRY® smart phone, a NEXUS ONE™ smart phone, an iPAD® device, or the like) that is capable of sending and receiving data in a wireless manner using protocols like the Internet Protocol, or IP, or the wireless application protocol, or WAP. This allows users to access information via wireless devices, such as smart phones, mobile phones, pagers, two-way radios, communicators, and the like. Wireless data access is supported by many wireless networks, including, but not limited to, CDPD, CDMA, GSM, PDC, PHS, TDMA, FLEX, ReFLEX, iDEN, TETRA, DECT, DataTAC, Mobitex, EDGE, UMTS, HSPA, WiMAX, LTE, LTE Advanced, and other 2G, 3G and 4G technologies, and it operates with many handheld device operating systems, such as PalmOS, EPOC, Windows CE, FLEXOS, OS/9, JavaOS, iOS and Android. Typically, these devices use graphical displays and can access the Internet (or other communications network) on so-called mini- or micro-browsers, which are web browsers optimized for small displays and which may accommodate the reduced memory constraints of many wireless devices. In a representative embodiment, the mobile device is a cellular telephone or smart phone that operates over GPRS, which is a data technology for GSM networks. In addition to a conventional voice communication, a given mobile device can communicate with another such device via many different types of message transfer techniques, including SMS (short message service), enhanced SMS (EMS), multi-media message (MMS), email WAP, paging, or other known or later-developed wireless data formats. Although many of the examples provided herein are implemented on smart phones, the examples may similarly be implemented on any suitable electronic device, such as a computer.

FIG. 2illustrates a flowchart of an example method for dynamic congestion management in accordance with embodiments of the present disclosure. This method may be implemented, for example, by the TPM function104of the system100shown inFIG. 1during times of network traffic congestion, for periodically and dynamically augmenting traffic-management policies. In another example, this method may be partially or entirely automated by the systems and devices described herein. In an example, this method may be implemented by any suitable component or node, such as a DPI system, configured for dynamic provisioning of congestion management policies as disclosed herein. It is noted that the DPI module may be implemented by one or more other components such as, but not limited to, a DPI engine, a statistics storage unit, and a subscriber manager. In one embodiment, described below, the subscriber manager may associate user identities, serving network nodes and device types with the IP addresses of computing devices.

Referring toFIG. 2, the method includes determining traffic statistics of one or more nodes in a communications network (step200). For example, the TPM function104of the DPI module102may determine traffic statistics including, but not limited to, a QoE score for the aggregate of one or more computing devices being served by a given network node, such as computing devices114,116, and118served by NodeB144. The QoE score, for example, may be derived from detected packet drops and retransmissions occurring in the context of Transmission Control Protocol (TCP) connections with computing devices114,116, and118. As an alternative or in addition to determining an aggregate QoE score for NodeB144, TPM function104may determine at least one of aggregate nodal downlink bandwidth, aggregate nodal uplink bandwidth, or aggregate nodal downlink and uplink bandwidth of traffic exchanged with computing devices114,116, and118. Collecting statistics for nodal QoE scores, or for nodal aggregate bandwidth may prove useful in subsequently inferring nodal congestion.

Additional statistics may be collected for possible use in deriving policies to manage nodal congestion. For example, nodal bandwidth statistics may be collected per user, per application, per device, or per some combination of the preceding. For example, nodal bandwidth statistics may be collected per application per user.

The method ofFIG. 2includes determining whether the node(s) are congested based on the traffic statistics (step202). For instance, TPM function104may determine that one of the NodeBs144is congested as depicted inFIG. 1. Continuing an aforementioned example, the TPM function104may determine that the node's aggregate QoE score is falls below a predefined threshold, and thereby ascertains that the node is likely congested. In another example, the TPM function104may assess the aggregate bandwidth of traffic exchanged with computing devices served by a network node against an engineered link capacity for this node. Such an engineered capacity is hereinafter referred to as a link-utilization threshold. If the aggregate bandwidth exceeds a provisioned, nodal, link-utilization threshold, TPM function104may infer that the node is congested.

The method ofFIG. 2includes dynamically changing or provisioning a set of one or more traffic shaping rules for application to the node(s) in response to determining that the node(s) are congested. For example, the TPM function104may dynamically change or provision a traffic shaping rule for application to the congested nodeB144in response to determining that the nodeB is congested. The traffic shaping rules applied to manage nodal congestion may vary in consideration of at least one of service plans associated with users that are served by the congested node, limitations on congestion management permitted by the regulatory environment in which the node resides, and operator-specific policies. For example, where users subscribe to service plans that are tiered on the basis of allowed bandwidth or traffic volume, TPM function104may shape nodal traffic of lower-tier (e.g., “bronze”) users per their service plan before iteratively impacting the traffic of higher-tier (e.g., “silver” and “gold”) users. Or where a user is served by the congested node and subscribes to a plan offering a premium gaming or voice over internet protocol (VoIP) experience, TPM function104may selectively throttle other traffic to ensure that the user enjoys an optimal gaming or VoIP experience. In another embodiment, where “net neutrality” concerns do not prohibit targeting specific applications, TPM function104may during nodal congestion shape traffic of applications which do not directly contribute to the network operator's revenues, in order to provide a better QoE for applications which do contribute to the operator's revenues. Another example would be TPM function104shaping traffic of applications which are less sensitive to delay or packet loss, in order to provide a better QoE for users of applications which are more sensitive. For instance, TPM function104may shape peer-to-peer (P2P) and other file-transfer traffic, as well as downloads of software updates, in order to provide other users with a better VoIP and web browsing experience. Yet another example would be TPM function104applying traffic-shaping rules to drop packets of high-definition (HD), streamed video to computing devices with low-resolution displays, so as to trigger feedback from the computing device to the video head-end, such that lower-definition video is streamed because of network congestion being assumed by the end points. Where “net neutrality” concerns do prohibit targeting specific applications, TPM function104may enforce “usage fairness” traffic-shaping policies that are application-agnostic but which effectively target users that use more than their “fair share” of bandwidth during nodal congestion, so as to limit the detrimental impact of such “bandwidth abusive” users on other users' QoE.

FIG. 3illustrates a flowchart of another example method for dynamic congestion management in accordance with embodiments of the present disclosure. This method may be implemented, for example, by the TPM function104of the system100shown inFIG. 1during times of network traffic congestion for periodically and dynamically augment traffic-management policies. In another example, this method may be partially or entirely automated by the systems and devices described herein. In an example, this method may be implemented by any suitable component or node, such as a DPI system, configured for dynamic provisioning of congestion management policies as disclosed herein.

Referring toFIG. 3, the method includes implementing statically provisioned, baseline traffic-shaping policies (step300). For example, the TPM function104shown inFIG. 1may implement a baseline traffic management policy such as, but not limited to, one of the following: ensuring that downlink traffic's bandwidth does not exceed the network's engineered downlink bandwidth capacity, dropping (policing) traffic associated with illegal peer-to-peer file sharing, or prioritizing premium (e.g., “gold”) users' traffic over others' traffic.

The method ofFIG. 3includes periodically auditing nodal traffic statistics (step302). For example, the TPM function104may audit nodal traffic statistics every 15 minutes as described for step202ofFIG. 2. For instance, every 15 minutes TPM function104may examine nodal aggregate QoE scores or the aggregate traffic bandwidth supported by network nodes.

The method ofFIG. 3includes determining whether there is nodal congestion (step304). For example, as described for step202ofFIG. 2, TPM function104may assess whether nodal aggregate QoE scores have fallen below a provisioned QoE threshold, or whether aggregate traffic bandwidth exceeds a nodal link-utilization or throughput-capacity threshold. For congested nodes, problematic users and applications may be identified.

In response to determining that there is nodal congestion at step304, the method may dynamically augment or provision shaping rules or policies for congested nodes (step306). Such rules or policies may selectively throttle any combination of users, applications, nodal bandwidth usage, and device types. For example, TPM function104may apply traffic-shaping policies, such as those described for step204ofFIG. 2. Policies may be applied to congested nodes at a lowest level in a network hierarchy that is experiencing congestion, since addressing congestion at lower-level nodes may alleviate congestion at nodes higher in the network hierarchy.

In response to determining that there is no longer congestion at a node to which shaping rules or policies were dynamically applied, the method may back out any last dynamic rule set changes (step308). As expounded in connection withFIG. 8, hysteresis techniques may be employed to minimize “ping ponging” between congested and uncongested nodal states.

At step310, the method may log any dynamic rule set changes. Telecommunications products often support time-stamped logging of various system events, including provisioning changes. TPM function104may augment an existing log to record dynamic provisioning of traffic-management policies, accounting for both their application to congested nodes and their disablement or removal from network nodes that are no longer congested. Logging of dynamic policy changes related to congested nodes, together with collection of nodal traffic statistics, allows subsequent analysis of patterns in and effectiveness of these dynamic, congestion-management policies.

FIG. 4illustrates a block diagram of an example system400for dynamic congestion management in accordance with an embodiment of the present disclosure. Referring toFIG. 4, the system400may include a subscriber manager402, a statistics storage unit404, and a DPI engine406configured for inline traffic analysis and management. These components may be operable together for implementing dynamic congestion management in accordance with embodiments of the present disclosure. For example, the DPI engine406may be positioned behind a GGSN408and may manage traffic between one or more subscriber computing devices408and the Internet410. Further, the DPI engine406may provide inline traffic classification—e.g., identify the applications associated with traffic flows—and correlate traffic flows with one or more traffic-management policies, as will be understood. Further, the DPI engine406may collect traffic statistics and store the statistics at the statistics storage unit404.

The subscriber manager402may access the statistics storage unit404to retrieve statistics for informing of congestion detection and dynamic policy creation. Further, the subscriber manager402may provide user, location, and device awareness via analysis of signaling traffic that it taps or is replicated and tunneled to subscriber manager402by the DPI engine406. By user, location, and device awareness, we mean that the IP address of a computing device410may be associated via various signaling with a user identity, with network elements that carry traffic exchanged with said computing device410, and with the type of said computing device410. For example, and as is further elucidated inFIG. 5, subscriber manager402may examine signaling exchanged with GGSN408to provide these associations with the IP address of computing device410. In one embodiment, the subscriber manager402may have a script that is periodically invoked to pull statistics from the statistics storage unit404. The subscriber manager402may subsequently analyze the statistics to identify one or more congested nodes and associated users (or subscribers), device types, and applications. In response to determining that one or more nodes are congested, the subscriber manager402may dynamically create or modify one or more policies (e.g., traffic-shaping or traffic-management rules) to mitigate congestion and push the policy changes to (i.e., provision the policies on) the DPI engine406for enforcement.

FIG. 5illustrates a block diagram of an example system500for tapping into GGSN signaling according to embodiments of the present disclosure. Referring toFIG. 5, the subscriber manager402and DPI engine406may be operable together for tapping signaling traffic exchanged by GGSN106with a network authentication, authorization, and accounting (AAA) component502, a policy and charging rules function (PCRF) component504, or a serving GPRS support node (SGSN). The AAA component502and the PCRF component504may each be suitably implemented within a server or other computing device. The GGSN may exchange RADIUS or Diameter signaling with AAA502, Diameter signaling with PCRF504, and/or GTP-C signaling with SGSN140. Subscriber manager402may directly tap into this signaling, as depicted inFIG. 5. Alternatively, DPI engine406may detect such signaling, and tunnel a copy of the signaling to subscriber manager402. By examining the constituent parts of this signaling, subscriber manager402may associate the IP addresses of computing devices114and116with respective user identities, with network nodes that carry traffic exchanged with said computing devices, and with the respective types of said computing devices. The signaling thus enables subscriber manager402to become user, location, and device aware, such that traffic-management policies (e.g., traffic-shaping or policing rules) may be dynamically provisioned that are specific to users, network nodes, or device types.

Detecting Nodal Congestion

According to embodiments of the present disclosure, nodal congestion may be determined based on throughput- or link-capacity utilization. For example,FIG. 6illustrates a graph showing nodal throughput-capacity utilization over a period of time. Referring toFIG. 6, a congestion threshold, sometimes corresponding to an engineering limit, is shown together with bandwidth usage. Congestion may be inferred when the bandwidth usage is measured to be above said predefined threshold. For example, with reference toFIG. 6, congestion may be detected at 11 p.m., when nodal throughput-capacity utilization exceeds the congestion threshold of 80%. Provisioned objects representing network nodes may have a throughput-capacity or link-capacity property. The objects may be provisioned for both downlink and uplink throughput or link capacities. As a result, throughput or link utilization may be assessed and reported relative to thresholds. A subscriber manager script, such as a script implemented by the subscriber manager402shown inFIG. 4, may periodically compare users' aggregate bandwidth versus the throughput capacity of a node serving them. Nodal congestion (or the cessation of such congestion) may be determined by use of the thresholds. System and method embodiments of the presently disclosed subject matter may employ throughput-capacity or link utilization and/or QoE metrics thresholds for determining nodal congestion.

Identifying Nodes as Targets for Dynamic Congestion Policies

FIG. 7illustrates a block diagram of an example network hierarchy700showing nodes identified as targets for dynamic congestion policies according to embodiments of the present disclosure. The “circled” nodeBs144and RNC142indicate targeted nodes. Provisioned QoE-score and/or link-utilization thresholds indicating congestion may vary between levels in the network hierarchy. Higher level thresholds may be more stringent than lower level thresholds, because more traffic is at stake. With respect to two immediately connected nodes in the hierarchy, we refer to the node at the higher level as the parent node, and the node at the lower level as the child node. For example, each of depicted SGSNs140are children nodes with respect to a GGSN106, but parent nodes with respect to subtending RNCs142.

A goal in selecting target nodes for dynamic policy changes is to minimize the policy changes for nodes that are not experiencing congestion. Another goal is to judiciously and iteratively apply policy changes to both effectively manage congestion and impact a minimal subset of congested nodes. Thus, as depicted inFIG. 7, if a parent node is congested but has one or more congested children nodes to which congestion-management policies could be applied, then the children are candidates for dynamic policies rather than the parent node, since managing congestion at the children may concomitantly address congestion at the parent node. If a congested node has no congested child and congestion-management policies remain that could be applied to the congested node, then that node is targeted for policy changes.

Exceptions for which policies may be applied “globally” at a GGSN106include policies specific to “bandwidth abusive” users who are moving between congested cells. After determining that such users are moving between congested cells, policies specific to such users that are applied to nodes at lower levels in the network hierarchy may be replaced with a policy at the GGSN. (In this case, policies could also be applied to an RNC142or SGSN140that serves the set of congested cells.) Further, exceptions may be applied for roaming “bandwidth hogs” whose traffic is anchored at a congested GGSN106, since the GGSN is the only node serving such users that is under the network operator's control and to which the operator can apply congestion-management policies.

It is also noted that a provisioned interval between periodic audits302should allow time for determining an effect of one or more implemented, dynamic, congestion-management policies. It is further noted that the provisioned interval between audits could be different before and after congestion is detected. Periodic audits enable iterative policy application in the management of congestion. Policies may be iteratively applied to both a given congested node and, as described above in connection withFIG. 7, congested nodes in a network hierarchy. Iteration may also be employed in the removal or disablement of congestion-management policies that have been applied to formerly congested nodes.

It is noted thatFIG. 7depicts only one example network applicable to the presently disclosed subject matter. However, the present subject matter may be applied to any suitable type of network as will be understood by those of skill in the art.

Gathering Data to Inform Dynamic Policies for Congested Nodes

Traffic statistics may provide nodal breakout data of bandwidth usage within a network hierarchy, identifying as well the users, applications and device types that are consuming bandwidth. Nodal uplink and downlink throughout- or link-capacities may be provisioned at subscriber manager402, or subscriber manager402may obtain such capacities from a network management system (NMS).

Backing Out Dynamic Policy Changes

According to embodiments of the present disclosure, hysteresis techniques may be used to back out dynamic policy changes. Such techniques may minimize “ping-ponging” between congested and non-congested states. Hysteresis may be embodied in several exemplary forms. First, hysteresis techniques may include applying two thresholds to trigger entering and leaving congested state. A higher link-utilization or throughput-capacity threshold may be used to enter a nodal congested state, and a lower threshold used to leave the state. In contrast, a lower QoE-score threshold may be used to enter a nodal congested state, and a higher threshold used to exit this state. Second, dynamic policies may be maintained for multiple, consecutive audit intervals without congestion, before they are finally removed. Finally, and by way of example, a per-node stack of dynamic rule-set changes may be kept per audit. In this example, iteratively applied policy changes may be backed out in reverse order.

FIG. 8illustrates a graph showing an example of nodal link utilization undergoing hysteresis techniques to back out a dynamic policy change according to embodiments of the present disclosure. Referring toFIG. 8, whereas congestion-management policy changes may be applied at 11 p.m. when nodal bandwidth exceeds a congestion threshold of 80%, such changes may be backed out at 1:00 a.m. (i.e., at the second-to-last diamond shape in “Bandwidth Usage”), after the second audit below the 75%, non-congestion threshold.

Tuning Congestion Management in the Network

In accordance with embodiments of the present disclosure, dynamic rule-set (i.e., congestion-management policy) changes may be logged to enable pattern analysis. Such logs, in conjunction with traffic statistics, may allow evaluation of the effectiveness of dynamic policies. Such pattern analysis and evaluation of policy effectiveness may be automated. The monitoring of logs and traffic statistics may be periodic, or aperiodic and triggered by a recent (or latest) congestion event in the network. The pattern may be a degenerate pattern of one set of at least one dynamically applied policy.

Persistent patterns of effective, dynamically installed policies may suggest the need to augment the baseline of statically provisioned policies. For example, if a dynamically installed policy is consistently applied to manage nodal congestion during the data busy hour, then the policy may be statically provisioned. Further, a time-of-day condition may be added to the policy. This allows policies to be enforced in real-time rather than during congestion audits.

FIG. 9illustrates a block diagram of an example system900for tuning statically provisioned, congestion-management policies according to embodiments of the present disclosure. Referring toFIG. 9, the system900may include: a congestion audit node402, a system406for managing traffic per installed policies, a system906for storing dynamic policy-change logs, a traffic statistics storage system404, and a system910for assessing effectiveness of repeatedly applied dynamic policies. In an example, static policies may be provisioned at one or more nodes at912. The system406may manage traffic based on the statically and dynamically provisioned policies. The system406may report traffic statistics, before and after dynamic policies are applied and removed, to the statistics storage system404for storage. Using traffic statistics retrieved from statistics storage404, congestion-audit node402may determine whether one or more nodes are congested, provision or remove/disable dynamic congestion-management policies on system406for enforcement, and log dynamic policy changes to the system906. Assessment system910, retrieving dynamic policy changes from logging storage906and traffic statistics from statistics storage404, may detect patterns of dynamic policy changes, and assess the effectiveness of dynamic policies in managing congestion. Assessment system910may provide a report on its analysis, and the report may inform (manual or automated) deliberation on whether dynamically applied policies should have corresponding static policies provisioned on traffic-management system406. Such static policies may be provisioned at912.

Computer program code for carrying out operations for aspects of the present subject matter 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, or assembly language that is specific to the instruction execution system. The program code may be compiled and the resulting object code executed 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 situation scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).

The corresponding structures, materials, acts, and equivalents of all means or steps plus function elements in the claims below are intended to include any structure, material, or act for performing the function in combination with other claimed elements as specifically claimed. The description of the present subject matter has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the subject matter in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the subject matter. The embodiment was chosen and described in order to best explain the principles of the presently disclosed subject matter and the practical application, and to enable others of ordinary skill in the art to understand the presently disclosed subject matter for various embodiments with various modifications as are suited to the particular use contemplated.