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: receiving an HTTP Request from a web client by a web server over the Internet; causing the web server to fetch a TCP Round Trip Time (RTT) for a TCP connection on which the HTTP Request arrived; comparing the RTT to a pre-determined threshold; setting a non-standard HTTP Request Header (X-BW) to indicate a high or low bandwidth depending on whether the RTT is below or above the pre-determined threshold; causing a web application at the web server to send a varied response to the web client depending on the value of the X-BW; wherein the web application fetches the bandwidth set by the web server in the non-standard HTTP Request Header (X-BW), and (a) in response to determining that the X-BW indicates high bandwidth, generates inline Cascading Style Sheets (CSS) or JavaScript in the HTTP Response, or (b) redirects or forwards the incoming HTTP Request to a set of different Uniform Resource Locators (URLs) based upon the value of the bandwidth.
A web server determines a web client's network bandwidth by measuring the Round Trip Time (RTT) of the initial TCP connection handshake. When the server receives an HTTP request, it retrieves the RTT for that connection. The RTT is compared against a predefined threshold to classify the connection as high or low bandwidth. The server then sets a custom HTTP request header, "X-BW", to "high" or "low" accordingly. A web application on the server reads this "X-BW" header. If the bandwidth is high, the application generates dynamic CSS or JavaScript directly in the HTTP response. Alternatively, the application can redirect the client to different URLs based on the bandwidth classification.
2. The method of claim 1 , wherein the web server receives the HTTP Request over a Hypertext Transfer Protocol Secure (HTTPS) connection that provides encrypted communication over the Internet along with a secure identification of the web server by the web client.
The bandwidth classification method, where the web server determines a web client's network bandwidth by measuring the Round Trip Time (RTT) of the initial TCP connection handshake and sets a custom HTTP request header "X-BW", is also applicable when the HTTP request is received over an HTTPS connection. This means the communication between the client and server is encrypted and the client securely identifies the web server, while still using the RTT for bandwidth estimation to serve varied content.
3. The method of claim 1 , wherein the web client communicates with the web server over a TCP based network using an application level protocol.
The bandwidth classification method, where the web server determines a web client's network bandwidth by measuring the Round Trip Time (RTT) of the initial TCP connection handshake and sets a custom HTTP request header "X-BW", functions when the web client communicates with the web server over a TCP-based network using an application-level protocol like HTTP. This means that the bandwidth classification works as long as the underlying network uses TCP for reliable communication.
4. The method of claim 1 , wherein the web server classifies the web client's network bandwidth into more than two categories.
The bandwidth classification method, where the web server determines a web client's network bandwidth by measuring the Round Trip Time (RTT) of the initial TCP connection handshake, can be extended to classify the bandwidth into more than two categories (high and low). Instead of just "high" or "low", the server could classify bandwidth as "very high," "high," "medium," or "low," by using multiple RTT thresholds, allowing for more granular content delivery.
5. The method of claim 1 , wherein the web application fetches the bandwidth set by the web server in the non-standard HTTP Request Header (X-BW), and in response to determining that the X-BW indicates low bandwidth, sets longer cache durations in the HTTP Response.
The bandwidth classification method, where the web server determines a web client's network bandwidth by measuring the Round Trip Time (RTT) of the initial TCP connection handshake and sets a custom HTTP request header "X-BW", includes setting longer cache durations in the HTTP response when the "X-BW" header indicates low bandwidth. This allows the web application on the server to instruct the web client to cache content for longer periods, reducing server load and improving performance on slower connections.
6. The method of claim 1 , wherein the web application fetches the bandwidth set by the web server in the non-standard HTTPRequestHeader (X-BW), and in response to determining that the X-BW indicates a low bandwidth, serves a relatively lighter content in the HTTPResponse.
The bandwidth classification method, where the web server determines a web client's network bandwidth by measuring the Round Trip Time (RTT) of the initial TCP connection handshake and sets a custom HTTP request header "X-BW", involves the web application serving lighter content in the HTTP response when the "X-BW" header indicates low bandwidth. This means the server delivers a simplified version of the web page (e.g., lower resolution images, less JavaScript) to improve loading speed on slower connections.
7. The method of claim 1 , wherein the web server redirects or forwards the incoming HTTP Request to different Uniform Resource Locators (URLs) or web applications depending on the value of the RTT.
The bandwidth classification method, where the web server determines a web client's network bandwidth by measuring the Round Trip Time (RTT) of the initial TCP connection handshake and sets a custom HTTP request header "X-BW", allows the web server to redirect or forward the incoming HTTP request to different URLs or web applications based on the RTT value directly, bypassing the need for the custom X-BW header. The different URLs or applications serve content optimized for the specific bandwidth, improving the user experience.
8. The method of claim 1 , wherein the web server sets an indicator for the web client's network bandwidth in a standard HTTP Request Header.
Instead of using a custom HTTP request header ("X-BW"), the web server can set an indicator for the web client's network bandwidth in a standard HTTP request header when the server determines a web client's network bandwidth by measuring the Round Trip Time (RTT) of the initial TCP connection handshake. This avoids the use of a non-standard header, potentially improving compatibility with different clients and proxies.
9. The method of claim 1 , wherein the web server uses information in the HTTP Request Header in addition to the RTT from the TCP connection to categorize the web client's network bandwidth.
In addition to the RTT from the TCP connection, the web server can also use information in the HTTP request header to categorize the web client's network bandwidth when the server determines a web client's network bandwidth by measuring the Round Trip Time (RTT) of the initial TCP connection handshake. This includes checking the user-agent string (to identify device type) or the Accept-Encoding header (to see if the client supports compression), which allows for a more accurate bandwidth estimation.
10. The method of claim 1 , wherein the web server uses information in a HTTP Cookie to categorize the web client's network bandwidth.
Instead of using RTT or request headers directly, the web server can utilize information stored in HTTP cookies to categorize the web client's network bandwidth. This can be used in addition to the bandwidth classification based on the Round Trip Time (RTT) of the initial TCP connection handshake. For example, a cookie might store a user's preferred content quality, overriding the automatically determined bandwidth.
11. The method of claim 1 , further comprising causing the web server to fetch the TCP RTT for the TCP connection on which the HTTP Request arrived and using a particular TCP RTT value that was calculated as part of a three-way TCP handshake associated with the connection.
When the web server determines a web client's network bandwidth by measuring the Round Trip Time (RTT) of the initial TCP connection handshake, the server specifically uses the RTT value that was calculated as part of the three-way TCP handshake process when establishing the connection. This ensures that the RTT value is accurate and reflects the initial network conditions between the client and server.
12. A data processing method comprising: receiving an application level protocol Request from a client by a server over the Internet; causing the web server to fetch a Round Trip Time (RTT) for a transport connection on which the Request arrived; comparing the RTT to a pre-determined threshold; setting a header value in a Response in the application level protocol to indicate a high or low bandwidth depending on whether the RTT is below or above the pre-determined threshold; causing an application program at the server to send a varied response to the client depending on the value of the header value; wherein the web application fetches the bandwidth set by the web server in the non-standard HTTP Request Header (X-BW), and (a) in response to determining that the X-BW indicates high bandwidth, generates inline Cascading Style Sheets (CSS) or JavaScript in the HTTP Response, or (b) redirects or forwards the incoming HTTP Request to a set of different Uniform Resource Locators (URLs) based upon the value of the bandwidth.
A server estimates client bandwidth based on transport connection Round Trip Time (RTT). When a client sends a request, the server retrieves the RTT of that connection and compares it to a threshold to determine high or low bandwidth. The server sets a header value in its response indicating high or low bandwidth. An application on the server uses this header value. If bandwidth is high, the application generates dynamic CSS or JavaScript in the HTTP response or redirects the client to different URLs optimized for that bandwidth. This method applies to any application-level protocol.
13. The method of claim 12 , wherein causing the server to fetch comprises causing the server to fetch the RTT for any one of: a connectionless network transport protocol and SCTP.
In the bandwidth estimation method based on transport connection RTT, fetching the RTT can involve fetching the RTT for connectionless network transport protocols or SCTP, instead of TCP. This makes the method applicable to different transport layer protocols, not just TCP, for estimating client bandwidth.
14. The method of claim 12 , wherein the application level protocol is any one of: SPDY and HTTP.
In the bandwidth estimation method based on transport connection RTT, the application-level protocol can be SPDY or HTTP. This extends the method beyond HTTP to other application-level protocols that operate over a transport connection.
15. The method of claim 12 , further comprising causing the web server to fetch the RTT for the transport connection on which the Request arrived and using a particular RTT value that was calculated as part of a transport connection handshake process associated with the connection.
When a server estimates client bandwidth based on transport connection Round Trip Time (RTT), the method involves fetching the RTT value that was calculated as part of the transport connection handshake process associated with the connection, similar to the TCP three-way handshake. This ensures that the RTT value is accurate and reflects the initial network conditions between the client and server for any transport protocol.
Unknown
December 19, 2017
Browse 5M+ US patents with plain-English claim translations and AI-generated analysis.