Patent Grant
11943272
Content delivery networks (CDNs) provide content, such as video content, to users. The CDNs typically employ a hierarchy of computer servers, with an origin server that originally supplies the content, and a hierarchy of proxying servers, caching servers or both organized hierarchically below the origin server to help distribute the content and reduce the load on the origin server.
When a user requests content, such as a particular video, the user's client device (e.g., computer, cell phone, internet-enabled television set) may transmit a request for a fragment of the user-requested content, such as a two-second video fragment, to a proxy server using Hypertext Transfer Protocol (HTTP). The proxy server can provide the fragment if it is available, and if it is not, the proxy server can transmit a request to another proxy server that is higher up in the content's hierarchy, and the process can repeat further up the hierarchy until a server having the requested fragment is reached (or until the source is reached). When the proxy server receives the fragment from the higher level server, the proxy server waits until it possesses the entire content fragment before transmitting data to the client device. This process repeats until all fragments of the user-requested content have been received by the client device.
Content requests are often associated with a timeout, a specified period of time that is allowed to elapse before the request is to be retransmitted or abandoned if none of the requested content has been received. When the user requests high bit rate content, such as a high-definition television content, the request may timeout if the proxy server cannot cache and then deliver the requested content in time. In response to the request timeout, the client device may abandon the request or transmit a redundant request for the content, often at a lower bit rate, which can result in network overload and other bandwidth inefficiencies. In either case, the user's viewing experience is negatively impacted by lower quality content, or no content at all, being delivered to the user's device. In the context of CDNs, where multiple servers are used to deliver content, these inefficiencies are escalated because servers at each level of the CDN hierarchy may be respectively transmitting multiple requests for the same content as a result of timeout.
Accordingly, there remains an ever-present need to improve the delivery of content, and to balance that need with the strains on the network.
Some features described herein relate generally to allowing a client device to request content from a computing device, such as a proxy server, and receive data from the computing device before timeout of the request has occurred. Some disclosed aspects relate to streamlined caching (also referred to as progressive caching), where data transmission by a proxy server to a client device begins before it has been completely received by the proxy server from another server. As a result, timeout of a content request may be avoided, allowing a client or user device to receive and provide high data rate content, such as HD or 3D video or video fragments, to the requesting user.
In an embodiment, a server may receive an HTTP request for content, such as a data unit, from a client device, such as a gateway device coupled to a user's video display (e.g., computer monitor, television set, smart phone, etc.). The data unit may be, for example, content such as a video or a fragment of a video requested by a user, (e.g., a two-second video fragment). The server may determine that it does not possess the requested content and transmit a request for the content to a remote server, such as an upstream cache server in the server's CDN. The server may begin receiving the requested content from the remote server and buffer a portion of the received content. The portion of the content may be, for example, the first several bytes of a multi-megabyte data transmission. In another example, the portion of the content may be based on a maximum transmission unit or a smallest bufferable data unit. The server may then transmit the portion of the content to the requesting user device, in advance of completely receiving and storing the requested content from the remote server.
In some embodiments, the server may receive data from, and transmit data to, one or more intermediate devices. For example, the server may receive a content request from a modem coupled to or embedded within the client device. In another example, the server may transmit a content request to a service router, which may appropriately route communications to and from the remote server.
In some embodiments, the server may identify the remote server based on a server selection technique, a path selection technique, or both. For example, the server may search a cache server index to identify a remote server that possesses the requested content. The search may be based on address information extracted from a content request, such as a uniform resource identifier (URI) or URI prefix for the requested content.
In some embodiments, the server may identify a communications path for communications with the remote server. For example, the server may perform path selection based on a longest match lookup routine, where the remote server that possesses the longest match of the address information for the requested content is selected.
This summary is not intended to identify critical or essential features of the disclosures herein, but instead merely summarizes certain features and variations thereof. Other details and features will also be described in the sections that follow.
Some features herein are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements.
There may be one link 101 originating from the local office 103, and it may be split a number of times to distribute the signal to various homes 102 in the vicinity (which may be many miles) of the local office 103. Although the term home is used by way of example, locations 102 may be any type of user premises, such as businesses, institutions, etc. The links 101 may include components not illustrated, such as splitters, filters, amplifiers, etc. to help convey the signal clearly, but in general each split introduces a bit of signal degradation. Portions of the links 101 may also be implemented with fiber-optic cable, while other portions may be implemented with coaxial cable, other lines, or wireless communication paths.
The local office 103 may include interface 104, such as a cable modem termination system (CMTS), which may be a computing device configured to manage communications between devices on the network of links 101 and backend devices such as servers 105-107 (to be discussed further below). The CMTS may be as specified in a standard, such as, in an example of an HFC-type network, the Data Over Cable Service Interface Specification (DOCSIS) standard, published by Cable Television Laboratories, Inc. (a.k.a. CableLabs), or it may be a similar or modified device instead. The CMTS may be configured to place data on one or more downstream channels or frequencies to be received by devices, such as modems at the various homes 102, and to receive upstream communications from those modems on one or more upstream frequencies. The local office 103 may also include one or more network interfaces 108, which can permit the local office 103 to communicate with various other external networks 109. These networks 109 may include, for example, networks of Internet Protocol devices, telephone networks, cellular telephone networks, fiber optic networks, local wireless networks (e.g., WiMAX), satellite networks, and any other desired network, and the interface 108 may include the corresponding circuitry needed to communicate on the network 109, and to other devices on the network such as a cellular telephone network and its corresponding cell phones, or other network devices. For example, the network 109 may communicate with one or more content sources, such as multicast or unicast video sources, which can supply video streams for ultimate consumption by the various client devices in the homes 102.
As noted above, the local office 103 may include a variety of servers 105-107 that may be configured to perform various functions. For example, the local office 103 may include a push notification server 105 that can generate push notifications to deliver data and/or commands to the various homes 102 in the network (or more specifically, to the devices in the homes 102 that are configured to detect such notifications). The local office 103 may also include a content server 106 configured to provide content to users in the homes. This content may be, for example, video on demand movies, television programs, songs, text listings, etc. The content server may include software to validate user identities and entitlements, locate and retrieve requested content, encrypt the content, and initiate delivery (e.g., streaming) of the content to the requesting user and/or device.
The local office 103 may also include one or more application servers 107. An application server 107 may be a computing device configured to offer any desired service, and may run various languages and operating systems (e.g., servlets and JSP pages running on Tomcat/MySQL, OSX, BSD, Ubuntu, Redhat, HTML5, JavaScript, AJAX and COMET). For example, an application server 107 may be used to implement a cache server for the content found on the content server 106. Other example application servers may be responsible for collecting data such as television program listings information and generating a data download for electronic program guide listings. Another application server may be responsible for monitoring user viewing habits and collecting that information for use in selecting advertisements. Another application server may be responsible for formatting and inserting advertisements in a video stream being transmitted to the homes 102. And as will be discussed in greater detail below, another application server may be responsible for receiving user remote control commands, and processing them to provide an intelligent remote control experience.
An example home 102a may include an interface 120. The interface 120 may comprise a device 110, such as a modem, which may include transmitters and receivers used to communicate on the links 101 and with the local office 103. The device 110 may be, for example, a coaxial cable modem (for coaxial cable links 101), a fiber interface node (for fiber optic links 101), or any other desired device having similar functionality. The device 110 may be connected to, or be a part of, a gateway interface device 111. The gateway interface device 111 may be a computing device that communicates with the device 110 to allow one or more other devices in the home to communicate with the local office 103 and other devices beyond the local office. The gateway 111 may be a set-top box (STB), digital video recorder (DVR), computer server, or any other desired computing device. The gateway 111 may also include local network interfaces (not shown) to provide communication signals to devices in the home, such as televisions 112, additional STBs 113, personal computers 114, laptop computers 115, wireless devices 116 (wireless laptops and netbooks, tablet computers, mobile phones, mobile televisions, personal digital assistants (PDA), etc.), and any other desired devices. Examples of the local network interfaces include Multimedia Over Coax Alliance (MoCA) interfaces, Ethernet interfaces, universal serial bus (USB) interfaces, wireless interfaces (e.g., IEEE 802.11), Bluetooth interfaces, and others. Any of the devices in the home, such as the gateway 111, STB 113, computer 114, etc., can include an application software client that can make use of the video images captured by the image capture servers.
Various features described herein offer improved remote control functionality to users accessing content from the local office 103 or another content storage facility or location. For example, one such user may be a viewer who is watching a television program being transmitted from the local office 103. In some embodiments, the user may be able to control his/her viewing experience (e.g., changing channels, adjusting volume, viewing a program guide, etc.) using any networked device, such as a cellular telephone, personal computer, personal data assistant (PDA), netbook computer, etc., aside from (or in addition to) the traditional infrared remote control that may have been supplied together with a television or STB.
The origin server 300 may also establish the caching hierarchy that will be used to distribute content. For example, the server 300 may transmit messages to one or more cache servers, requesting that the cache servers assist in caching the origin server's content, and instructing the cache server as to where that cache server should be in the hierarchy for the origin's content domain(s), what domain(s) of content it should (or should not) cache, access restrictions, authentication requirements for granting access, etc.
To facilitate distribution of the content, one or more top level cache servers 301a-b can be communicatively coupled to the origin server 300, and each can store a copy of the file(s) containing the content of the origin server 300 (e.g., a copy of the movie files for an on-demand movie). These top level servers can be co-located at the same premises as the origin server 300 and implemented as application servers 107, or they can be located at locations remote from the origin server 300, such as at a different local office connected to the network 109. The top level cache servers 301a-b may also receive and respond to client requests for the content. Further down in the hierarchy may be one or more intermediate level cache servers 302a-c and edge cache servers 303a-d, and these may be implemented using the same hardware as the cache servers 301a-b, and can be configured to also receive and respond to client requests for content. Additional layers of caches in the hierarchy may also be used as desired, and the hierarchical arrangement allows for the orderly distribution of the content, updates to the content, and access authorizations. For example, lower level servers may rely on higher lever servers to supply source files for the content and to establish access authorization parameters for the content. In some embodiments, the top and intermediate level servers may refrain from interaction with clients, and may instead limit their content delivery communications to communicating with other servers in the distribution network. Limiting client access to just the lowest level, or edge, servers can help to maintain security and assist with scaling.
The CDN may also include one or more service routers 304, which may be communicatively coupled to all of the cache servers, but which need not be a part of the caching hierarchy. The service router 304 may facilitate communications between the members of the hierarchy, allowing them to coordinate. For example, the servers in the hierarchy may periodically transmit announcement messages to other cache servers, announcing their respective availabilities (e.g., announcing the content that they are able to provide, or the address domains or routes that they support). In some embodiments, the caches may simply transmit a single announcement to a service router 304, and the service router 304 may handle the further distribution of the announcement messages to other servers in the hierarchy. In this manner, the service router 304 may act as a route reflector in a border gateway protocol, reducing the amount of traffic passing directly between the caches.
For some aspects of the disclosure, the physical arrangement of the servers need not resemble
As illustrated in
The client device may transmit content request 401 at time 402 to a server, for example, in response to a user requesting content using an input device (e.g., input device 208 shown in
Content request 401 may be transmitted by the client device using any suitable transmission device or network, such as network I/O interface 209 shown in
In some embodiments, content request 401 may include an address identifier of the client device making the request. The address identifier may contain routing information to indicate how the client device can be contacted. For example, the address identifier may be a dotted-decimal internet protocol (IP) address for the client device or an intermediate device that handles the client device's communications.
In some embodiments, content request 401 may include a uniform resource identifier (URI). For example, content request 401 may include the URI:
In some embodiments, content request 401 may include a URI prefix, such as “videocontent/tv/NCIS/videos” or “videocontent/movies/Avatar/full-movie”, to identify a domain or subdomains of the requested content. Although the example URI prefixes use text and the forward slash “/” to indicate sub-domain relationships, other forms of notation may be used. For example, the domain name can be represented in an order that increases in specificity from left to right, such as “net. videocontent.tv.ncis” or “net. videocontent.movies.avatar,” or vice versa. In some embodiments, a fully qualified domain name (FQDN) can be used as a URI prefix. For example, the URI prefix may be the FQDN “videocontent.net.” or any other suitable FQDN or domain name associated with content request 401.
In some embodiments, the URI prefix can be provided in a shortened form to reduce code bloat. For example, a URI prefix for the movie Avatar could simply be “videocontentavatar.”
In some embodiments, content request 401 may include a time duration, a data range, or both corresponding to a fragment of the requested content (e.g., a two-second fragment of requested video content). For example, content request 401 may include a URI appended with the time duration “#t=2,4” corresponding to a two-second video fragment for seconds 2-4 of the requested content. In another example, content request 401 may include the data range “bytes=6000001-12000000” corresponding to the two-second video fragment for seconds 2-4 of a video with an associated data rate of approximately 3 MB/s.
In some embodiments, content request 401 may include or be associated with a timeout, such as timeout 413. Timeout 413 may correspond to a time duration after which the requesting client will respond as if an error has occurred with the original request, and may occur at a specified time after request 401 has been transmitted by the client device. In certain embodiments, a timeout period may correspond to the amount of time between request time 402 and timeout 413. For example, timeout 413 may occur two seconds after request time 402 in association with a two-second timeout period. If the requested content is not received by the client device before the timeout period ends, content request 401 may timeout and transmission of an additional request may begin (e.g., possibly for the requested content at a lower quality or bit rate). If the additional request also times out, the client device's request for content may become abandoned.
The server may receive content request 403 at time 404 from the client device using any suitable receiver device, such as network I/O interface 209 shown in
In some embodiments, the server may check to determine whether it possesses or stores the requested content in its cache memory (e.g., ROM 202, RAM 203, removable media 204, or hard drive 205 shown in
The server may transmit content request 405 at time 406 to a remote server, such as a higher-level cache server or origin server, in response determining that the requested content is not stored in its memory. For example, content request 405 may be an HTTP GET request for the requested video asset or a fragment of the video asset. Content request 405 may be transmitted by the server using any suitable transmission device, such as network I/O interface 209 shown in
In some embodiments, request 405 may include an address identifier of the server making the request. This identifier can contain routing information to indicate how the server can be contacted. This address can be, for example, a dotted-decimal internet protocol (IP) address for the server, or for a router, modem, or network interface that handles the server's communications.
In some embodiments, the server may identify the remote server to which content request 405 will be transmitted using any suitable server selection technique, path selection technique, or both. For example, the server may consult an index of cache servers (e.g., an index or database maintained by service router 304 shown in
In some embodiments, various other factors may be used in the identification and selection of the remote server to which request 405 is to be directed. One factor may be the processing capability of the remote server. For example, a remote server with a faster processing capability may be preferred over a remote server with a slower processing capability. Another factor may be the length of a physical connection between the server and the remote server. The length may include the number of intermediate routers and network legs, and the path selection process may prefer a shorter path. For example, a remote server located in the same domain or CDN may be preferred over a remote server located in a different domain or CDN. Another factor may be the cost (e.g., financial cost, computing cost, time cost) associated with accessing the respective caches. For example, the path selection process conducted by the cache server on the index may select the least costly route. In some embodiments, other business rules, processes, or techniques may be used for server selection, path selection, or both.
The server may receive content 407 at time 408 from the remote server or from an intermediate device using any suitable receiver device. In some embodiments, the server may initially receive portion 420 of content 407. Portion 420 may be, for example, a portion of the data unit requested by the client device. Portion 420 may be of an arbitrarily small size. For example, portion 420 may be the first 64 bits of a 6 MB video fragment. In some embodiments, the server may store or buffer portion 420 in a temporary storage device (e.g., RAM 203 shown in
In some embodiments, the server may identify the portion or portions of the data unit that it has received. For example, the server may store information identifying the portions of the data unit that have been received. In certain implementations, the server may associate a flag with an index of the data unit. The server may analyze the flag data to determine whether one or more of the portions of the data unit have been received. The server may also, for example, use the flag data to determine whether any portions of a requested data unit are stored in the server's memory. If the server determines that one or more of the portions are stored locally, it may transmit the locally-stored portions to the requesting client device and request additional portions of the data unit from any suitable remote server or content delivery network.
The server may begin transmitting portion 421 of content 409 at time 410 to the requesting client device (e.g., by opening a network protocol session with the client device) upon receiving and buffering portion 420 of content 407. For example, the difference between time 408 and time 410 may be arbitrarily small and limited only by system capabilities. Portion 421 may be substantially the same as, or a modified version of, portion 420. In some embodiments, portion 421 may correspond to data read from a buffered version of portion 420 stored in the server's memory. For example, the size of portion 421 may correspond to the smallest bufferable data unit. In another example, the size of portion 421 may correspond to a maximum transmission unit (MTU).
In some embodiments, the transmission of portion 421 begins in advance of completely receiving content 407 because waiting to completely receive content 407 at time 414 may result in transmission of content 407 beginning after timeout 413 has occurred. In some embodiments, the server may begin a looping process to receive, buffer, and transmit subsequent portions of content 407 until all portions of content 407 have been received. For example, the looping process may proceed until an end of transmission character (EOT) in content 407 has been received and decoded (if needed) by the server.
The client device may receive portion 422 of content 411 at time 412 from the server using any suitable receiver device, such as network I/O interface 209 shown in
In some embodiments, the client device may present the received content for display on a display device (e.g., television 112, personal computer 114, laptop computer 115, wireless device 116 shown in
In step 501, the server receives an HTTP request for a data unit from a client device, such as content request 401 shown in
In step 502, the server determines whether its memory contains a copy of the requested data unit based on address information or other identifying information extracted from the received request. If the server determines that its memory includes a copy of the requested data unit, the process proceeds to step 503. If the server determines that its memory does not include a copy of the requested data unit, the process proceeds to step 504.
In step 503, the server returns a copy of the requested data unit to the requesting client device in response to determining that the data unit was found in the server's memory. For example, the server may return the entire data unit requested by the client device.
In step 504, the server transmits a request for the data unit to a remote server, such as request 403 shown in
In step 505, the server begins to receive a portion of the data unit from the remote server, such as portion 420 of content 407 shown in
In step 507, the server determines whether it has received the entire data unit (e.g., by decoding an EOT in content 407 shown in
With the features described above, various advantages may be achieved. An advantage of the present technique is that timeout of the request is avoided in some instances as a result of transmission by the server of an initial portion of the content beginning before the entire requested content has been received at the server (e.g., before timeout has occurred). As a result, a user can request and receive high quality (e.g., high bit rate) videos using an HTTP protocol without, in some instances, the user's client device experiencing timeout. Another advantage of the present technique is that delay in the delivery of content in a CDN is reduced because data is transmitted to the next layer in the CDN hierarchy as soon as or shortly after it is received. Accordingly, the network is not overloaded with redundant content requests and the user's viewing experience is enhanced.
The various features described above are merely nonlimiting examples, and can be rearranged, combined, subdivided, omitted, and/or altered in any desired manner. For example, features of the servers can be subdivided among multiple processors and computing devices. The true scope of this patent should only be defined by the claims that follow.
This application is a continuation of U.S. application Ser. No. 16/233,788, filed Dec. 27, 2018, which is a continuation of U.S. application Ser. No. 13/344,674 filed Jan. 6, 2012, now U.S. Pat. No. 10,218,756, titled Streamlined Delivery of Video Content. The contents of these applications, in their entireties, are incorporated by reference herein.
| Number | Name | Date | Kind |
|---|---|---|---|
| 5913024 | Green et al. | Jun 1999 | A |
| 6714985 | Malagrino et al. | Mar 2004 | B1 |
| 6785704 | McCanne | Aug 2004 | B1 |
| 6894976 | Banga et al. | May 2005 | B1 |
| 7024485 | Dunning et al. | Apr 2006 | B2 |
| 7505484 | Pancholi et al. | Mar 2009 | B2 |
| 7734730 | McCanne | Jun 2010 | B2 |
| 7840680 | Zuckerman et al. | Nov 2010 | B2 |
| 7844712 | Zuckerman et al. | Nov 2010 | B2 |
| 7849163 | Issa | Dec 2010 | B1 |
| 7995590 | Cutaia | Aug 2011 | B2 |
| 8019899 | Zhang et al. | Sep 2011 | B2 |
| 8139924 | Walters et al. | Mar 2012 | B2 |
| 8140672 | Crowder et al. | Mar 2012 | B2 |
| 8244887 | Abu-Samaha et al. | Aug 2012 | B2 |
| 8307031 | Grieve | Nov 2012 | B1 |
| 8341688 | Ngo et al. | Dec 2012 | B2 |
| 8392748 | Bocharov et al. | Mar 2013 | B2 |
| 20010036185 | Dempo | Nov 2001 | A1 |
| 20020062369 | von Klopp et al. | May 2002 | A1 |
| 20030005144 | Engel et al. | Jan 2003 | A1 |
| 20040006636 | Oesterreicher et al. | Jan 2004 | A1 |
| 20040044761 | Phillipi et al. | Mar 2004 | A1 |
| 20040068579 | Marmigere et al. | Apr 2004 | A1 |
| 20050025185 | Brown et al. | Feb 2005 | A1 |
| 20050030972 | Madukkarumukumana et al. | Feb 2005 | A1 |
| 20050091395 | Harris et al. | Apr 2005 | A1 |
| 20050187968 | Dunning et al. | Aug 2005 | A1 |
| 20060045131 | Pancholi et al. | Mar 2006 | A1 |
| 20060159102 | Major | Jul 2006 | A1 |
| 20060221844 | Subramanian et al. | Oct 2006 | A1 |
| 20070005787 | Igarashi et al. | Jan 2007 | A1 |
| 20070053363 | Chen et al. | Mar 2007 | A1 |
| 20070079342 | Ellis et al. | Apr 2007 | A1 |
| 20070286233 | Latif et al. | Dec 2007 | A1 |
| 20080040498 | Setlur et al. | Feb 2008 | A1 |
| 20080098101 | Black et al. | Apr 2008 | A1 |
| 20080162922 | Swartz | Jul 2008 | A1 |
| 20080240123 | Cutaia | Oct 2008 | A1 |
| 20090067325 | Baratakke et al. | Mar 2009 | A1 |
| 20090067429 | Nagai et al. | Mar 2009 | A1 |
| 20090110003 | Julien et al. | Apr 2009 | A1 |
| 20090116490 | Charpentier et al. | May 2009 | A1 |
| 20090225757 | Imao | Sep 2009 | A1 |
| 20090316698 | Menten | Dec 2009 | A1 |
| 20100002697 | Krishnan et al. | Jan 2010 | A1 |
| 20100057939 | Zhang | Mar 2010 | A1 |
| 20100067540 | Park | Mar 2010 | A1 |
| 20100094959 | Zuckerman et al. | Apr 2010 | A1 |
| 20100094963 | Zuckerman et al. | Apr 2010 | A1 |
| 20100121940 | Reeser | May 2010 | A1 |
| 20100131671 | Kohli et al. | May 2010 | A1 |
| 20100183009 | Baratakke et al. | Jul 2010 | A1 |
| 20100281042 | Windes et al. | Nov 2010 | A1 |
| 20110022471 | Brueck et al. | Jan 2011 | A1 |
| 20110032428 | Bing | Feb 2011 | A1 |
| 20110087733 | Shribman et al. | Apr 2011 | A1 |
| 20110096828 | Chen et al. | Apr 2011 | A1 |
| 20110126248 | Fisher et al. | May 2011 | A1 |
| 20110137934 | Pizzomi et al. | Jun 2011 | A1 |
| 20110161598 | Kelapure et al. | Jun 2011 | A1 |
| 20110185041 | Hunt | Jul 2011 | A1 |
| 20110238789 | Luby et al. | Sep 2011 | A1 |
| 20110239078 | Luby et al. | Sep 2011 | A1 |
| 20110243138 | Oh et al. | Oct 2011 | A1 |
| 20110264727 | Keum et al. | Oct 2011 | A1 |
| 20110270944 | Keilhau et al. | Nov 2011 | A1 |
| 20110271007 | Wang et al. | Nov 2011 | A1 |
| 20110276699 | Pedersen | Nov 2011 | A1 |
| 20110302320 | Dunstan | Dec 2011 | A1 |
| 20120042050 | Chen et al. | Feb 2012 | A1 |
| 20120054361 | Luzzatti et al. | Mar 2012 | A1 |
| 20120063449 | Frederic et al. | Mar 2012 | A1 |
| 20120072957 | Cherukuwada et al. | Mar 2012 | A1 |
| 20120106327 | Lin et al. | May 2012 | A1 |
| 20120131223 | Watson et al. | May 2012 | A1 |
| 20120144000 | Nogami et al. | Jun 2012 | A1 |
| 20120144443 | Bae et al. | Jun 2012 | A1 |
| 20120155460 | Gu et al. | Jun 2012 | A1 |
| 20120198020 | Parker et al. | Aug 2012 | A1 |
| 20120281559 | Ner et al. | Nov 2012 | A1 |
| 20120320752 | Gouache et al. | Dec 2012 | A1 |
| 20130007040 | John et al. | Jan 2013 | A1 |
| 20130077940 | Shackleton et al. | Mar 2013 | A1 |
| 20130089142 | Begen et al. | Apr 2013 | A1 |
| 20130091251 | Walker et al. | Apr 2013 | A1 |
| 20130091303 | Mitra et al. | Apr 2013 | A1 |
| 20130097309 | Ma et al. | Apr 2013 | A1 |
| 20130124679 | Harrang et al. | May 2013 | A1 |
| 20130124749 | Thang et al. | May 2013 | A1 |
| 20130132507 | Swaminathan et al. | May 2013 | A1 |
| 20130138775 | Shah | May 2013 | A1 |
| 20130166625 | Swaminathan et al. | Jun 2013 | A1 |
| 20130279464 | Gu et al. | Oct 2013 | A1 |
| 20130290493 | Oyman et al. | Oct 2013 | A1 |
| 20140337473 | Frusina et al. | Nov 2014 | A1 |
| 20140372627 | Axelrod et al. | Dec 2014 | A1 |
| 20150032899 | Willars et al. | Jan 2015 | A1 |
| Number | Date | Country |
|---|---|---|
| 2011139305 | Nov 2011 | WO |
| Entry |
|---|
| Sen, S.; Rexford, J.; Towsley, D., “Proxy prefix caching for multimedia streams,” Mar. 21-25, 1999, Eighteenth Annual Joint Conference of the IEEE Computer and Communications Societies. Proceedings IEEE, vol. 3, pp. 1310-1319. |
| Nov. 1983—“The TCP Maximum Segment Size and Related Topics”—Network Working Group—J. Postel. |
| Jul. 2012—“TCP Options and Maximum Segment Size (MSS)”—Internet Engineering Task Force (IETF)—D. Borman. |
| Number | Date | Country | |
|---|---|---|---|
| 20220272140 A1 | Aug 2022 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 16233788 | Dec 2018 | US |
| Child | 17741000 | US | |
| Parent | 13344674 | Jan 2012 | US |
| Child | 16233788 | US |
