Legal claims defining the scope of protection. Each claim is shown in both the original legal language and a plain English translation.
1. A method comprising: providing a keep-alive application programming interface on a device configured to connect to an application client; transmitting one or more messages of a first keep-alive message type from the device; determining keep-alive parameters via the keep-alive application programming interface; transmitting, to a network element via the keep-alive application programming interface, data comprising the keep-alive parameters and information identifying one or more types of keep-alive messages such that the network element is instructed to transmit the one or more types of keep-alive messages to an application server on behalf of the device; receiving, by the device, information from the network element that directs the device to stop transmitting the one or more types of keep-alive messages to the network element, wherein the information that directs the device to stop transmitting the one or more types of the keep-alive messages to the network element directs the device to stop transmitting the first keep-alive message type; determining that an outgoing message is one of the one or more types of keep-alive messages that the device is to stop transmitting to the network element; and filtering, by the device, the outgoing message from outgoing traffic of the device.
A mobile device utilizes a "keep-alive" API to maintain a persistent connection with an application server. The device initially sends keep-alive messages. The API determines keep-alive parameters (e.g., frequency, content) and communicates these, along with the message type, to a network element (like a GGSN). The network element is then instructed to send keep-alive messages to the application server on behalf of the device, freeing the device's resources. The device receives instructions from the network element to stop sending its own keep-alive messages of a specific type (the "first keep-alive message type"). The device then filters and blocks these specified keep-alive messages from its outgoing traffic.
2. The method of claim 1 , wherein the keep-alive parameters include a message sending period, at least one parameter defining message content, and a target IP address of the application server.
This invention relates to network communication systems, specifically methods for maintaining persistent connections between client devices and application servers. The problem addressed is the need to ensure reliable and efficient communication in scenarios where network conditions or server policies may otherwise terminate inactive connections, leading to disruptions in service. The method involves configuring and managing keep-alive parameters to sustain a connection between a client device and an application server. These parameters include a message sending period, which defines the interval at which keep-alive messages are transmitted to prevent connection timeouts. The message content is also configurable, allowing for customization of the data sent to the server, which may include identifiers or status updates. Additionally, the target IP address of the application server is specified to ensure messages are directed correctly. The method further includes dynamically adjusting these parameters based on network conditions or server responses, optimizing connection stability without unnecessary resource consumption. This approach prevents premature disconnection while minimizing bandwidth usage. The system may also monitor server acknowledgments to verify message delivery and adjust parameters accordingly. This ensures robust communication in environments with variable latency or intermittent connectivity.
3. The method of claim 1 , further comprising: prior to transmitting the data, determining, by the keep-alive application programming interface, whether a network element-based keep-alive messaging service exists in a network in which the application client operates.
Before offloading keep-alive message transmission to a network element using the "keep-alive" API, the device first determines whether the network supports this "network element-based keep-alive messaging service". This check is performed via the keep-alive application programming interface to check for functionality in the network where the mobile app is running, before attempting to use the offload feature.
4. The method of claim 3 , further comprising: upon determining that a network element-based keep-alive messaging service does not exist in the network, transmitting, by the device, a first keep-alive message to the application server.
This invention relates to network communication systems, specifically methods for maintaining connectivity between a device and an application server when a network element-based keep-alive messaging service is unavailable. The problem addressed is ensuring reliable communication in networks where traditional keep-alive mechanisms, such as those provided by network elements like routers or gateways, are not present or functional. Without such mechanisms, connections may drop prematurely, leading to service interruptions. The method involves a device monitoring the network to detect the absence of a network element-based keep-alive service. If no such service is detected, the device initiates its own keep-alive process by transmitting a first keep-alive message directly to the application server. This proactive approach ensures that the connection remains active even when network-level keep-alive services are missing. The method may also include additional steps, such as determining the frequency or timing of subsequent keep-alive messages based on network conditions or application requirements. By implementing this fallback mechanism, the device prevents unnecessary disconnections and maintains seamless communication with the application server. The solution is particularly useful in dynamic or unreliable network environments where traditional keep-alive services may not be guaranteed.
5. The method of claim 1 , wherein the keep-alive application programming interface comprises a filter description for defining that the one or more types of the keep-alive messages are not to be forwarded from the device.
The "keep-alive" API includes a "filter description". This description defines which types of keep-alive messages the device should *not* forward from itself. This filter is used to prevent the device from sending keep-alive messages once the network element takes over that responsibility. This reduces redundant traffic and conserves device battery power.
6. The method of claim 5 , wherein the filtering is performed based on the filter description.
The filtering of keep-alive messages, to prevent the device from sending redundant messages after the network element assumes responsibility, is performed based on the "filter description" defined in the "keep-alive" API. This filter description identifies the types of messages to block.
7. The method of claim 1 , wherein the information that directs the device to stop transmitting the one or more types of the keep-alive messages to the network element directs the device to stop transmitting each of a plurality of message types of keep-alive messages.
The instruction from the network element to the device, telling the device to stop sending keep-alive messages, can apply to multiple keep-alive message types simultaneously. The instruction can direct the device to "stop transmitting each of a plurality of message types of keep-alive messages". This allows for more flexible and complete control over which keep-alive tasks are offloaded to the network element.
8. The method of claim 1 , wherein the keep-alive application programming interface does not receive requests for keep-alive functions from the application server while the device is connected to the application server.
While the device is actively connected to the application server, the "keep-alive" API does *not* accept or process requests for keep-alive functions originating from the application server itself. The application server does not directly control the keep-alive function on the mobile device. The device only interacts with the network element to handle keep-alive functions.
9. The method of claim 1 , further comprising: performing a query to determine whether network-element-based keep-alive messaging functionality is available.
Before transmitting the keep-alive parameters to the network element using the API, the device performs a query to check whether the network element-based keep-alive messaging functionality is available in the network. This query happens before the parameters are passed to the network element.
10. The method of claim 9 , wherein the transmitting of the data is part of a negotiating process with the network element to relieve the device of a duty to perform keep-alive messaging.
The transmission of keep-alive parameters from the device to the network element is part of a negotiation process. The goal of this negotiation is to offload the responsibility of sending keep-alive messages from the device to the network element. The device's duty to keep alive the connection is passed onto the network element.
11. The method of claim 1 , wherein the network element is a GPRS gateway serving node.
The network element responsible for sending keep-alive messages on behalf of the device can be a GPRS gateway serving node (GGSN). This is a specific example of a network component capable of handling the keep-alive functionality.
12. The method of claim 1 , wherein the network element is interposed between the device and the application server.
The network element, tasked with sending keep-alive messages on behalf of the device, is located in the network path between the device and the application server. The network element is "interposed between the device and the application server".
13. The method of claim 12 , further comprising: upon determining an IP address of the network element during a dynamic host configuration protocol procedure, requesting, by the device, network address translation-based keep-alive messaging from the network element.
During a dynamic host configuration protocol (DHCP) procedure, the device learns the IP address of the network element. The device then uses this IP address to request network address translation (NAT)-based keep-alive messaging from the network element. This mechanism allows the device to specifically request the offloaded keep-alive functionality.
14. An apparatus comprising: a processor; and a memory storing computer executable instructions that, when executed, cause the apparatus to at least: provide a keep-alive application programming interface that is configured to connect to an application client; transmit one or more messages of a first keep-alive message type; determine keep-alive parameters via the keep-alive application programming interface; transmit, to a network element via the keep-alive application programming interface, data comprising the keep-alive parameters and information identifying one or more types of keep-alive messages such that the network element is instructed to transmit the one or more types of keep-alive messages to an application server on behalf of the apparatus; receive information from the network element that directs the apparatus to stop transmitting the one or more types of keep-alive messages to the network element, wherein the information that directs the apparatus to stop transmitting the one or more types of the keep-alive messages to the network element directs the apparatus to stop transmitting the first keep-alive message type; determine that an outgoing message is one of the one or more types of keep-alive messages that the apparatus is to stop transmitting to the network element; and filter the outgoing message from outgoing traffic of the apparatus.
A mobile device contains a processor and memory. The memory stores instructions that, when executed by the processor, implements a "keep-alive" API. The device transmits keep-alive messages. The API determines keep-alive parameters and sends these, plus message types, to a network element instructing it to send keep-alive messages to the application server on the device's behalf. The device receives instructions to stop sending its own keep-alive messages of a specific type. The device filters and blocks those specified keep-alive messages from its traffic.
15. The apparatus of claim 14 , wherein the keep-alive parameters include a message sending period, at least one parameter defining message content, and a target IP address of the application server.
In the apparatus described, the keep-alive parameters, managed via the API, define the characteristics of the keep-alive messages sent by the network element. These include the interval at which the messages are sent, the message content, and the destination IP address of the application server.
16. The apparatus of claim 14 , wherein the memory further stores computer executable instructions that, when executed, cause the apparatus to: prior to transmitting the data, determine, by the keep-alive application programming interface, whether a network element-based keep-alive messaging service exists in a network in which the apparatus operates.
The apparatus contains instructions to determine if a network element-based keep-alive messaging service exists in the current network, before sending the keep-alive parameters via the keep-alive application programming interface.
17. The apparatus of claim 16 , wherein the memory further stores computer executable instructions that, when executed, cause the apparatus to: upon determining that a network element-based keep-alive messaging service does not exist in the network, transmit a first keep-alive message to the application server.
In the apparatus, if no network element-based keep-alive messaging service exists, the apparatus is instructed to transmit a first keep-alive message directly to the application server.
18. The apparatus of claim 14 , wherein the keep-alive application programming interface comprises a filter description for defining that the one or more types of keep-alive messages are not to be forwarded from the apparatus.
This invention relates to network communication systems, specifically to apparatuses that manage keep-alive messages in a network. The problem addressed is the unnecessary forwarding of keep-alive messages, which can consume bandwidth and processing resources without providing meaningful benefits. The apparatus includes a keep-alive application programming interface (API) that allows for the filtering and control of keep-alive messages. The API includes a filter description that specifies which types of keep-alive messages should not be forwarded by the apparatus. This filtering mechanism prevents the apparatus from transmitting certain keep-alive messages, reducing network traffic and improving efficiency. The apparatus may also include a network interface for receiving and transmitting messages, a processor for processing the messages, and a memory for storing the filter description. The filter description can be dynamically updated to adjust the types of keep-alive messages that are blocked or allowed. This system ensures that only necessary keep-alive messages are forwarded, optimizing network performance.
19. The apparatus of claim 18 , wherein the filtering is performed based on the filter description.
The filtering of keep-alive messages by the apparatus is performed based on the filter description.
20. The apparatus of claim 14 , wherein the network element is a GPRS gateway serving node.
In the apparatus, the network element sending the keep-alive messages can be a GPRS gateway serving node.
21. The apparatus of claim 14 , wherein the memory further stores computer executable instructions that, when executed, cause the apparatus to: upon determining an IP address of the network element during a dynamic host configuration protocol procedure, request network address translation-based keep-alive messaging from the network element.
In the apparatus, upon determining the network element's IP address via DHCP, the apparatus requests network address translation-based keep-alive messaging from the network element.
22. A memory comprising computer executable instructions that, when executed, cause a device to at least: provide a keep-alive application programming interface on the device configured to connect to an application client; transmit one or more messages of a first keep-alive message type from the device; determine keep-alive parameters via the application programming interface; transmit, to a network element via the application programming interface, data comprising the keep-alive parameters and information identifying one or more types of keep-alive messages such that the network element is instructed to transmit the one or more types of keep-alive messages to an application server on behalf of the device; receive, by the device, information from the network element that directs the device to stop transmitting the one or more types of keep-alive messages to the network element, wherein the information that directs the device to stop transmitting the one or more types of the keep-alive messages to the network element directs the device to stop transmitting the first keep-alive message type; determine that an outgoing message is one of the one or more types of keep-alive messages that the device is to stop transmitting to the network element; and filter, by the device, the outgoing message from outgoing traffic of the device.
A memory stores instructions that, when executed by a device, implements a "keep-alive" API. The device transmits keep-alive messages. The API determines keep-alive parameters and sends these, plus message types, to a network element instructing it to send keep-alive messages to the application server on the device's behalf. The device receives instructions to stop sending its own keep-alive messages of a specific type. The device filters and blocks those specified keep-alive messages from its traffic.
Unknown
September 30, 2014
Browse 5M+ US patents with plain-English claim translations and AI-generated analysis.