Patent Grant
11457078
Generally described, computing devices and communication networks can be utilized to exchange information. In a common application, a computing device can request content from another computing device via the communication network. For example, a user at a personal computing device can utilize a software browser application to request a Web page from a server device via the Internet. In such embodiments, the user computing device can be referred to as a client computing device and the server device can be referred to as a content provider.
With reference to an illustrative example, a user of a client computing device may search for or navigate to a desired content item. The user may utilize an application to submit requests, search queries and other interactions to one or more content providers. The application may be a purpose-built application for requesting and interacting with such content items or the application may be a general purpose browser application. The requested content may be identified by one or more embedded resource identifiers, such as uniform resource locators (“URLs”). In turn, software on the client devices typically processes embedded resource identifiers to generate requests for the resources. Often, the resource identifiers reference a computing device associated with the content provider such that the client device would transmit the request for the resource to the referenced content provider computing device.
Some content providers attempt to facilitate the delivery of requested content through the utilization of a content delivery network (“CDN”) service provider. A CDN service provider typically maintains a number of computing devices, generally referred to as “points of presence” or “POPs” in a communication network that can maintain content from various content providers. In turn, content providers can instruct, or otherwise suggest to, client computing devices to request some, or all, of the content provider's content from the CDN service provider's computing devices. With reference to the previous illustrative example, the content provider can leverage a CDN service provider with the modification or substitution of resource identifiers associated with the embedded resources. Specifically, the resource identifiers can reference a computing device associated with the CDN service provider such that the client computing device would transmit the request for the resource to the referenced CDN service provider computing device. Further, in many cases computing devices associated with content providers or CDN service providers cache content that is frequently requested. Similarly, client computing devices may cache content received from the content providers or CDN service providers. Serving requested content from caches at different locations reduces latency associated with content delivery to different extents.
From the perspective of a user utilizing a client computing device, a user experience can be defined in terms of the performance and latencies associated with obtaining network content over a communication network, such as obtaining a Web page or other network content, processing and rendering content on the client computing device, etc. Similarly, content providers are generally motivated to provide requested content to client computing devices often with consideration of efficiency and/or cost associated with transmission of the requested content. However, user experience may vary when requested content is being delivered to and rendered on client computing devices. The variance may depend on a combination of networking, computing, presenting, or other conditions associated with the content request and delivery process. On top of that, content providers associated with a business (e.g., an electronic commerce website), may also consider factors such as customer retention and/or business generation as they provide requested content to users.
The foregoing aspects and many of the attendant advantages will become more readily appreciated as the same become better understood by reference to the following detailed description, when taken in conjunction with the accompanying drawings. Throughout the drawings, reference numbers may be re-used to indicate correspondence between referenced elements. The drawings are provided to illustrate example embodiments described herein and are not intended to limit the scope of the disclosure.
Generally described, the present disclosure is directed to managing content requests and delivery based on machine learning techniques in order to serve various or a combination of needs of a content provider, such as enhancement in user experience, business development and/or customer retention. Computing devices can be used to model content request, delivery, and rendering processes associated with a large number of users based on machine learning techniques, such as various supervised learning, unsupervised learning, and/or reinforcement learning techniques. These models can represent data relationships and patterns, such as functions, algorithms, systems, and the like. The models may accept data input, and produce output that corresponds to the input in some way. In some implementations, a model is used to generate a likelihood or set of likelihoods that the input corresponds to a particular group or value. For example, a model may be used to determine what content should be pre-cached at a server associated with a CDN service provider based on an estimated likelihood that a group of users will request the content in the near future. As another example, a model may be used to determine what content delivery strategy should be adopted for responding to a content request based on a predicted performance metric associated with the strategy as applied to the content request.
Specifically, some aspects of the disclosure will be described with regard to cache management via request routing and content pre-caching based on machine learning models. In one embodiment, a cache management service associated with a content provider may build a model to route incoming content requests to appropriate content serving computing devices (e.g., content servers of the content provider, POPs of an associated CDN service provider, or client computing devices associated with users) that are likely to have cached the requested content. The model can be built based on unsupervised clustering of past requests. For example, the cache management service may analyze content requests received by the content provider over a specified period of time and cluster the past requests based on a criterion that assesses their commonalities. The criterion may be a formula defining a distance among multiple requests. For example, requests for a same resource and submitted during a small time window on weekends by devices within a geographic region may have a small distance among them based on the formula, and therefore can form a cluster.
Once the clusters of past content requests are determined, the cache management service may associate each cluster with a respective subset of one or more content serving computing devices best situated to cache relevant content and respond to future content requests similar to those in the cluster. The cache management service may also instruct or otherwise cause the subset of content serving devices to pre-cache at least some content that were requested by the cluster of requests in anticipation of similar future requests routed their way. With the association between clusters and content serving computing devices established, the cache management service may start routing incoming content requests. Illustratively, the cache management service receives an incoming content request and determines a cluster that corresponds to the request, for example, based on the same criterion for assessing commonalities among requests. The cache management service then routes the incoming request to the subset of content serving computing devices that are associated with the determined cluster, for example, by way of DNS resolution, URL modification or other request routing techniques known in the art.
As the cache management service routes incoming requests based on the clusters, cache performance metrics (e.g., cache hit or miss rate, routing cost, user perceived latency, combination of the same, or the like) can be collected from the content serving devices or client computing devices. The cache management service may use information regarding the newly received and routed requests as well as the collected performance information to update and optimize the model. For example, the cache management service may re-generate the clusters based on newly received requests after the previous round of clustering. Alternatively, or in addition, the cache management service may modify the criterion for clustering, such as by adjusting weights or parameters of the formula for determining distance among requests. For example, the modifications may be designed to decrease the likelihood of forming clusters that resulted in weak cache or content delivery performance during the previous round, but increase the likelihood of generating clusters that may yield strong performance. The updating of the model can be performed periodically or based on conditions, such as when a performance metric drops below a threshold.
Other aspects of the disclosure will be described with regard to content delivery management via machine learning based content delivery strategy determination. In one embodiment, a content delivery management service associated with a content provider may build a model to determine appropriate content delivery strategies for responding to incoming content requests. The content delivery management service may or may not use the cache management service for request routing. The model can be a supervised learning model (e.g., a decision tree or artificial neural network) trained on historical data related to the processing of content requests and corresponding content delivery performance. For example, the content delivery management service may derived various attributes (e.g., requested resources, timing of requests, associated network condition, computing capability of request submitting device, geographic information, etc.) of each content request received by the content provider over a specified period of time. In some cases, applicable user attributes (e.g., demographics, purchase histories, Web browsing histories, search term histories, session tracking histories, ownership or rental lists, preferences, settings, etc.) associated with users who submitted the content requests can also be derived. The content delivery management service may also derive various content delivery strategy components (e.g., inclusion or exclusion of certain features in responses, lazy-loading or prefetching of resources, in-lining or external call for resources, low quality or high quality data formats, dependency graph associated with responses, above-the-fold configurations, routing of the requests, etc.) from data related to responses to each of the content requests. On the other hand, the content delivery management service can collect or derive content delivery performance metrics (e.g., perceived latency, error rate, cache efficiency, etc.) corresponding to each of the requests. In some cases, the content delivery performance metrics may include user-specific valuations, such as a purchase propensity corresponding to a likelihood that a user makes a related purchase (including its associated timing, type, amount, frequency, etc.) after receiving a response to the user's content request. All of the information regarding historical content requests, content delivery strategy and corresponding performance can be used as training data for the model.
After the model is trained, it is able to take attributes associated with an incoming content request as one part of input, take a candidate content delivery strategy (which may include a combination of strategy components) as another part of input, and generate one or more performance predictions for applying the candidate strategy in response to the content request as output of the model. The content delivery management service may apply the model to the incoming content request in conjunction with a set of candidate strategies and select a strategy that yields a best predicted performance. In some cases, the set of candidate content delivery strategies may include different combinations of strategy components that have a strong correlation with similar content requests in the training data. Once the strategy is selected, the content delivery management service executes the selected strategy, for example, by identifying a pre-generated response to the content request, dynamically generating HTML documents, causing content serving devices to pre-cache certain network resources, routing the request to a corresponding content server, combinations of the same, or the like.
In accordance with the content delivery strategy, the content delivery management service may transmit a response to the content requesting device, such as a client computing device. The response, such as an HTML file, may include information that causes the client computing device to perform further steps in accordance with the content delivery strategy, such as requesting embedded resources from CDN service providers based on an associated order or priority, pre-fetch content in anticipation of future requests, etc.
Still further aspects of the disclosure will be described with regard to the implementation of a portion of the model for content delivery strategy determination on client computing devices. In one embodiment, a global model employed by the content delivery management service may contain separable portions. Some of the separable portions may be executed on individual client computing devices that submit content requests. For example, some upper levels of a decision tree or some portion of input layer of an artificial neural network may be separable because the input to these portions corresponds to data accessible by individual client computing devices. Accordingly, client computing devices may apply the separable model portion on newly generated content requests, by way of a separate application or a script running within a content requesting application. The output of the locally implemented model portions can be included in content requests transmitted from client computing devices to the content provider and fed into the global model where appropriate (e.g., as input to a lower level of decision tree or an intermediate layer of neural network).
Further, the content delivery management service may dynamically determine which portion of the model should be implemented locally on different client computing devices. For example, at the beginning of a browse session a relatively simple and generic portion can be provided to the client computing device. As the content delivery management service processes more content requests from the client computing device during the browse session, the content delivery management may be able to determine the computing capability or data accessibility of the client computing device. Accordingly, the content delivery management service may provide a more complicated or specific portion of the model to the client computing device to execute locally.
In some cases, certain separable portions of the global model can be trained on individual client computing devices. For example, a sub decision tree or a portion of an artificial neural network input layer can be trained or updated on client computing devices based on local user data for user behavior prediction, such as predicting content that users will likely request in the near future. When the model portion is trained, it can be applied by individual client computing devices directly on newly generated content requests. Alternatively or in addition, the model portion can be updated by the content delivery management service as the global model is updated.
Still other aspects of the disclosure will be described with regard to facilitating rendering of responses to content requests via machine learning based above the fold (“ATF”) determination. ATF generally corresponds to a portion of rendered content, such as a Web page or Web application, that is initially visible or otherwise perceivable to a user of a client computing device without scrolling. In one embodiment, the content delivery management service may build a model to determine appropriate ATF configurations for rendering responses to content requests. The model for ATF determination may be the same model as described above. For example, one of the outputs of the same model can correspond to an indication of an ATF configuration. Alternatively, the ATF determination model can be a standalone machine learning model.
Similarly, the model for ATF determination can be a supervised learning model (e.g., a decision tree or artificial neural network) trained on historical data related to content requests, corresponding responses and associated users. In particular, user interaction data (e.g., scrolling, dwelling, or clicking actions on Web pages or applications, browsing history, searching history, purchase history, product review history, user preference or setting history, or user location data) and client computing device data (e.g., screen size, screen resolution, browser window size, browser version, or device orientation) associated with historical content requests and their responses may be particularly relevant to the model training. For example, the data may reveal that a group of users frequently scroll down immediately from an ATF portion of a type of content that they requested. This may be treated as an indication that the current ATF configuration for rendering the type of content is not appropriate for the group of users. Depending on the consistency of the scrolling (e.g., by a similar number of pixels), the model may learn that the ATF should display a specific, lower portion of the content (or a feature or resource rendered therein) to the group of users. Based on the determined ATF configuration, the content delivery management service may further assign priorities for retrieval and rendering of various resources embedded in a response, so that portions of content that likely interest users most can be presented first in the ATF.
After the model for ATF determination is trained, it is able to take attributes associated with an incoming content request as one part of input, and possibly take a candidate content delivery strategy as another part of the input, and generate one or more indications of ATF configurations for rendering the response to the request. For example, the indication may be a prediction of a specific portion or feature of the response that the user intends to view or interact with. The content delivery management service may select an ATF configuration (e.g., based on associated confidence level or a predicted content delivery performance) may apply the ATF configuration in response to the content request (e.g., by modifying the order of calls for embedded resources, incorporating corresponding script code, etc.) The model for ATF determination can similarly be updated and optimized based on feedback data collected from client computing devices and other relevant sources.
Although various aspects of the disclosure will be described with regard to illustrative examples and embodiments, one skilled in the art will appreciate that the disclosed embodiments and examples should not be construed as limiting. For example, use of the term “content provider” is not intended to be limited to any particular type of service provider, whether discussed or described in examples. Accordingly, one skilled in the relevant art will appreciate that a content provider need not provide all, or any, of the additional services or functionality that may be associated with some content providers, such as one associated with an electronic commerce website.
The content delivery environment 100 can also include a content provider 104 in communication with the one or more clients 102 and the CDN service provider 106 via the communication network 110. Illustratively, one or more clients 102 may be associated with the content provider 104. For example, a user may have an account with the content provider 104, or the client 102 may be configured to exchange information with certain components of the content provider 104.
The content provider 104 illustrated in
The content provider 104 illustrated in
The data stored in the request information data store 122 can include any information related to content requests, corresponding responses and performance thereof. The data may be in a form of system logs recording received content requests and corresponding responses in their raw format with time stamps. Alternatively, or in addition, the data may be organized in accordance with various attributes that can be derived from the raw data. For example, requested resources, timing of requests, associated network condition or topology, characteristics of requesting devices (e.g., operating system, browser version, device model, form factor, display size, input devices, processor type, etc.), associated location information (e.g., IP address of requesting devices), etc., can be derived from the raw data to characterize content requests. As another example, inclusion or exclusion of types of features, lazy-loading or prefetching of resources, in-lining or external calls for resources, low quality or high quality data formats, associated dependency graphs, above the fold information, routing of the requests, etc., can be derived from the raw data to characterize content delivery strategies in responding to content requests. As yet another example, DNS resolution latency and performance, total time to load a content page and individual network resources, number of times the content page or individual network resources was retrieved, bandwidth utilization, network latency, number of hops between client and server, processor utilization, memory utilization, cache hit/miss ratio, load time per cache miss, etc., can be derived from the raw data to characterize performance of content request processing and corresponding content delivery strategy. The request information included in data store 122 may be obtained from multiple sources, such as various components of the content provider 104, CDN service provider 106 or clients 102.
The data stored in the user information data store 124 can include any information related to users associated with the content provider 104. For example, the user information may include user characteristic or demographic data, such as age, gender, ethnicity, religion, geographic location, occupation, income, spending levels, content interests, hobbies, preferences, settings, and the like. As another example, the user information may include user interaction data, such as scrolling, dwelling, or clicking actions on Web pages or applications, purchase histories, Web browsing histories, search histories, session tracking histories, ownership or rental lists, user reviews, customer service interactions, and the like. The user information included in the user information data store 124 may be cross referenced with the request information include in the request information data store 122, for example, based on browser cookie or other user identification mechanism.
The content provider 104 illustrated in
Still further, the content provider 104 illustrated in
Although not illustrated in
With continued reference to
One skilled in the relevant art will appreciate that the components and configurations provided in
In the illustrated embodiment, the cache management service 120 includes a processing unit 202, a network interface 204, a non-transitory computer-readable medium drive 206, and an input/output device interface 208, all of which may communicate with one another by way of a communication bus. The network interface 204 may provide the cache management service 120 with connectivity to one or more networks or computing systems. The processing unit 202 may thus receive information and instructions from other computing devices, systems, or services via a network. The processing unit 202 may also communicate to and from memory 210 and further provide output information via the input/output device interface 208. The input/output device interface 208 may also accept input from various input devices, such as a keyboard, mouse, digital pen, touch screen, etc.
The memory 210 may contain computer program instructions that the processing unit 202 may execute in order to implement one or more embodiments of the present disclosure. The memory 210 generally includes RAM, ROM and/or other persistent or non-transitory computer-readable storage media. The memory 210 may store an operating system 214 that provides computer program instructions for use by the processing unit 202 in the general administration and operation of the cache management service 120. The memory 210 may further include other information for implementing aspects of the present disclosure.
In one embodiment, the memory 210 includes an interface module 212. The interface module 212 can be configured to facilitate generating one or more user interfaces through which a component of the content provider 104, CDN service provider 106, a client 102 or other computing devices may send to, or receive from, the cache management service 120 data regarding machine learning models, content requests, content to pre-cache, cache distribution and performance, etc., or otherwise communicate with the cache management service 120. Illustratively, the user interface can be implemented as a graphical user interface (GUI), network-based user interface, computer program, smartphone or tablet program or application, touchscreen, wearable computing device interface, command line interface, gesture, voice, or text interface, etc., or any combination thereof.
In addition, the memory 210 may include a request clustering module 216 that may be executed by the processing unit 202. In an example embodiment, the request clustering module 216 implements aspects of the present disclosure. For example, the request clustering module 216 can be configured to implement various computational, statistical, or machine learning methods, for example, clustering or classification algorisms to group or categorize requests for network resources based on criteria related to optimization of cache performance. The data analyzed by the request clustering module 216 for generating clusters of content requests can be forwarded from the interface module 212 or obtained from a repository or storage system of the content provider 104 that maintains such information, such as the request information data store 122 and user information data store 124. The request clustering module 216 may also be configured to associate content serving computing devices with content caching components or capabilities (e.g., content servers 113, CDN POPs 115, or clients 102) with individual clusters or groups of the historical content requests.
The memory 210 may further include a request routing module 218 that may be executed by the processing unit 202. In an example embodiment, the request routing module 218 implements aspects of the present disclosure. For example, the request routing model 218 can be configured to process client requests for content, such as network resources, and route the request based on clusters or groups of historical requests. Specifically, the client request can be forwarded to the request routing module 218 by the interface module 202. The request routing module 218 can match the client request with one or more clusters or groups of content requests, and route the client request to one or more content serving computing devices associated a matching cluster or group.
It should be noted that the cache management service 120 may be implemented by some or all of the components present in
In the illustrated embodiment, the content delivery management service 130 includes a processing unit 302, a network interface 304, a non-transitory computer-readable medium drive 306, and an input/output device interface 308, all of which may communicate with one another by way of a communication bus. The network interface 304 may provide the content delivery management service 130 with connectivity to one or more networks or computing systems. The processing unit 302 may thus receive information and instructions from other computing devices, systems, or services via a network. The processing unit 302 may also communicate to and from memory 310 and further provide output information via the input/output device interface 308. The input/output device interface 308 may also accept input from various input devices, such as a keyboard, mouse, digital pen, touch screen, etc.
The memory 310 may contain computer program instructions that the processing unit 302 may execute in order to implement one or more embodiments of the present disclosure. The memory 310 generally includes RAM, ROM and/or other persistent or non-transitory computer-readable storage media. The memory 310 may store an operating system 314 that provides computer program instructions for use by the processing unit 302 in the general administration and operation of the content delivery management service 130. The memory 310 may further include other information for implementing aspects of the present disclosure.
In one embodiment, the memory 310 includes an interface module 312. The interface module 312 can be configured to facilitate generating one or more user interfaces through which a component of the content provider 104, CDN service provider 106, a client 102 or other computing devices may send to, or receive from, the content delivery management service 130 data regarding machine learning models, content requests, users, content delivery strategy, ATF configurations, content delivery performance, etc., or otherwise communicate with the content delivery management service 130. Illustratively, the user interface can be implemented as a graphical user interface (GUI), network-based user interface, computer program, smartphone or tablet program or application, touchscreen, wearable computing device interface, command line interface, gesture, voice, or text interface, etc., or any combination thereof.
In addition, the memory 310 may include a model building module 316 that may be executed by the processing unit 302. In an example embodiment, the model building module 316 implements aspects of the present disclosure. For example, the model building module 316 can be configured to employ various supervised machine learning methods, as well as other computational or statistical methods for building one or more models for determining content delivery strategy and ATF configuration for responses to content requests. The data for training or updating the models can be forwarded from the interface module 312 or obtained from a repository or storage system of the content provider 104 that maintains such information, such as the request information data store 122 and user information data store 124.
The memory 310 may further include a model application module 318 that may be executed by the processing unit 302. In an example embodiment, the model application module 318 implements aspects of the present disclosure. For example, the model application module 318 can be configured to process client requests for content, such as network resources, and feed applicable features related to the client requests to the model in conjunction with candidate content delivery strategies. The model application module 318 may then determine a content delivery strategy (and possibly an ATF configuration for a corresponding response) that is predicted be associated with optimized performance in accordance with a criterion or metric. The model application module 318 may also determine, provide and update applicable model portions to be executed on client computing devices.
It should be noted that the content delivery management service 130 may be implemented by some or all of the components present in
With reference now to
At (2), the cache management service 120 obtains user data that is applicable to the historical content requests. As described above, the user data may include any information related to users associated with the content provider 104. For example, the user information may include user characteristic data, such as age, gender, ethnicity, religion, geographic location, occupation, income, spending levels, content interests, hobbies, and the like. As another example, the user information may include user interaction data, such as purchase histories, Web browsing histories, search term histories, session tracking histories, ownership or rental lists, user reviews, customer service interactions, and the like. Where applicable, the cache management service 120 may correlate applicable user data with at least a subset of the historical content requests.
At (3), the cache management service 120 clusters or groups the historical content requests referenced by the obtained data. Various computational, statistical, or machine learning methods (e.g., k-means, mixture models, hierarchical clustering, or other unsupervised clustering or classification algorisms) can be employed to group the content requests so that each group may be associated with dedicated content serving devices. Any combination of attributes derived from the content requests data or applicable user data can be used as features for individual content requests. This way, content requests may be represented as vectors of features and fed into an applicable clustering or classification algorithm.
In some embodiments, the clustering algorithm includes one or more criteria for grouping the content requests. For example, the criterion may correspond to a formula for calculating distances between or among content requests. The formula for calculating distances may include heuristics for improving cache performance of content serving devices associated with the content provider 104, CDN service provider 106, or clients 102. Illustratively, distances between or among content requests in accordance with the formula may be smaller if the content requests include a same requested resource, are submitted by clients within a same geographic region, a same network domain or through a same Internet service provider (ISP), relate to users of similar income level or purchase interests, are transmitted within a small window of date or time, combinations of the same, or the like.
Based on the one or more criteria for request grouping, the cache management service 120 determines multiple clusters or groups of the historical content requests. Depending on the clustering method or criteria, these groups can be mutually exclusive, overlapping, forming a hierarchical relationship, or probabilistic. The cache management service 120 then associates content serving computing devices (e.g., content servers 113, CDN POPs 115, clients 102, etc.) with each of the groups. The association may be a one-to-one, one-to-many, many-to-one, or many-to-many relationship. Characteristics can be derived from each of the groups, which may facilitate associating content serving devices with the groups. For example, if one group of requests mostly originated from mobile devices utilizing a wireless network, the cache management service 120 may associate a CDN POP 115 located close to a mobile endpoint for the wireless network with that group. As another example, the size of a group of content requests may inform a number of content serving devices to be associated with the group (e.g., the larger the size of a group the more content serving devices are associated with the group).
Characteristics of content request groups may also be used by the cache management service 120 to instruct or otherwise cause content serving devices to pre-cache content. For example, if one group of requests generally corresponds to requests submitted during a specific time window (e.g., between 9 am and 12 pm on Mondays), the cache management service 120 may cause content service devices associated with the group to pre-cache at least a portion of content requested by the group of requests prior to the time window. As such, the association between content serving devices and groups of requests can be time based. Illustratively, a same content service device can be associated with one group for a first period of time, and be associated with another group for a second period of time. This can be further facilitated by setting expiration time (e.g., time to life or “TTL”) of content cached by the content service device in accordance with times of “switch-overs” between the associations with different groups of content requests.
At (4), the cache management service 120 obtains new requests for content that originated from clients 102. Illustratively, the client 102 may generate a request for content by loading a browser for viewing network content in response to an event or user action. The browser may be implemented to request network resource via a browse session request to the network content provider 104. Illustratively, this request may be generated automatically as a result of the browser loading (e.g., a request for a default or “home” page), or may be generated as a result of a user following a link or entering a network address into an address bar of the browser. Once the request is received by a component of the content provider 104, the request can be forwarded to the cache management service 120.
At (5), the cache management service 120 determines one or more clusters or groups of historical content requests that are applicable to newly obtained content requests. For example, the cache management service 120 may compute an average distance between a newly obtained content request to all historical requests of a group. The average distance can be computed with respect to each group of historical requests and an ordered list of groups can be generated based on corresponding average distances. Illustratively, the cache management service 120 may select a specified number of groups from the top of the list and assign a respective confidence level (e.g., a value inversely proportional to a corresponding average distance and further weighted by a corresponding group size) for associating the newly obtained content request with each of the top groups.
In some embodiments, the cache management service 120 always assigns the newly obtained content request to a group that has the highest confidence level. In other embodiments, the cache management service 120 probabilistically assigns the newly obtained content request to groups based on their respective confidence levels. For example, the likelihood the new content request is assigned to a specific group can be made proportional to the value of confidence level for the group.
At (6), the cache management service 120 routes the newly obtained requests to various content serving computing devices (e.g., content servers 113, CDN POPs 115, clients 102, etc.) associated with the assigned group. This can be achieved by DNS resolution, URL modification, or other techniques known in the art. Ideally, if the newly obtained content requests follow a similar pattern as the historical content requests, the performance of cache components associated with the various content serving computing devices are optimized in accordance with the clustering of content requests.
In some embodiments, the cache management service 120 may associate additional content serving devices to a cluster or group that matches the newly obtained content request. For example, the cache management service 120 may have detected significantly more content requests that match a particular group than what is considered proportional to the size of the particular group. In this case, the cache management service 120 may assign one or more additional servers to be associated with the particular group and route the newly obtained content request to the additional server.
At (7), the cache management service 120 obtains feedback data of cache performance related to the routing of the newly obtained content requests from the various content serving devices. The feedback data may be transmitted from the content serving devices to the cache management service directly. Alternatively or in addition, the feedback data may be transmitted to other components of the content provider 104 and maintained by the request information data store 122. As described above, the cache performance feedback data may include performance metrics about cache components (e.g., cache hit/miss rate) or performance metrics about content delivery (e.g., latency information) in response to content requests.
At (8), the cache management service 120 obtains updated content request data (e.g., data about more recent content requests) from the request information data store 122. At (9), the cache management service 120 obtains updated user data that is applicable to the updated content request data from the user information data store 124. At (10), the cache management service 120 updates the clustering of content requests based on the feedback data and updated data regarding more recent content requests. In some embodiments, the cache management service may define a metric to measure cache performance. For example, the cache performance metric can be as simple as an average cache hit rate of all content serving devices that respond to content requests directed to the content provider 104. A more complicated example can be a weighted average of cache hit rate and user's perceived latency, which can be further augmented or discounted by a quality value of corresponding content requests (e.g., a high quality value may be assigned to authentic human generated requests and a low quality value may correspond to requests generated by an automatic Web crawler).
Using the defined cache performance metric, the cache management service 120 may assess cache performance of content serving devices that are associated with previously determined groups of content requests. The cache management service 120 may compare groups that correspond to high values in cache performance with groups that correspond to low performance, and then determine which features or measurement of similarities between content requests contribute more to the formation of high performing groups (or low performing groups). The cache management service 120 may then adjust the criteria, such as changing a distance formula to emphasize certain content request features while discounting others, so that high performing clusters or groups are more likely to occur through the clustering process.
The adjusted criteria can be used to cluster the more recent content requests referenced by the updated data. Accordingly, the cache management service 120 determines a set of updated clusters of content requests and re-associates content serving devices with each of the updated clusters, which are likely to achieve better cache performance than the clusters previously determined. The updating of clustering criteria and re-generation of content request clusters can be performed periodically (e.g., every 30 days) or based on a condition (e.g., a cache performance metric value falls below a predetermined threshold).
With reference to
At (3), the content delivery management service 130 builds one or more models for determining content delivery strategies in response to content requests. Various supervised machine learning methods (e.g., decision trees, artificial neural networks, logistic regression, support vector machine, etc.) can be employed to build the model. The content delivery management service may decide to use a subset of the historical data obtained from the request information data store 122 and user information data store 124 as basis for training data for a specific model. The training data needs to be representative of real-world use of a function (e.g., to predict a defined content delivery performance measure or to determine an ATF configuration based on content request attributes and a proposed content delivery strategy) corresponding to the model.
Thus, input features and outputs are determined for each content request referenced by the training data. For example, input features corresponding to each content request can include a vector of any combination of attributes derived from the content requests data or applicable user data related to the content request, and another vector of any combination of content delivery strategy components derived from processing information or responses to the content request. Outputs correspond to the same content request may include any defined metrics for measuring content delivery performance, such as a weighted average of user perceived latency and user's purchase propensity corresponding to the content request, which can be further modified by other values related to a type of content, a type of client computing device, a geographic region, combinations of the same, or the like. The outputs may also include indications of ATF configurations derived from user interaction data related to a response to the content request, such as identification of a portion of rendered content as ATF and a confidence level associated with the ATF configuration. The confidence level can be defined based on a type, quantity or consistency of user interactions with the portion of rendered content.
The content delivery management service 130 then determines the type and structure of the model. For example, the content delivery management service 130 may choose decision trees or artificial neural networks as the model type. The content delivery management service 130 may further determine the order of levels for a decision tree model or the structure of layers for a neural network model. In some embodiments, the structure of the model is designed to facilitate determination of model portions that can be provided to and executed locally on clients 102. For example, the upper levels of a decision tree may correspond to decision nodes based on input features generated by or accessible to clients 102. As another example, portions of input layer of an artificial neural network may be designed to only receive input features generated by or accessible to clients 102.
Next, the content delivery management service 130 trains the model by running learning algorithms corresponding to the model on the training data. In some embodiments, the accuracy of the trained model is evaluated on test data, such as another subset of the historical data obtained from the request information data store 122 and user information data store 124, before the model is deployed. As described above, a trained model may take a content request (as represented by a vector of various features related to the content request) and a candidate content delivery strategy (as represented by a vector of various content delivery strategy components) as input and generate one or more predicted content delivery performance metrics and/or indications of ATF configurations.
At (4), the content delivery management service 130 obtains a new content request that originated from a client 102. Illustratively, the client 102 may generate the request for content by loading a browser for viewing network content in response to an event or user action. The browser may be implemented to request network resource via a browse session request to the network content provider 104. Once the request is received by a component of the network content provider 104, the request can be forwarded to the content delivery management service 130. In some embodiments where a portion of the model is executed locally on the client 102, the newly obtained content request may include outputs from the locally executed model portion. Illustratively, such information can be included in the header or parameters of the content request.
At (5), the content delivery management service 130 applies the trained model to the incoming content request in order to determine a proper content delivery strategy and/or ATF configuration. The content delivery management service may feed the model with at least some known attributes associated with an incoming content request as one part of input, and feed the model with at least some known components corresponding to a candidate content delivery strategy as another part of the input, and retrieve one or more performance predictions and/or indications of ATF configurations. Depending on the model, training data, or training method employed, unknown input features can be assigned a neutral value or simply be left blank.
The content delivery management service 130 may apply the model to the incoming content request in conjunction with a set of candidate strategies, compare the predictions made by the model among candidate strategies, and select a strategy that yields a best predicted performance. In some cases, the set of candidate content delivery strategies may include different combinations of strategy components that are correlated with similar content requests in the training data. For example, content requests submitted by older smartphones via relatively slow networks may typically be correlated with responses including in-lining of resources, low quality data formats, exclusion of certain types of features, combinations of the same, or the like.
At (6), once a content delivery strategy (possibly including an ATF configuration) is determined or selected, the content delivery management service 130 executes the strategy, for example, by identifying a pre-generated response to the content request that corresponds to the strategy, dynamically generating HTML documents in accordance with the strategy, causing content serving devices to pre-cache certain network resources accordingly, routing the request to a corresponding content server, combinations of the same, or the like.
At (7), the content delivery management service 130 may transmit a response to the client 102. The response, such as an HTML file, may include information that causes the client 102 to perform further steps in accordance with the content delivery strategy. In some embodiments, the content delivery management service 130 may also incorporate a determined portion of the trained model in the response (e.g., as script code to be executed within a browser or a separate application to be installed on the client 102).
With reference to
At (9), the content delivery management service 130 obtains feedback data of content delivery performance related to the executed strategy from the client 102 or other sources. The feedback data may be transmitted from the client 102 to the content delivery management service 130 directly. Alternatively or in addition, the feedback data may be transmitted to other components of the content provider 104 and maintained by the request information data store 122 or user information data store 124. As described above, the content delivery performance feedback data may include various performance metrics about content delivery (e.g., network statistics, latencies, bandwidths, data arrival times, such as the timing of receipt of first and last packets of information for the requested resource and each embedded resource, timing information associated with processing executable resources, such as JavaScript, as well as additional information that can be used to indirectly determine processing times associated with the execution of the resources) in response to content requests. The content delivery performance feedback data may also include user interaction data or valuation (e.g., purchase actions, Web browsing actions, search actions, updated purchase propensity values, etc.)
At (10), the content delivery management service 130 obtains updated content request data (e.g., data about more recent content requests, such as the most recent 60 days) from the request information data store 122. At (11), the content delivery management service 130 obtains updated user data that is applicable to the updated content request data from the user information data store 124. At (12), the content delivery management service 130 updates the model based on the feedback data and updated data regarding more recent content requests, for example, by re-training the model with these data. Similarly, the model updating can be performed periodically (e.g., every 30 days) or based on a condition (e.g., when a content delivery performance metric value falls below a predetermined threshold).
With reference to
In some embodiments, the clustering algorithm includes one or more criteria for clustering the content requests. For example, a criterion may correspond to a formula for calculating a measure of similarity between or among content requests. Illustratively, the formula may include heuristics related to cache performance of content serving devices associated with the content provider 104, CDN service provider 106, or clients 102. For example, content requests may be considered similar if the content requests include a same requested resource, are submitted by clients within a same geographic region, a same network domain or through a same Internet service provider (ISP), relate to users of similar income level or purchase interests, are transmitted within a window of date or time, combinations of the same, or the like.
Based on the one or more criteria for request clustering, the cache management service 120 determines multiple clusters of the historical content requests. Depending on the clustering algorithm employed, these clusters can be mutually exclusive, overlapping, forming a hierarchical relationship, or probabilistic. The cache management service 120 then associates content serving computing devices with each of the clusters. The association may correspond to a one-to-one, one-to-many, many-to-one, or many-to-many relationship. Characteristics can be derived from clusters to facilitate their association with content serving devices. For example, if a cluster of requests mostly originated from clients located within a specific geographic region, the cache management service 120 may associate the cluster with a CDN POP 115 located in the same region. As another example, the variety and size of content requested by a cluster may inform the type of content serving devices (e.g., having a larger or smaller cache capacity) to be associated with the cluster.
Characteristics of content request clusters may also be used by the cache management service 120 to instruct or otherwise cause content serving devices to pre-cache content. For example, if a cluster of requests generally corresponds to requests submitted upon occurrence of certain events (e.g., requests of a cluster are typically submitted one day after certain items are added to online shopping carts), the cache management service 120 may cause content service devices associated with the cluster to pre-cache at least a portion of content requested by the cluster when the event is detected again.
At block 604, the cache management service 120 obtains a new incoming content request originated from a client 102. Illustratively, the client 102 may generate the request for content by loading a browser for viewing network content in response to an event or user action. The browser may be implemented to request network resource via a browse session request to the network content provider 104. Once the content request is received by a component of the network content provider 104, the request can be forwarded to the cache management service 120.
At block 606, the cache management service 120 routes the incoming content request in accordance with a corresponding cluster of historical content requests. For example, the cache management service 120 may compute a similarity measure for each cluster with respect to the income content request based, for example, on the same similarity formula used to cluster historical content requests. The cache management service 120 may further compute a respective confidence level for matching individual clusters with the incoming request based on how similar the cluster is to the incoming request. In some embodiments, the cache management service 120 always assigns the incoming content request to a cluster with the highest confidence level. In other embodiments, the cache management service 120 probabilistically assigns the incoming content request to individual clusters based on their respective confidence levels.
The cache management service 120 then routes the incoming request to a content serving computing device (e.g., a content server 113, a CDN POP 115, or the requesting client 102) that are associated with the cluster assigned to the incoming request. This can be achieved by DNS resolution, URL modification, or other request routing techniques known in the art. In some embodiments, the cache management service 120 may associate additional content serving devices to a cluster that matches the incoming content request. For example, the cache management service 120 may determine that the content serving devices currently associated with the matching cluster lacks capacity to handle some content requests routed thereto. In this case, the cache management service 120 may assign additional server(s) to be associated with the cluster and route the incoming content request to the additional server.
At block 608, the cache management service 120 obtains feedback data of cache performance related to the routing of the incoming request. The feedback data may be transmitted from the content serving devices to the cache management service 120 directly. Alternatively or in addition, the feedback data may be transmitted to another component of the content provider 104 and then maintained by the request information data store 122. As described above, the cache performance feedback data may include performance metrics about cache components (e.g., cache hit/miss rate) or performance metrics about content delivery (e.g., latency information) in response to content requests.
At block 610, the cache management service 120 updates the clusters of content requests for optimization of cache performance of content serving devices managed by the service. The cache management service 102 may retrieve updated content request and user data (e.g., data related to more recent content requests) from the request information data store 122 and the user information data store 124. The cache management service 120 may then update the clustering of content requests based on the feedback data of cache performance and updated data regarding more recent content requests. In some embodiments, the cache management service 120 may define a metric to measure cache performance (e.g., a weighted average of cache hit rate and user's perceived latency).
Using the defined cache performance metric, the cache management service 120 may assess cache performance of content serving devices that are associated with previously determined clusters. The cache management service 120 may compare clusters that correspond to high values in cache performance with those that correspond to low values, and then determine which features or measurement of similarities between content requests contribute more to the formation of high (or low) performing clusters. The cache management service 120 may then adjust the criteria, such as changing a similarity formula to discount factors that contribute to formation of low performance clusters while amplifying factors that contribute to formation of high performance clusters, so that high performing clusters are more likely to occur through the clustering process.
The adjusted criteria can be used to cluster the more recent content requests. Accordingly, the cache management service 120 determines a set of updated clusters of content requests and then re-associates content serving devices with each of the updated clusters, which are likely to achieve better cache perform than with the clusters previously determined. The updating of clustering criteria and re-generation of content requests clusters can be performed periodically (e.g., every week) or based on a condition (e.g., a cache performance metric value starts to decline).
At block 612, the cache management service 120 determines whether to continue the request-routing based cache management routine. If the routine is to continue, it proceeds to block 604 where the cache management service 120 obtains additional incoming content requests. Otherwise, the routine ends at block 614.
At block 704, the content delivery management service 130 obtains an incoming content request that originated from a client 102. Illustratively, the client 102 may generate the request for content by loading a browser for viewing network content in response to an event or user action. At block 706, the content delivery management service 130 determines and executes a content delivery strategy in response to the incoming content request based on the trained model. As described above, the content delivery management service 130 may feed the model with at least some known attributes associated with an incoming content request as one part of an input.
The known attributes associated with the incoming content request may be derived from the request itself or from other data related to the incoming content request. For example, the user associated with the incoming content request may have logged in its account with the content provider 104 and therefore any applicable user information, such as demographics, purchase history, review history, etc., can be derived as input features. As another example, previous content requests originated from the same client 102 can be identified based on IP address, session ID or other identification methods, which may be basis for other applicable input features.
The content delivery management service 130 may feed the model with at least some known components of a candidate content delivery strategy as another part of the input. The model will then generate the one or more performance predictions for applying the candidate strategy in response to the incoming content request. The content delivery management service 130 may apply the model to the incoming content request in conjunction with a number of candidate strategies, compare the predictions made by the model with respect to each candidate strategy, and select a strategy that yields a best predicted performance metric that the content provider 104 is set to optimize. For example, the performance metric may correspond to one of the outputs of the model, such as user's perceived latency. As another example, the performance metric may correspond to a formula that combines a number of model outputs, such as a weighted average of certain latency metrics and user valuation metrics.
Once the content delivery strategy is determined, the content delivery management service 130 executes the strategy, for example, by identifying a pre-generated response to the content request that corresponds to the strategy, dynamically generating HTML documents in accordance with the strategy, causing content serving devices to pre-cache certain network resources accordingly, routing the request to a corresponding content server, combinations of the same, or the like.
At block 708, in accordance with the content delivery strategy, the content delivery management service 130 may transmit a response to the content requesting device, such as client 102. The response, such as an HTML file, may include information that causes the client 102 to perform further steps in accordance with the content delivery strategy. At block 710, the content delivery management service 130 obtains feedback data of content delivery performance related to the executed strategy from the client 102 or other sources. The feedback data may be transmitted from the client 102 to the content delivery management service 130 directly. Alternatively or in addition, the feedback data may be transmitted to other components of the content provider 104 and then forwarded to or retrieved by the content delivery management service 130. The content delivery performance feedback data may include any information related to content requests, responses, or users as described herein. For example, the feedback data can include various performance metrics about content delivery, user action or valuation resulted from the executed content delivery strategy.
At block 712, the content delivery management service 130 updates the model. Illustratively, the content delivery management service 130 re-trains the model based on updated content request data (e.g., data about more recent content requests), updated user data, and the feedback data of content delivery performance. At block 714, the content delivery management service 130 determines whether to continue the routine. If so, the routine proceeds to block 704. If not, the routine terminates at block 716.
At block 804, after the global model is trained, the content delivery management service 130 may provide a determined portion of the model (e.g., certain upper levels of a decision tree or portion of a neural network's input layer) to a client 102. Different portions of the global model can be provided to different clients 102, and in some cases, a large portion provided to a client with adequate computing capability or data accessibility may include a number of smaller portions provided to other clients. The model portion can be embodied in a separate application or script code to be executed locally on the client 102. In some embodiments, the model portion is trained and/or updated locally on the client 102. In other embodiments, the model portion may receive input features accessible to the client 102 exclusively, such as a quantity or type of other contents the client 102 is requesting, rendering or presenting, available computational or networking resources, user interactions with other applications, etc. If the client 102 is currently executing a portion of the global model, the content delivery management service 130 may provide update information regarding the portion based on the newly trained global model.
At block 806, the content delivery management service 130 obtains a new content request that originated from a client 102. The newly obtained content request includes outputs from the model portion executed locally on the client 102. For example, such information can be included in the header or parameters of the content request. At block 808, the content delivery management service 130 determines and executes content delivery strategy in response to the content request based on another portion of the global model. For example, the content request may indicate a location of the locally executed model portion within the global model. Alternatively or in addition, the content delivery management service 130 may determine that outputs from the model portion executed on the client 102 corresponds to inputs to another specific portion of the global model utilized by the content delivery management service 130.
In some embodiments, the outputs from the model portion executed on the client 102 include at least some content delivery strategy components and therefore dictate or limit the type of candidate content delivery strategies that can be evaluated by the global model. The content delivery management service may feed the outputs where appropriate into the overall model and possibly feed the global model with other applicable input features, and retrieve one or more performance predictions from the model. As described above, the content delivery management service 130 may determine a strategy based on the predictions and execute the strategy, which may include determining whether the model portion executing on the client 102 should be updated, replaced, or otherwise modified.
At block 810, in accordance with the content delivery strategy, the content delivery management service 130 may transmit a response to the client 102. The response may include another determined portion of the global model or updating information for the model portion currently executing on the client 102 in the response. At block 812, the content delivery management service 130 obtains feedback data of content delivery performance related to the executed strategy from the client 102 or other sources. The content delivery performance feedback data may include any information related to content requests, responses, or users as described herein. For example, the feedback data can include various performance metrics about content delivery, user action or valuation. At block 814, the global model is updated, for example, by re-training the model with the updated data related to more recent content requests and the feedback data. At block 816, the content delivery management service 816 determines whether or not to continue the routine. If the routine is to continue, the routine proceeds to block 804. Otherwise, the routine ends at block 818.
Thus, input features and outputs are determined for each content request within the training data. For example, input features corresponding to each content request can include a vector of any combination of attributes derived from the content requests data or applicable user data related to the content request, as well as another vector of content delivery strategy components derived from processing information or responses to the content request. Outputs may include indications of ATF configurations derived from user interaction data related to responses to the content request.
For example, user interactions (e.g., clicking or dragging items, inputting information, etc.) with certain types of features within a Web page may be considered an indication the type of features should be included in the ATF. As another example, user scrolling away from a current ATF immediately after its rendering may indicate that the current ATF configuration is inappropriate. As a further example, user scrolling away from a portion of rendered content and dwelling on another portion for an extended period of time may be considered an indication that the later portion should be displayed as ATF. Still further, the indications of ATF configuration can be associated with respective confidence levels, which can be defined based on a type, quantity or consistency of user interactions. Next, the content delivery management service 130 trains the model by running learning algorithms corresponding to the model on the training data. As described above, the trained model may take a content request (as represented by a vector of various features related to the content request) and a candidate content delivery strategy (as represented by a vector of various content delivery strategy components) as input and generate one or more indications of ATF configurations for rendering a corresponding response to the content request.
At block 904, the content delivery management service 130 obtains a new content request that originated from a client 102. Illustratively, the client 102 may generate the request for content by loading a browser for viewing network content in response to an event or user action. At block 906, the content delivery management service 130 applies the trained model to the incoming content request in order to determine a proper ATF configuration for content rendering in its response. As described above, the content delivery management service may feed the model with at least some known attributes associated with an incoming content request as one part of input, and feed the model with indications of at least some components of a content delivery strategy as another part of the input, and retrieve one or more indications of ATF configurations for applying the strategy in response to the incoming content request. The content delivery management service 130 may select an ATF configuration based on its associated confidence level as compared to other ATF configurations. In accordance with the chosen ATF configuration, the content delivery management service 130 may determine priorities associated with various features or resources embedded in the response to the content request.
At block 908, the content delivery management service 130 causes the response to the content request to be rendered on the client 102 in accordance with the determined ATF configuration. For example, the content delivery management service may incorporate additional information (e.g., script codes, dependency graphs, etc.) in the response transmitted to the client 102, so that the client 102 retrieves embedded resources from the content provider 104 or CDN service provider 106 based on their associated priorities and renders or displays content in accordance with the ATF configuration.
At block 910, the content delivery management service 130 obtains feedback data related to the response as rendered in accordance with the ATF configuration from the client 102 or other sources. The feedback data may include any information related to content requests, responses, or users as described herein. For example, the feedback data can include any user interaction data, such as changes of user preferences or settings. The feedback data may also include corresponding user valuation data, such as updated purchase propensity values.
At block 912, the content delivery management service 130 updates the model based on the feedback data as well as updated data related to more recent content requests. As describe above, the model updating can be achieved by re-training the model with the updated data. Similarly, the model updating can be performed periodically (e.g., every 30 days) or based on a condition derived from the feedback data. At block 914, the content delivery management service 130 determines whether to continue the routine. If so, the routine proceeds to block 904. Otherwise, the routine terminates at block 916.
Depending on the embodiment, certain acts, events, or functions of any of the methods described herein can be performed in a different sequence, can be added, merged, or left out altogether (e.g., not all described acts or events are necessary for the practice of the algorithm). Moreover, in certain embodiments, acts or events can be performed concurrently, e.g., through multi-threaded processing, interrupt processing, or multiple processors or processor cores or on other parallel architectures, rather than sequentially.
The various illustrative logical blocks, modules and method elements described in connection with the embodiments disclosed herein can be implemented as electronic hardware, computer software or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. The described functionality can be implemented in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the disclosure.
The various illustrative logical blocks and modules described in connection with the embodiments disclosed herein can be implemented or performed by a machine, such as a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor can be a microprocessor, but in the alternative, the processor can be a controller, microcontroller, or state machine, combinations of the same, or the like. A processor can also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.
The elements of a method, process, or algorithm described in connection with the embodiments disclosed herein can be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module can reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM or any other form of computer-readable storage medium known in the art. A storage medium can be coupled to the processor such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium can be integral to the processor. The processor and the storage medium can reside in an ASIC. The ASIC can reside in a user terminal. In the alternative, the processor and the storage medium can reside as discrete components in a user terminal.
Embodiments of the disclosure can be described in view of the following clauses:
Conditional language used herein, such as, among others, “can,” “might,” “may,” “e.g.” and the like, unless specifically stated otherwise, or otherwise understood within the context as used, is generally intended to convey that certain embodiments include, while other embodiments do not include, certain features, elements and/or states. Thus, such conditional language is not generally intended to imply that features, elements and/or states are in any way required for one or more embodiments or that one or more embodiments necessarily include logic for deciding, with or without author input or prompting, whether these features, elements and/or states are included or are to be performed in any particular embodiment. The terms “comprising,” “including,” “having,” “involving” and the like are synonymous and are used inclusively, in an open-ended fashion, and do not exclude additional elements, features, acts, operations and so forth. Also, the term “or” is used in its inclusive sense (and not in its exclusive sense) so that when used, for example, to connect a list of elements, the term “or” means one, some or all of the elements in the list.
Disjunctive language such as the phrase “at least one of X, Y or Z,” unless specifically stated otherwise, is otherwise understood with the context as used in general to present that an item, term, etc., may be either X, Y or Z, or any combination thereof (e.g., X, Y and/or Z). Thus, such disjunctive language is not generally intended to, and should not, imply that certain embodiments require at least one of X, at least one of Y or at least one of Z to each be present.
Unless otherwise explicitly stated, articles such as “a” or “an” should generally be interpreted to include one or more described items. Accordingly, phrases such as “a device configured to” are intended to include one or more recited devices. Such one or more recited devices can also be collectively configured to carry out the stated recitations. For example, “a processor configured to carry out recitations A, B and C” can include a first processor configured to carry out recitation A working in conjunction with a second processor configured to carry out recitations B and C.
While the above detailed description has shown, described, and pointed out novel features as applied to various embodiments, it will be understood that various omissions, substitutions, and changes in the form and details of the devices or algorithms illustrated can be made without departing from the spirit of the disclosure. As will be recognized, certain embodiments described herein can be embodied within a form that does not provide all of the features and benefits set forth herein, as some features can be used or practiced separately from others. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.
This application is a continuation of U.S. patent application Ser. No. 14/578,189, entitled “MACHINE LEARNING BASED CONTENT DELIVERY,” filed Dec. 19, 2014, which is hereby incorporated by reference herein in its entirety.
| Number | Name | Date | Kind |
|---|---|---|---|
| 5649185 | Antognini et al. | Jul 1997 | A |
| 5664106 | Caccavale | Sep 1997 | A |
| 5819033 | Caccavale | Oct 1998 | A |
| 5832517 | Knutsen, II | Nov 1998 | A |
| 5999636 | Juang | Dec 1999 | A |
| 6173322 | Hu | Jan 2001 | B1 |
| 6182125 | Borella et al. | Jan 2001 | B1 |
| 6185598 | Farber et al. | Feb 2001 | B1 |
| 6243761 | Mogul et al. | Jun 2001 | B1 |
| 6377257 | Borrel et al. | Apr 2002 | B1 |
| 6438592 | Killian | Aug 2002 | B1 |
| 6473804 | Kaiser et al. | Oct 2002 | B1 |
| 6529910 | Fleskes | Mar 2003 | B1 |
| 6553419 | Ram | Apr 2003 | B1 |
| 6633324 | Stephens, Jr. | Oct 2003 | B2 |
| 6662233 | Skarpness et al. | Dec 2003 | B1 |
| 6697805 | Choquier et al. | Feb 2004 | B1 |
| 6698013 | Bertero et al. | Feb 2004 | B1 |
| 6714975 | Aggarwal et al. | Mar 2004 | B1 |
| 6820133 | Grove et al. | Nov 2004 | B1 |
| 6920498 | Gourlay et al. | Jul 2005 | B1 |
| 6978418 | Bain et al. | Dec 2005 | B1 |
| 7009943 | O'Neil | Mar 2006 | B2 |
| 7065496 | Subbloie et al. | Jun 2006 | B2 |
| 7085825 | Pishevar et al. | Aug 2006 | B1 |
| 7096193 | Beaudoin et al. | Aug 2006 | B1 |
| 7107273 | Ohata et al. | Sep 2006 | B2 |
| 7114160 | Suryanarayana et al. | Sep 2006 | B2 |
| 7120871 | Harrington | Oct 2006 | B1 |
| 7185084 | Sirivara et al. | Feb 2007 | B2 |
| 7269657 | Alexander et al. | Sep 2007 | B1 |
| 7343399 | Hayball et al. | Mar 2008 | B2 |
| 7346676 | Swildens et al. | Mar 2008 | B1 |
| 7373599 | McElfresh et al. | May 2008 | B2 |
| 7523181 | Swildens et al. | Apr 2009 | B2 |
| 7555542 | Ayers et al. | Jun 2009 | B1 |
| 7581224 | Romero | Aug 2009 | B2 |
| 7596150 | Baird et al. | Sep 2009 | B2 |
| 7623460 | Miyazaki | Nov 2009 | B2 |
| 7650376 | Blumenau | Jan 2010 | B1 |
| 7653725 | Yahiro et al. | Jan 2010 | B2 |
| 7676570 | Levy et al. | Mar 2010 | B2 |
| 7685270 | Vermeulen et al. | Mar 2010 | B1 |
| 7685273 | Anastas et al. | Mar 2010 | B1 |
| 7698418 | Shimada et al. | Apr 2010 | B2 |
| 7707071 | Rigole | Apr 2010 | B2 |
| 7707173 | Nanavati et al. | Apr 2010 | B2 |
| 7725658 | Lang et al. | May 2010 | B2 |
| 7748005 | Romero et al. | Jun 2010 | B2 |
| 7752301 | Maiocco et al. | Jul 2010 | B1 |
| 7756032 | Feick et al. | Jul 2010 | B2 |
| 7765295 | Anastas et al. | Jul 2010 | B2 |
| 7860735 | Evanitsky | Dec 2010 | B2 |
| 7865594 | Baumback et al. | Jan 2011 | B1 |
| 7873065 | Mukerji et al. | Jan 2011 | B1 |
| 7904875 | Hegyi | Mar 2011 | B2 |
| 7925782 | Sivasubramanian et al. | Apr 2011 | B2 |
| 7930393 | Baumback et al. | Apr 2011 | B1 |
| 7933988 | Nasuto et al. | Apr 2011 | B2 |
| 7937456 | McGrath | May 2011 | B2 |
| 7961736 | Ayyagari | Jun 2011 | B2 |
| 8051166 | Baumback et al. | Nov 2011 | B1 |
| 8069231 | Schran et al. | Nov 2011 | B2 |
| 8117306 | Baumback et al. | Feb 2012 | B1 |
| 8122124 | Baumback et al. | Feb 2012 | B1 |
| 8165915 | Lucash | Apr 2012 | B1 |
| 8286176 | Baumback et al. | Oct 2012 | B1 |
| 8296429 | Baumback et al. | Oct 2012 | B2 |
| 8316124 | Baumback et al. | Nov 2012 | B1 |
| 8452870 | Baumback et al. | May 2013 | B2 |
| 8463877 | Richardson | Jun 2013 | B1 |
| 8468245 | Farber et al. | Jun 2013 | B2 |
| 8489737 | Baumback et al. | Jul 2013 | B2 |
| 8577963 | Trahan | Nov 2013 | B2 |
| 8667127 | Bettis et al. | Mar 2014 | B2 |
| 8762526 | Baumback et al. | Jun 2014 | B2 |
| 8843625 | Baumback et al. | Sep 2014 | B2 |
| 9071502 | Baumback et al. | Jun 2015 | B2 |
| 9088460 | Baumback et al. | Jul 2015 | B2 |
| 9118543 | Baumback et al. | Aug 2015 | B2 |
| 9160641 | Baumback et al. | Oct 2015 | B2 |
| 9210099 | Baumback et al. | Dec 2015 | B2 |
| 9367929 | Bettis et al. | Jun 2016 | B2 |
| 9491073 | Baumback et al. | Nov 2016 | B2 |
| 9628403 | Baumback et al. | Apr 2017 | B2 |
| 9660890 | Baumback et al. | May 2017 | B2 |
| 9769248 | Krishnan et al. | Sep 2017 | B1 |
| 9794188 | Baumback et al. | Oct 2017 | B2 |
| 9825831 | Baumback et al. | Nov 2017 | B2 |
| 9996501 | Nelson et al. | Jun 2018 | B1 |
| 10027739 | Krishnan et al. | Jul 2018 | B1 |
| 10104009 | Baumback et al. | Oct 2018 | B2 |
| 10148542 | Baumback et al. | Dec 2018 | B2 |
| 10205644 | Baumback et al. | Feb 2019 | B2 |
| 10225365 | Hotchkies et al. | Mar 2019 | B1 |
| 10284446 | Baumback et al. | May 2019 | B2 |
| 10311371 | Hotchkies et al. | Jun 2019 | B1 |
| 10311372 | Hotchkies et al. | Jun 2019 | B1 |
| 10410085 | Bettis et al. | Sep 2019 | B2 |
| 10462025 | Baumback et al. | Oct 2019 | B2 |
| 20010034771 | Hutsch et al. | Oct 2001 | A1 |
| 20020016802 | Hodgkinson | Feb 2002 | A1 |
| 20020062372 | Hong et al. | May 2002 | A1 |
| 20020073235 | Chen et al. | Jun 2002 | A1 |
| 20020099829 | Richards et al. | Jul 2002 | A1 |
| 20020107913 | Rivera et al. | Aug 2002 | A1 |
| 20020112049 | Elnozahy et al. | Aug 2002 | A1 |
| 20020116491 | Boyd et al. | Aug 2002 | A1 |
| 20020120666 | Landsman et al. | Aug 2002 | A1 |
| 20020135611 | Deosaran et al. | Sep 2002 | A1 |
| 20020138443 | Schran et al. | Sep 2002 | A1 |
| 20020150276 | Chang | Oct 2002 | A1 |
| 20020156884 | Bertram et al. | Oct 2002 | A1 |
| 20020161911 | Pinckney, III et al. | Oct 2002 | A1 |
| 20020165912 | Wenocur et al. | Nov 2002 | A1 |
| 20020194382 | Kausik et al. | Dec 2002 | A1 |
| 20020198963 | Wu et al. | Dec 2002 | A1 |
| 20030005111 | Allan | Jan 2003 | A1 |
| 20030009488 | Hart, III | Jan 2003 | A1 |
| 20030037108 | Peiffer et al. | Feb 2003 | A1 |
| 20030065784 | Herrod | Apr 2003 | A1 |
| 20030118249 | Edgar | Jun 2003 | A1 |
| 20030128233 | Kasriel | Jul 2003 | A1 |
| 20030130982 | Kasriel | Jul 2003 | A1 |
| 20030131106 | Kasriel | Jul 2003 | A1 |
| 20030182305 | Balva et al. | Sep 2003 | A1 |
| 20030182413 | Allen et al. | Sep 2003 | A1 |
| 20030217144 | Fu et al. | Nov 2003 | A1 |
| 20030221000 | Cherkasova et al. | Nov 2003 | A1 |
| 20030236836 | Borthwick | Dec 2003 | A1 |
| 20040039794 | Biby et al. | Feb 2004 | A1 |
| 20040039820 | Colby et al. | Feb 2004 | A1 |
| 20040049541 | Swahn | Mar 2004 | A1 |
| 20040049579 | Ims et al. | Mar 2004 | A1 |
| 20040059796 | McLintock | Mar 2004 | A1 |
| 20040064293 | Hamilton et al. | Apr 2004 | A1 |
| 20040064558 | Miyake | Apr 2004 | A1 |
| 20040128538 | Gmuender et al. | Jul 2004 | A1 |
| 20040194085 | Beaubien et al. | Sep 2004 | A1 |
| 20040199603 | Tafla et al. | Oct 2004 | A1 |
| 20040201669 | Guha et al. | Oct 2004 | A1 |
| 20040221034 | Kausik et al. | Nov 2004 | A1 |
| 20050021862 | Schroeder et al. | Jan 2005 | A1 |
| 20050055420 | Wyler | Mar 2005 | A1 |
| 20050076111 | Cherkasova et al. | Apr 2005 | A1 |
| 20050076339 | Merril et al. | Apr 2005 | A1 |
| 20050086645 | Diao et al. | Apr 2005 | A1 |
| 20050091612 | Stabb et al. | Apr 2005 | A1 |
| 20050102683 | Branson et al. | May 2005 | A1 |
| 20050182826 | Knittel et al. | Aug 2005 | A1 |
| 20050198571 | Kramer et al. | Sep 2005 | A1 |
| 20050223091 | Zahavi et al. | Oct 2005 | A1 |
| 20050223092 | Sapiro et al. | Oct 2005 | A1 |
| 20050229119 | Torvinen | Oct 2005 | A1 |
| 20050273507 | Yan et al. | Dec 2005 | A1 |
| 20060015865 | Schneider et al. | Jan 2006 | A1 |
| 20060020714 | Girouard et al. | Jan 2006 | A1 |
| 20060026275 | Gilmour et al. | Feb 2006 | A1 |
| 20060048071 | Jarrett et al. | Mar 2006 | A1 |
| 20060059246 | Grove | Mar 2006 | A1 |
| 20060069808 | Mitchell et al. | Mar 2006 | A1 |
| 20060085536 | Meyer et al. | Apr 2006 | A1 |
| 20060179080 | Meek et al. | Aug 2006 | A1 |
| 20060209701 | Zhang et al. | Sep 2006 | A1 |
| 20060218304 | Mukherjee et al. | Sep 2006 | A1 |
| 20060233342 | Thione et al. | Oct 2006 | A1 |
| 20060235961 | Klein et al. | Oct 2006 | A1 |
| 20060251339 | Gokturk et al. | Nov 2006 | A1 |
| 20060265497 | Ohata et al. | Nov 2006 | A1 |
| 20060282758 | Simons et al. | Dec 2006 | A1 |
| 20070016736 | Takeda et al. | Jan 2007 | A1 |
| 20070021998 | Laithwaite et al. | Jan 2007 | A1 |
| 20070050703 | Lebel | Mar 2007 | A1 |
| 20070088805 | Cyster | Apr 2007 | A1 |
| 20070094325 | Ih et al. | Apr 2007 | A1 |
| 20070118640 | Subramanian et al. | May 2007 | A1 |
| 20070136469 | Nusbickel | Jun 2007 | A1 |
| 20070143672 | Lipton et al. | Jun 2007 | A1 |
| 20070198982 | Bolan et al. | Aug 2007 | A1 |
| 20070214454 | Edwards et al. | Sep 2007 | A1 |
| 20070219795 | Park et al. | Sep 2007 | A1 |
| 20070226058 | Lorenzen et al. | Sep 2007 | A1 |
| 20070239610 | Lemelson | Oct 2007 | A1 |
| 20070245010 | Arn et al. | Oct 2007 | A1 |
| 20070245299 | Sung et al. | Oct 2007 | A1 |
| 20070250560 | Wein et al. | Oct 2007 | A1 |
| 20070250611 | Bhogal et al. | Oct 2007 | A1 |
| 20070266113 | Koopmans | Nov 2007 | A1 |
| 20070266151 | Friedland et al. | Nov 2007 | A1 |
| 20070271375 | Hwang | Nov 2007 | A1 |
| 20070299869 | Clary et al. | Dec 2007 | A1 |
| 20070299965 | Nieh et al. | Dec 2007 | A1 |
| 20070300152 | Baugher | Dec 2007 | A1 |
| 20080037432 | Cohen et al. | Feb 2008 | A1 |
| 20080050021 | Plant | Feb 2008 | A1 |
| 20080065724 | Seed et al. | Mar 2008 | A1 |
| 20080065745 | Leighton et al. | Mar 2008 | A1 |
| 20080086559 | Davis et al. | Apr 2008 | A1 |
| 20080098310 | Choi | Apr 2008 | A1 |
| 20080104502 | Olston | May 2008 | A1 |
| 20080114875 | Anastas et al. | May 2008 | A1 |
| 20080172488 | Jawahar et al. | Jul 2008 | A1 |
| 20080183672 | Canon et al. | Jul 2008 | A1 |
| 20080183721 | Bhogal et al. | Jul 2008 | A1 |
| 20080208961 | Kim et al. | Aug 2008 | A1 |
| 20080215583 | Gunawardena et al. | Sep 2008 | A1 |
| 20080215755 | Farber et al. | Sep 2008 | A1 |
| 20080228574 | Stewart et al. | Sep 2008 | A1 |
| 20080250327 | Li et al. | Oct 2008 | A1 |
| 20080289029 | Kim et al. | Nov 2008 | A1 |
| 20090037517 | Frei | Feb 2009 | A1 |
| 20090055542 | Zhao et al. | Feb 2009 | A1 |
| 20090063690 | Verthein et al. | Mar 2009 | A1 |
| 20090083228 | Shatz et al. | Mar 2009 | A1 |
| 20090083279 | Hasek | Mar 2009 | A1 |
| 20090089448 | Sze et al. | Apr 2009 | A1 |
| 20090119388 | Kikuchi et al. | May 2009 | A1 |
| 20090122714 | Kato | May 2009 | A1 |
| 20090187575 | DaCosta | Jul 2009 | A1 |
| 20090248786 | Richardson et al. | Oct 2009 | A1 |
| 20090248852 | Fuhrmann et al. | Oct 2009 | A1 |
| 20090248893 | Richardson et al. | Oct 2009 | A1 |
| 20090319636 | Tokumi | Dec 2009 | A1 |
| 20090327460 | Yoo et al. | Dec 2009 | A1 |
| 20090327517 | Sivasubramanian et al. | Dec 2009 | A1 |
| 20090327914 | Adar et al. | Dec 2009 | A1 |
| 20100005403 | Rozmaryn et al. | Jan 2010 | A1 |
| 20100034470 | Valencia-Campo et al. | Feb 2010 | A1 |
| 20100161792 | Palm et al. | Jun 2010 | A1 |
| 20100195908 | Bechtel et al. | Aug 2010 | A1 |
| 20100211459 | Seeman et al. | Aug 2010 | A1 |
| 20100318508 | Brawer et al. | Dec 2010 | A1 |
| 20100325615 | Ramot | Dec 2010 | A1 |
| 20100332650 | Aisen et al. | Dec 2010 | A1 |
| 20110055627 | Zawacki et al. | Mar 2011 | A1 |
| 20110096987 | Morales et al. | Apr 2011 | A1 |
| 20110145715 | Malloy et al. | Jun 2011 | A1 |
| 20110264511 | Zhang | Oct 2011 | A1 |
| 20120042277 | Lin-Hendel | Feb 2012 | A1 |
| 20120164621 | Katz et al. | Jun 2012 | A1 |
| 20130007273 | Baumback et al. | Jan 2013 | A1 |
| 20130031040 | Modha | Jan 2013 | A1 |
| 20130091294 | El-beltagy et al. | Apr 2013 | A1 |
| 20130191450 | Bodenhamer et al. | Jul 2013 | A1 |
| 20130198298 | Li et al. | Aug 2013 | A1 |
| 20140113600 | El Gamal et al. | Apr 2014 | A1 |
| 20140129707 | Baumback et al. | May 2014 | A1 |
| 20140135105 | Quan et al. | May 2014 | A1 |
| 20140143320 | Sivasubramanian et al. | May 2014 | A1 |
| 20140149533 | Bergman | May 2014 | A1 |
| 20140219279 | Gross et al. | Aug 2014 | A1 |
| 20140250051 | Lahav et al. | Sep 2014 | A1 |
| 20140257891 | Richardson et al. | Sep 2014 | A1 |
| 20140304406 | Baumback et al. | Oct 2014 | A1 |
| 20140317726 | Turgeman et al. | Oct 2014 | A1 |
| 20140372511 | Kapadia et al. | Dec 2014 | A1 |
| 20150012649 | Baumback et al. | Jan 2015 | A1 |
| 20150032801 | Hart | Jan 2015 | A1 |
| 20150088968 | Wei et al. | Mar 2015 | A1 |
| 20150156280 | Vaswani et al. | Jun 2015 | A1 |
| 20150189033 | Han | Jul 2015 | A1 |
| 20150220990 | Kobyakov et al. | Aug 2015 | A1 |
| 20150242379 | Kuivinen et al. | Aug 2015 | A1 |
| 20150263927 | Baumback et al. | Sep 2015 | A1 |
| 20150288593 | Campbell | Oct 2015 | A1 |
| 20150326491 | Baumback et al. | Nov 2015 | A1 |
| 20150333997 | Mermoud et al. | Nov 2015 | A1 |
| 20150358250 | Baumback et al. | Dec 2015 | A1 |
| 20160020972 | Baumback et al. | Jan 2016 | A1 |
| 20160188181 | Smith | Jun 2016 | A1 |
| 20160267354 | Bettis et al. | Sep 2016 | A1 |
| 20170054621 | Baumback et al. | Feb 2017 | A1 |
| 20170070446 | Baumback et al. | Mar 2017 | A1 |
| 20170187591 | Baumback et al. | Jun 2017 | A1 |
| 20180007121 | Krishnan et al. | Jan 2018 | A1 |
| 20180054371 | Baumback et al. | Feb 2018 | A1 |
| Entry |
|---|
| Al-Fares, M. et al., A Scalable, Commodity Data Center Network Architecture, SIGCOMM '08 Proceedings, Aug. 17, 2008, pp. 63-74, 66-68, 70-71, Seattle, WA. |
| McCulloch et al. “A Logical Calculus of the Ideas Immanent in Nervous Activity”, Bulletin of Mathematical Biophysics, vol. 5, 1943, 19 pages. |
| Arcelli et al., “A New Technique for Image Magnification”, p. 53-61, 2009. |
| Bennami, M., et al., Resource Allocation for Autonomic Data Centers Using Analytic Performance Models, 2005, IEEE, 12 pages. |
| Chang, F., et al., Automatic Configuration and Run-time Adaptation of Distributed Applications, 2000, IEEE, 10 pages. |
| Extended Search Report in European Application No. 16001480.9 dated Dec. 5, 2016. |
| Feldmeier, Improving Gateway Performance With a Routing-Table Cache, Massachusetts Institute of Technology, Laboratory for Computer Science, IEEE, Mar. 27, 1988, pp. 298-307. |
| Halpern, et al., Internet Draft, “Advertising Equal Cost Multipath routes in BGP; draft-bhatia-ecmp-routes-in-bgp-02.txt”, The Internet Society 2006, 16 pages. |
| Kalogiros et al., “Understanding Incentives For Prefix Aggregation in BGP”, Re-Architecting The Internet, ACM, Dec. 1, 2009, pp. 49-54. |
| Kounev, S., et al., Autonomic QoS-Aware Resource Management in Grid Computing Using Online Performance Models, 2007, ICST, Valuetools, 2007, 10 pages. |
| Ludwig, “Traffic engineering with BGP”, Seminar “Internet Routing”, Technical University Berlin, Jul. 2, 2009, pp. 1-10. |
| Schlansker et al., “Killer Fabrics for Scalable Datacenters”, HP Technical Report, HPL-2009-26, 26 Feb. 26, 2009, 16 pages. |
| Number | Date | Country | |
|---|---|---|---|
| 20190109926 A1 | Apr 2019 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 14578189 | Dec 2014 | US |
| Child | 16201883 | US |
