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: generating, by a computing device and based on a first update, an updated version of a resource; determining, based on an actual update time of the updated version of the resource: a first approximate update time that is before the actual update time; and a second approximate update time that is after the actual update time; determining a time window based on the first approximate update time and the second approximate update time; receiving, from a client device, a request for the resource; determining, based on whether the request was received within the time window, one of the first approximate update time or the second approximate update time; and sending, to the client device and in response to the request for the resource: the determined one of the first approximate update time or the second approximate update time; and the updated version of the resource.
A computer system updates a resource and needs to tell clients when it changed. When a resource is updated, the system determines the actual update time. It also calculates an "earlier" (rounded down) and "later" (rounded up) approximate update time. A time window is defined between these approximate times. When a client requests the resource, the system checks if the request falls within this window. If it does, it sends the "earlier" approximate update time and the updated resource. If it doesn't, it sends the "later" approximate update time and the updated resource. This helps manage caching based on update time approximations.
2. The method of claim 1 , further comprising: in response to a request from a first device, sending the updated version and an indication that the updated version was last updated at the first approximate update time; and in response to a request from a second device, sending the updated version and an indication that the updated version was last updated at the second approximate update time.
Building upon the previous resource update method, when a first client requests a resource, the server responds with the updated resource and indicates that the resource was last updated at the "earlier" approximate update time. Subsequently, when a second client requests the same updated resource, the server responds with the updated resource but indicates that it was last updated at the "later" approximate update time. The server uses different approximate times for different clients, influencing their caching behavior. This approach ensures that clients receive appropriate cache validation information.
3. The method of claim 1 , wherein the determining one of the first approximate update time or the second approximate update time comprises: determining the first approximate update time in response to determining that the request was received within the time window.
Expanding on the resource update method, the system checks if a client's request for a resource is received within a specific time window. If the request is received within this time window, the system sends the client the "earlier" approximate update time. This "earlier" time is used to signal to the client that it might have a slightly outdated version, prompting it to potentially refresh sooner than if the "later" time was sent. This optimizes caching behavior.
4. The method of claim 1 , further comprising: generating the first approximate update time by rounding down the actual update time; and generating the second approximate update time by rounding up the actual update time.
Continuing with the resource update method, the "earlier" approximate update time is generated by rounding down the actual update time of the resource. Conversely, the "later" approximate update time is generated by rounding up the actual update time. This rounding mechanism creates the time window between the two approximate times. The system uses these rounded times to manage client-side caching, providing a degree of flexibility in cache validation depending on request timing.
5. The method of claim 1 , further comprising: receiving, from the client device, a validation request comprising the first approximate update time; and in response to determining that the validation request was received outside of the time window, determining whether the first approximate update time of the validation request is less than or equal to the actual update time.
The resource update method includes a process where a client sends a validation request containing the "earlier" approximate update time. If this validation request is received *outside* the defined time window, the server determines whether the "earlier" approximate update time in the validation request is less than or equal to the actual update time. This comparison helps the server decide whether to send the client the latest version of the resource.
6. The method of claim 5 , further comprising: in response to determining that the first approximate update time of the validation request is less than or equal to the actual update time, sending, to the client device, the second approximate update time and the updated version of the resource.
Building on the resource validation method, if the system determines that the client's "earlier" approximate update time from a validation request is less than or equal to the resource's actual update time, and the validation request arrived outside the time window, then the server sends the client both the "later" approximate update time and the updated version of the resource. This ensures the client gets the most up-to-date content if its cached version is indeed stale.
7. The method of claim 1 , further comprising: receiving, from the client device, a validation request comprising the second approximate update time; in response to determining that the validation request was received outside of the time window, determining whether the second approximate update time of the validation request is less than or equal to the actual update time; and in response to determining that the second approximate update time is greater than the actual update time, sending, to the client device, a response indicating that the updated version of the resource has not been further updated.
In addition to previous resource update concepts, if the client sends a validation request that includes the "later" approximate update time, and this request arrives outside the predetermined time window, the server determines if the client's "later" approximate update time is greater than the actual update time. If it is, the server sends a response to the client indicating that the client's cached version of the resource is still up-to-date and doesn't need to be refreshed.
8. A method comprising: determining, by a computing device, an actual update time of an updated version of a resource; determining, based on the actual update time of the updated version of the resource: a first approximate update time that is before the actual update time; and a second approximate update time that is after the actual update time; determining a time window based on the first approximate update time and the second approximate update time; receiving, by the computing device and from a client device, a validation request for the resource, wherein the validation request comprises a timestamp associated with a version of the resource at the client device; determining, based on a determination of whether the validation request was received outside of the time window, whether to use the timestamp in generating a response to the validation request; and sending, to the client device, the response to the validation request.
A computer system determines when a resource was updated ("actual update time"). It then calculates an "earlier" and a "later" approximate update time, creating a time window. When a client sends a validation request (checking if its cached version is up-to-date) with a timestamp, the system checks if the request was received *outside* of the time window. Based on this, it decides whether to even use the client's timestamp to generate a response, and sends the response back to the client.
9. The method of claim 8 , wherein the determining whether to use the timestamp in generating a response to the validation request comprises: comparing, based on a determination that the validation request was received outside of the time window, the timestamp with the actual update time.
Expanding on the resource validation process, determining whether to use the timestamp in a client's validation request to generate a response involves comparing the client's timestamp with the actual update time if the validation request was received *outside* of the defined time window. This comparison helps the server decide whether the client's cached version is stale or up-to-date.
10. The method of claim 8 , further comprising: in response to determining that the validation request was received within the time window, sending, to the client device in response to the validation request, the first approximate update time.
Continuing with the resource validation method, if a client's validation request is received *within* the defined time window, the server responds to the validation request by sending the "earlier" approximate update time to the client. This signals to the client that there might be a newer version available, encouraging it to potentially refresh its cache.
11. The method of claim 8 , further comprising: in response to determining that the validation request was received outside of the time window, determining whether the timestamp is less than or equal to the actual update time; and determining, based on a determination of whether the timestamp is less than or equal to the actual update time, whether to send the second approximate update time.
Building on the resource validation mechanism, if a client's validation request is received *outside* the defined time window, the system determines if the client's timestamp is less than or equal to the actual update time. The system uses this determination to decide whether to send the "later" approximate update time back to the client, influencing its caching behavior.
12. The method of claim 11 , further comprising: in response to determining that the timestamp is greater than the actual update time, sending, to the client device, the response comprising an indication that a cached resource at the client device is up-to-date.
Expanding on the previous validation logic, if the server determines that the client's timestamp is greater than the actual update time (meaning the client *thinks* it has a newer version than is actually available), the server sends a response to the client indicating that its cached resource is indeed up-to-date. This prevents unnecessary re-downloads and conserves bandwidth.
13. The method of claim 8 , further comprising: receiving a different updated version of the resource; updating, based on the different updated version and at a different update time outside of the time window, the resource; and determining a different time window based on the different update time.
To maintain cache validity over multiple updates, the system updates a resource, generating a different version and a different "update time" *outside* the initially defined time window. It then determines a *different* time window based on this *different* update time, ensuring that the approximation logic adapts as the resource evolves. This allows for long-term, dynamic cache management.
14. The method of claim 8 , further comprising: receiving, by the computing device and from the client device, a read request for the resource; sending, to the client device and based on whether the read request was received within the time window, one of the first approximate update time or the second approximate update time.
In addition to validation requests, the system also handles standard read requests for a resource. When a client sends a regular read request, the server checks if the request was received within the defined time window. Based on whether the read request falls within the time window, the server sends either the "earlier" or the "later" approximate update time along with the resource.
15. An apparatus comprising: one or more processors; and memory storing computer-executable instructions that, when executed by the one or more processors, cause the apparatus to: generate, based on a first update, an updated version of a resource; determine, based on an actual update time of the updated version of the resource: a first approximate update time that is before the actual update time; and a second approximate update time that is after the actual update time; determine a time window based on the first approximate update time and the second approximate update time; receive, from a client device, a request for the resource; determine, based on whether the request was received within the time window, one of the first approximate update time or the second approximate update time; and send, to the client device and in response to the request for the resource: the determined one of the first approximate update time or the second approximate update time; and the updated version of the resource.
A computer system consists of processors and memory containing instructions. When executed, these instructions generate an updated version of a resource after an update. The system calculates an "earlier" and a "later" approximate update time based on the actual update time, defining a time window. Upon receiving a client's request for the resource, the system checks if the request was received within the time window. The system sends the client either the "earlier" or "later" time, along with the updated resource, depending on whether the request fell within the time window.
16. The apparatus of claim 15 , wherein the instructions, when executed by the one or more processors, further cause the apparatus to: in response to a request from a first device, send the updated version and an indication that the updated version was last updated at the first approximate update time; and in response to a request from a second device, send the updated version and an indication that the updated version was last updated at the second approximate update time.
An apparatus operates as follows: when a first device requests the updated resource, the system sends the updated version and an indication that it was last updated at the "earlier" approximate update time. When a second device makes the same request, the system sends the same updated version but indicates that it was last updated at the "later" approximate update time. The time provided differs per client, influencing cache policies and ensuring efficient resource utilization.
17. The apparatus of claim 15 , wherein the instructions, when executed by the one or more processors, further cause the apparatus to: determine the first approximate update time in response to determining that the request was received within the time window.
The apparatus checks the timing of requests. If the system determines that a request was received within the defined time window, the apparatus uses the first approximate time (the "earlier" rounded down time). This "earlier" time encourages more frequent cache validation for requests received closer to the actual update, balancing freshness and server load.
18. The apparatus of claim 15 , wherein the instructions, when executed by the one or more processors, further cause the apparatus to: receive, from the client device, a validation request comprising the first approximate update time; and in response to determining that the validation request was received within the time window, send, to the client device, the first approximate update time in a Last-Modified field.
The apparatus receives a validation request from the client, and this request includes the first approximate update time. When the system determines that this validation request was received within the time window, the apparatus sends the client the first approximate update time back using the standard HTTP "Last-Modified" field.
19. The apparatus of claim 15 , wherein the instructions, when executed by the one or more processors, further cause the apparatus to: receive, from the client device, a validation request comprising the first approximate update time; and in response to determining that the validation request was received outside of the time window, parse the first approximate update time from an If-Modified-Since field of the validation request; and compare the parsed first approximate update time with the actual update time; and send, to the client device and based on the comparison, the second approximate update time.
The apparatus receives a validation request from a client, where the validation request contains the first approximate update time. If the validation request was received outside of the time window, the system gets the first approximate update time from the "If-Modified-Since" field of the request, then compares this time to the actual update time, and finally sends the client the second approximate update time based on this comparison.
Unknown
October 17, 2017
Browse 5M+ US patents with plain-English claim translations and AI-generated analysis.