Patent Description:
When a user requests the data for content selection, the data needs to be retrieved, formatted / shaped based on client-specific details (e.g., including for the type of client device and software version requesting the data), and returned to the client requester. This can cause numerous problems when the number of requests spikes at a given time. For example, when the latest episode of a very popular program, such as Home Box Office, Inc. 's "Game of Thrones" is first made available for streaming, the number of simultaneous or near-simultaneous requests for the selection-related data needed to select the episode offering can overwhelm conventional data retrieval techniques. <CIT> is directed towards detecting and propagating changes that affect information maintained in a cache. Data may be pre-cached in advance of its actual need, however such data can change, including in various different source locations. A change monitoring/signaling service detects relevant changes and publishes change events to downstream listeners, including to a cache population service that updates pre-cache data as needed in view of such data changes. Per-user-specific data also may be pre-cached, such as when a user logs into a data service. <CIT> is directed towards batching two or more data requests into a batch request that is sent to a data-providing entity such as a client data access layer coupled to a data service. Described is maintaining a mapping of the requests to requesting entities so that the responses to a batched request, which may be separately streamed, may be assembled into a batch response to the requesting entity. Also described is multiplexing a plurality of requests for the same data item into a single request, which may be added to a batch request, and de-multiplexing the single response into separate responses to each requesting entity. <CIT> is directed towards sending metadata related to a video to a client device, such as events that describe a portion of that video, such as in a hidden stream. The enhanced metadata comprises nodes used to build part of a relationship graph. This allows interested clients to switch between the feature playback and interacting with the metadata. <CIT> is directed towards having multiple paths through streamed media content, such as a video. The content may be represented as a state machine of states, in which each state corresponds to one or more periods of one or more segments, and transitions to one or more other states. When a state is able to transition to different states, one or more criteria may be used to select one of the transition paths to a next state. Segments corresponding to unknown paths (where the transition decision is not yet available) may be selected and streamed for buffering via a multiple path buffering mechanism. <CIT> discloses a system for linking transmedia content subsets. A memory stores a plurality of transmedia content data items and associated linking data which define time ordered content links between the plurality of transmedia content data items. A transmedia content model that represents the transmedia content data items as nodes and the content links between the transmedia content data items as edges in one or more time-varying graphs. A processor is configured to associate the transmedia content data items with the time-ordered content links and store the linking data in the memory. It assigns the trans media content data items to nodes of a graph structure, assign the time-ordered content links to edges of the graph structure and store them in the transmedia content model.

It is therefore the object of the present invention to provide an improved method for generating a content selection graph, a corresponding system, and a machine-readable medium comprising executable instructions that cause a processor to perform the corresponding method.

The technology described herein is illustrated by way of example and not limited in the accompanying figures in which like reference numerals indicate similar elements and in which:.

Various aspects described herein are generally directed towards a technology in which entire graphs that maintain the data of content selection offerings are generated, validated and stored in an in-memory data store, such as a Redis (Remote Dictionary Server) cache. Instead of having to wait for an initial request (which corresponds to one or more graph nodes), then obtain the graph data from one or more underlying data stores and build an appropriate response, the graphs including the response data for the nodes are built in advance in anticipation of a request for a graph node. Moreover, the graphs can be prearranged with preformatted and pre-shaped responses that map to the requesting client-specific information / details, e.g., a device's type, software type (e.g., a device's browser or a more dedicated device application) and version, and other factors (e.g., brand, channel such as HBO® or Cinemax®, language, territory), so that the response is returnable from the content selection data store generally as is, without having to format / shape the data. For example, there can be multiple graphs in use, one graph for device type A, software version <NUM>, another for device type C, software version <NUM> and so on. The request is mapped to the correct graph based on these client-specific details (data response formatting factors), e.g., for the device type, software version, etc., whereby the response data corresponding to the requested graph node can be rapidly retrieved and returned generally as is.

Still further, because any content offering's availability can be limited in time, (that is, an offering can expire), and new content offerings can be made available from time-to-time, the stored set of graphs are associated with a starting time. When the current time reaches the starting time of a new set of graphs, those graphs, which are prepopulated into the in-memory content selection data store, become active. As a result, the correct current content selection data becomes directly available at the appropriate time for requests received at or after that time, until a next set of graphs becomes active at a next starting time.

It should be understood that any of the examples herein are non-limiting. For instance, instead of different graphs for different types of device, software versions, locales, etc.), as an alternative, a lesser number of graphs can be used, with some (ideally fast) amount of reformatting / reshaping of the response data before returning to the client. While not as efficient when responding to requests, less rapid (e.g., Redis cache) storage needs to be used. As another alternative, a device itself can be configured with some reformatting intelligence, e.g., , e.g., a tablet or smartphone with a relatively small screen can adjust more generalized data (such as menus and tiles) differently than a large ("ten-foot viewing distance") television display, and vice-versa. Still further, data stores (e.g., key-value stores) other than a Redis cache can be used for storing the graph content, although the use of a Redis cache provides a number of features, benefits and advantages that can be readily recognized as described herein.

<FIG> is a generalized block diagram representation of an example system <NUM> in which requests <NUM> from clients <NUM> are serviced from an in-memory content selection graph data store <NUM>, e.g., a Redis cache, multiple caches, database(s) and/or the like. In general, the requests <NUM> are received (e.g., via a load balancer or the like) at request handling servers <NUM>. Time-to-graph mappings <NUM> are maintained in the system (which can be in the Redis cache). The time-to-graph mappings <NUM> can be polled by each of the servers <NUM> (e.g., once-per minute) and locally stored in the servers <NUM> as current mappings instance data <NUM>. The currently active graph set <NUM> in the content selection graph data store <NUM> is known to the request handling servers <NUM> based on the current time. Thus, requests <NUM> are handled by returning responses <NUM> from the current graph set <NUM>, until the mappings <NUM> / current mappings instance data <NUM> indicates a new graph set is active.

Thus, as shown in <FIG>, when a client request <NUM> for an item (e.g., data corresponding to a graph node) is received, a request handling server <NUM> of the data service locates the data item in the currently active graph set <NUM>, based on the mappings <NUM> (by selecting the most recent graph set that is before the current time) and the client-specific details (e.g., brand, channel, territory, device type and API version). The response <NUM> contains at least some of the graph node's data. In one or more implementations, that data is already formatted and shaped for that client's specific details within the graph, as there can be multiple graphs within a set of active graphs, e.g., with one graph in the set for each permutation of client-specific information. Note that the request handling servers <NUM> can have their own level one (L1) write-through caches, but the "source of truth" is the content selection graph data store <NUM>.

It should be noted that the response <NUM> contains information obtained from the active graph, but is not limited to the graph node data from the graph node identified in the client request. Indeed, as set forth above, the response can be prebuilt in the data store, including being formatted and shaped for the requesting client based on the client-specific details. Moreover, for example, the response can contain expanded information; e.g., the client requests information corresponding to a node A, based on providing node A's identifier, and receives information from node A as well as from a node B even though the client did not identify node B. Further, the information returned to the client can be a proper subset of the graph node data; for example, a client request can identify graph node C, but only receive part of the information in the graph node data of graph node C.

In general, the components of <FIG> load the in-memory content selection graph data store <NUM> with generated and validated future graphs <NUM>, and then serve content from a specific mapped graph of the current graph set <NUM> at the appropriate time. Each graph has a unique identifier and an associated time of use (once mapped), and there can be a different graph for different specific combinations of client-specific information / details / data response formatting factors, facilitating very efficient data retrieval.

As will be understood, various components are managed by a coordinator <NUM> to perform graph-related tasks. Such tasks include generating and writing new graphs, as performed by graph pre-cache generation logic <NUM>, and validating graphs before use, as performed by graph pre-cache validation logic <NUM>. Block <NUM> represents a graph set being generated / validated, along with one or more data structures DS used during generation and validation operations. A maintenance-type task set is performed by garbage collection logic <NUM>, which removes expired graph sets (e.g., <NUM>) as well as various data structures and the like, including those used during the generation and validation operations.

Thus, <FIG> shows how graph sets are able to be prepared in advance to quickly respond from a content selection graph data store <NUM> to any client request <NUM> for the data of a user interface graph node (item) that may come in. The technology described herein stores (pre-caches) entire sets of current and future graphs for a number of relevant points in time based on timepoints, as collected by a timepoint collection component <NUM> that via the coordinator <NUM> causes graph generation requests <NUM> to be made. The data for the responses <NUM>, obtained from one or more backing data stores <NUM>, can be customized / prebuilt in the format expected by the various types of requesting clients, including based on client-specific details.

When the current time reaches the next (future) mapped graph set, the next graph set becomes the current graph set from which responses are served. In the event that a future mapped graph needs to be changed, the mapping is updated once the modified graph is built and validated, whereby the newly generated and validated graph set is basically "hot-swapped" with the old graph set. In case of a catastrophic event, whereby the next graph set is not ready before it is needed, there is no mapping entry for it, and thus the request handling server continues to respond with data from the (now stale) cache, which is deemed significantly better than returning errors / no data.

In this way, responses to client requests are served from a current set (the most recent timepoint in the past), until a next mapped timepoint is reached by the current time, which switches request handling to a next-mapped graph. The technology maintains graph ID - timepoint mappings so that any one graph set is currently in use, until the next timepoint is reached.

Moreover, via the validation logic <NUM>, the technology is safe so that clients get valid data. Still further, because the mappings <NUM> are only updated when a new graph set is ready (successfully generated and validated), clients receive a reasonable response (e.g., stale data) from the most recently valid mapping, even if a catastrophic event occurs that prevents a "future" graph from being generated in time (before it is needed). As also will be understood, the technology is adaptable as changes to graphs / nodes' data are made at any time, e.g., by editors.

Turning to aspects related to how a graph is generated, the technology described herein stores (pre-caches) entire sets of current and future graphs for a number of relevant points in time based on timepoints, as collected by the timepoint collection component <NUM>, which cause graph generation requests <NUM>. Described with reference to <FIG> is the generating and storage in the content selection graph data store <NUM> (e.g., a Redis cache in one or more implementations) of user interface-related data that is arranged as graph nodes, to allow rapid retrieval for client requests. As described herein, a set of graphs are built in advance for one or more future timepoints, with different data formatting factors for the graphs in the set. Once built, the set is validated, and if validation passes, the set is mapped into a set of mappings, meaning that the client request handling data service knows of the graph set's existence and will serve items from the graph set once the associated timepoint is reached.

In one or more implementations, to generate a time-based graph, the graph set generation logic <NUM> uses parallel worker processes <NUM> (<FIG>) to load the content selection graph data store <NUM> with node identifiers and their data. To build the responses, the graph set generation logic <NUM> incorporates or is coupled to a request handling / data formatting engine <NUM> based on a technology that was previously performed on-demand in the request handling (front-end) servers and back-end servers, such as described in U. published patent application nos. <CIT> entitled "GRAPH FOR DATA INTERACTION" and <CIT> entitled "DATA DELIVERY ARCHITECTURE FOR TRANSFORMING CLIENT RESPONSE DATA".

As represented in <FIG>, when a graph is to be built, the root node ID of the graph to be built (e.g., a URN) is placed in a build data structure <NUM> (e.g., a build queue, such as allocated within the Redis cache) by the coordinator <NUM>. A worker process of the available parallel worker processes <NUM> is triggered to operate on an item in the build queue. In general and as shown in <FIG>, each node ID is basically retrieved and marked as dequeued from the build queue (arrow <NUM>), and its data retrieved and formatted (from / by the request handling engine <NUM>, arrow <NUM>) and then put into the graph set being generated / validated <NUM> in conjunction with the node ID (arrow <NUM>). The other node(s) that it references (via one or more edge(s), if any), are also added to the build data structure <NUM> (arrow <NUM>) for a next worker process to handle, and then the node is marked as handled; e.g., a hash of its ID is entered into a visited set data structure <NUM> (arrow <NUM>) representing the set of node identifiers that have already been handled.

So that two worker processes do not work on the same node ID, the worker process that handles a node ID marks a queued data structure entry (representing a node) as invisible, e.g., via invisibility timeout data (IVts) maintained in the data structure. The worker process extracts the edge(s), referenced in node data, to determine other node(s) that need to be handled, and if any exist, adds them to the build data structure <NUM>. However, to avoid redundant work, before adding a new node referenced via an edge to the build data structure <NUM>, the worker process evaluates which other nodes have already been handled / added to the graph (via the visited set data structure <NUM>). Error handling is also performed as described herein. Note that the graph pre-cache generation logic can load a validation queue <NUM> (<FIG>) for validating generated nodes.

With respect to obtaining the data, <FIG> is a block diagram showing the graph set generation logic <NUM>, which has time offset ("time-travel") capabilities, such as described in U. published patent application no. <CIT> and entitled "TIME OFFSET DATA REQUEST HANDLING". A time-travel value may be an adjusted time value relative to the current time (e.g., corresponding to the difference between a timepoint and the current time) or an actual time in the future (corresponding to the timepoint) for which time offset data exists and is retrievable. A time offset server <NUM> may limit the time offset values to only values for which time offset data exists and is retrievable.

As described herein, a front end data retrieval service <NUM> can reformat general data based upon the device in use (as well as the software version of the program running on the device that displays the data). In this way, for example, some future set of data may be formatted to appear one way on a tablet device's display, and another way when appearing on a gaming and entertainment console's display. This means graphs can be generated with future data for each device type, for example.

To this end, the graph set generation logic <NUM> sends a request <NUM> for data, with a token that contains the desired future time and (e.g., simulated) information e.g., representing device type, brand, channel and territory data. Headers accompanying the request can indicate version and language information. This is represented in <FIG> via the arrow labeled one (<NUM>). The token is received during user authentication, as generally described herein; note however that this is only one implementation, and, for example, the data retrieval service alternatively can be preconfigured to map a graph type identifier (ID) to the client-specific / formatting details, so as to only need receive {desired time, graph type ID} from the graph set generation logic.

When the front-end data retrieval service <NUM> receives the request, e.g., as handled by a data retrieval server <NUM> (of possibly more than one), the server <NUM> recognizes from information in the token that the graph set generation logic <NUM> has time-travel privileges and has client-specific data <NUM>. The server <NUM> thus communicates with the time offset server <NUM> to obtain the time-travel value that the graph set generation logic <NUM> has set for time offset data. This is represented in <FIG> via the arrows labeled two (<NUM>) and three (<NUM>).

Because caches are not used with a user's time-travel data (as doing so would use non-time travel data as well as cache undesired time offset data, such as from a previously generated graph set), a request <NUM> is sent with the time offset value to a back-end data service <NUM> (the arrow labeled four (<NUM>)).

The back-end data service <NUM> requests the needed data, at the desired time offset, from the one or more data sources <NUM>, and receives the requested data item or data items. This is represented in <FIG> via the arrows labeled five (<NUM>) and six (<NUM>). Thereafter, the back-end data service <NUM> composes the time offset data <NUM> and returns the <NUM> to the data retrieval server <NUM> (arrow seven (<NUM>)).

In one or more implementations, the time offset data <NUM> is independent of the client-specific details supplied by the graph set generation logic <NUM>. As a result, the data retrieval server <NUM> includes response processing logic <NUM> that formats the data for the particular (simulated) client-specific details, e.g., based on formatting rules <NUM>. The result is a formatted, time offset response <NUM> returned to the graph set generation logic <NUM>, arrow eight (<NUM>), such as described in such as described in U. published patent application nos. <CIT> entitled "TEMPLATING DATA SERVICE RESPONSES" and <CIT> entitled "MAINTAINING AND UPDATING SOFTWARE VERSIONS VIA HIERARCHY". Note that alternative implementations can return data that is already formatted from a back-end service, and thus may not need such device-specific processing, at least not to a full extent.

It should be noted that for efficiency, the same data entity is not saved more than once in the content selection graph data store <NUM>. Instead, the key to locate the content is first based on the graph identifier, and then based on a hash-based entity pointer to a single instance of the data blob in the content selection graph data store <NUM>. Consider, for example, that the content selection graph data store <NUM> is first arranged by type ("graph") and ID (the unique graph identifier) of the key. The value of the key can be a "hashes" (a secondary key) along with an entity identifier as the secondary key's value, comprising the hash of an entity data blob (e.g., a serialized JSON data blob). Thus, once retrieved, the hash value serves as a pointer to the single data instance / entity from which the Redis cache returns the correct data blob.

Note that locating the correct data is thus a two-level lookup, (get the correct graph, then get the pointer in that graph), but can be accomplished by a single call to Redis that invokes a LUA script, e.g., using HmGet, mGet commands). Note that multiple data blobs are typically requested by a client in a single request, and thus mGet (multiple Get) / HmGet (hash multiple Get) are used in one or more implementations.

<FIG> summarizes example operations of the graph set generation logic <NUM>, including operation <NUM> in which a worker process that is seeking a node (item) to process makes a request queue item call, and if an item is available, gets back an item to process. The call also causes the item to be set with an invisibility timeout (e.g., <NUM> seconds) and also increments a retry count.

The processing by the worker process includes checking (operation <NUM>) whether the node has already been handled (visited), which is possible because a node may be referenced by more than one other node (via an edge), including by a node it references. If already handled, the worker process branches ahead to operation <NUM> to make a delete queue item call.

If not previously visited, a response is generated for that item at operation <NUM> (by calling the request handling engine <NUM>, <FIG>), and the response is now obtained for storage. If the response generation failed (as evaluated at operation <NUM>), the worker process ends, leaving the item in the build data structure <NUM> to be handled again (once it becomes visible after the invisibility timeout is reached), up to the maximum amount of retries allowed. The maximum retry count prevents bad / missing node data from causing the generation process to run basically forever. Note that if the maximum retry count is reached (operation <NUM>), the item can be marked as having been visited and deleted; also the error can be flagged (operation <NUM>) so someone such as an editor can investigate why the item was unable to be put into the graph.

If the response is generated and cached, any other node(s) referenced by the node being processed are added to the build queue, as represented by operation <NUM>. The item is marked as visited (operation <NUM>), and then a delete queue item call is made at operation <NUM>.

Note that an item is not actually dequeued when retrieved, because <NUM>) the worker process may fail and <NUM>) the queue is not considered empty when at least one item is still being processed. Instead, the item is marked as invisible with respect to "receive queue item" retrieval for some timeout time, such as <NUM> seconds. If the worker process fails, the item is allowed to be retrieved for processing again, after the timeout time. Thus, the retrieve queue item call / delete queue item call is generally transactional in nature.

Turning to <FIG> and validation, that is, the processes and logic that validate each time-based graph following generation, once generated but before mapped for use, a graph needs to be validated to make sure it has no significant errors. To this end, validation logic dequeues each item from a validation queue <NUM>, locates and applies validation rules <NUM> specific to that item / item type, and records any errors or warnings associated with that item. Worker processes <NUM>, e.g., provided / triggered by the coordinator <NUM> and/or generation logic <NUM> (<FIG>), perform the validation. An alternative implementation may use the worker processes to crawl each graph to validate each node, e.g., instead of using a validation queue.

Thus, in general, validation refers to validating user interface-related data that is arranged as a graph of nodes, to ensure cached data has no significant errors. Validation ensures that valid data is served to clients from a cache for any client request for a user interface graph node (item) that may come in, including for each client-specific detail (e.g., device type, version, etc.).

To this end, before allowing a graph to be used, each node is validated against validation rules <NUM>. In one or more implementations, following successful generation, each item (node ID) in a validation queue is processed; the item ID may be written as part of generation, or copied from the visited queue (e.g., minus failed nodes), and so on. An alternative implementation is to walk each node in the graph.

As generally shown in <FIG> and <FIG>, regardless of how a node / item is obtained at operation <NUM> (by calling receive queue item or by walking the graph), validation is based on a worker process evaluating the node data (e.g., the returned response data) against a set of rules that is relevant to that node (operation <NUM>). Note that the same general concepts for generation can be used for validation, e.g., invisibility for a time upon calling to receive a queued item, marking a node as visited (e.g., if traversing the graph) and so forth to avoid inefficient reprocessing.

With respect to selective rules, for example, for a "menu" type node, a rule may specify, for example, that the menu contain at least one item, and that there are no duplicate nodes (with the same URN) listed in the menu. For a "feature" type node (representing a piece of content such as a movie or television program that can be streamed), a rule may specify that the feature contain a title that is not an empty string, for example. A "series" type node may evaluate whether all listed seasons actually exist, and so on. Rules may be specific to brand, channel, territory, device type and API version; for example, a rule for API version X may look for a node attribute that is present in API version X, whereas the attribute may not exist in API version Y, and thus no such rule is applicable.

If upon evaluation against the validation rules for the node type there is no violation (operation <NUM>), the validation process branches ahead to operation <NUM> to delete that item from the validation data structure (or otherwise mark the node as having been handled), and, for example, adding the node identifier to a visited set data structure. Operation <NUM> repeats the process with a different node item until the validation data structure is empty or the entire graph has been traversed.

Where there is a violation at operation <NUM>, some action is taken at operation <NUM>. Note that some rule violations may be considered errors and recorded as such, while other violations may be recorded as warnings.

In addition to (or instead of) errors and warnings, a graph may be scored, for example, by having different kinds of violations have different weights. The score can be accumulated for a given graph.

A violation that is considered significant enough to fail the validation process may halt the validation process (operations <NUM> and <NUM>) and notify a responsible person or team. For example, if the root (home) menu has no referenced items, the entire graph is not functional. Other errors may be too significant to consider the graph to be reasonably useable. Further, a validation score for a graph may reach an accumulated threshold value that fails the graph and halts further validation. Otherwise, at operation <NUM> the item is deleted (or otherwise marked as having been handled), and validation continues (operation <NUM>) until the graph is successfully validated (or fails). Note that even if a graph is successfully validated, a responsible person or team may look into any warnings or errors that were logged.

Turning to coordination of generation and validation, the coordinator <NUM> coordinates the series of processes and the logic that first builds and then validates the graphs. An input message (e.g., corresponding to a new timepoint) triggers a graph generation request, and the request can be expanded to include any non-specified parameters. Based on the request, the coordinator <NUM> generates the graph IDs, creates the various build and validation queues, triggers the building operations, determines graph completion, triggers the validation operations of each completed graph and maps the graphs that successfully validate.

The coordinator <NUM> thus coordinates how entire sets of current and future graphs may be cached (built, validated and mapped) for a number of relevant points in time (timepoints). A set of graphs are built in advance for a future timepoint. There can be a different graph in the set for each permutation of client-specific details (e.g., brand, channel, territory, device type and API version). Once built, the set is validated, and if validation passes, the set is mapped into a set of mappings, meaning that the client request handling data service knows of the set's existence and will serve items from the set once the timepoint is reached. The coordinator can also remove a mapping, e.g., if the new graph set is intended to replace another graph set that was previously built, with the other graph set now considered an "orphaned" graph set.

As shown in <FIG> and <FIG> and <FIG>, coordination is needed to manage the various processes that build and validate each graph, and then map the graph set if successful. Coordination starts upon receiving a request to build a graph set (operation <NUM>). The request may be expanded for any non-specified parameters at operation <NUM>; e.g., if a device type is not specified in the request, then a graph is generated for each supported device type. In one or more implementations, there may be many dimensions for expansion by the coordinator, as timepoint, along with brand, channel, territory, device type and API version are parameters that may be specified or left unspecified with any request. This can, for example be done in various ways. For example, a graph set can have a generally common identifier (e.g., sequentially chosen so as to ensure uniqueness within the system) associated with a timepoint, with brand, channel, territory, device type and API version parameters being represented by a value appended to the generally common identifier for that graph set. A request for a graph node in a graph finds the active graph set, and then uses the client-specific information to determine which graph in the active graph set applies to the given request. Alternatively, the mapping can have a system-unique identifier for each timepoint and client-specific permutation that is not necessarily related to other active graphs; a request maps to one graph identifier for the particular timepoint/brand/ channel/ territory/device type/API version permutation.

For each graph in the graph set, the coordinator <NUM> generates a unique graph ID at operation <NUM>, adds the graph ID to an outstanding set (operation <NUM>) creates a build data structure <NUM> (<FIG>) such as the build queue (in a paused state, operation <NUM>), and creates a validation data structure <NUM> (<FIG>) such as the validation queue (in a paused state, operation <NUM>). The coordinator <NUM> triggers the building process at operation <NUM> by adding the root node to the build queue (which un-pauses the build queue) causing the generation component to begin building the graph as described herein. Note that a graph can be identified by brand/channel/territory/device/API version/timepoint, which is mapped to a unique graph ID. To hot swap a graph with a replacement graph, the brand/channel/territory/device/API version/timepoint can be mapped to a different graph ID.

The coordinator <NUM> then evaluates for completion of the build for that graph, as represented by operation <NUM> of <FIG>; e.g., polls a generation status flag (set when generation starts) that the generation component worker process clears when the build queue is empty (no worker has added any other node ID)). If the build was successful as evaluated at operation <NUM>, the coordinator triggers validation; otherwise the process is halted at operation <NUM>. For example, if the build was successful the coordinator may un-pause the validation queue at operation <NUM> to evaluate for completion of validation.

In an alternative to validation based on a validation data structure (e.g., a validation queue), the coordinator can trigger a graph traversal. As described herein, via a graph traversal each relevant node can be selected, an associated rule set obtained for that node (e.g., based on node type and client-specific information), with the response data for that node evaluated against the selected rule set.

The system can poll a validation status flag (generally similar to that of the build status flag) to determine when validation is complete. If validation is successful (operation <NUM>), the coordinator <NUM> (or another component of the system <NUM>) maps the graph by writing the mapping to the data service client handler's mapping set (operation <NUM>), and removes the graph ID from the outstanding set (operation <NUM>). Otherwise the process is halted (operation <NUM>), without ever having written the mapping. Note that operations <NUM> and <NUM> remove the graph ID from the outstanding set, which means that the graph and associated data structures, etc., will be removed from storage during garbage collection, as described herein.

Note that the coordinator may batch requests received over a period of time, so that, for example, a small change does not immediately trigger graph generation, in case a number of such changes are being made at generally the same time. The coordinator also may replace graphs in the cache by swapping one mapping for another when those graphs have the same time point, to allow for changing the graph once a change is needed.

The coordinator also may trigger garbage collection, although this may be a time-based process that runs periodically for example, or runs whenever a new timepoint is reached.

Turning to another aspect, <FIG> represents the concept of collecting timepoints (e.g., start times, end times and/or commencement times, such as in Coordinated Universal Time) used for generating the graphs of the available streaming content offerings. In one or more aspects, the technology detects changes made to content / the programming schedule / a graph node, to insert a new timepoint into the set of timepoints to trigger automatic graph generation.

More particularly, the user interface data for selecting content, arranged as a graph, regularly changes as new offerings become available and other offerings expire. Each new timepoint corresponds to a different set of graphs. In addition to new offerings, editors often make changes to programming schedules, such as when an unexpected event occurs, or when an error is discovered. Editors also make editorial changes, such as to use a special image in conjunction with a particular feature. When a change is made, any previously obtained graph data with respect to a changed schedule is no longer valid.

To this end, a timepoint service <NUM> collects the timepoints that are relevant for the sets of future graphs, and monitors for changes relevant to any (possibly) pregenerated graph. Changes can be received as events / notifications from a notification (publisher) system <NUM>.

In this way, the timepoint service <NUM> monitors for changes relevant to the data in the underlying existing graphs; in one implementation this is done by subscribing for change notifications via the technology described in <CIT> and entitled "MONITORING SERVICE FOR PRE-CACHED DATA MODIFICATION", which describes one suitable notification (publisher) system <NUM>. Whenever a change occurs, an event is published and detected by the timepoint service <NUM>, which determines the relevant timepoint or timepoints affected. The timepoint service <NUM> / timepoint collection component <NUM> (which can
be a single combined entity) sends a request message to the coordinator <NUM> for a new graph set to be generated. The timepoint service <NUM> (or the coordinator <NUM>) may replace an existing graph set, or insert a new timepoint into the timepoint collection component <NUM> (having the timeline corresponding to the graph sets) used for generating the time-based graphs.

By way of example, as generally represented in <FIG>, a change producing entity <NUM>, such as editors, programming department personnel and the like, makes changes related in data sources <NUM> to content that is to be made available for user viewing. Example data sources include a catalog <NUM> of content-related items to be offered, an image service <NUM> that provides representative images for use in data items presented to a user for interactive selection, and a video service <NUM>. The change producing entity <NUM> also may output editorial override information, and or one or more editors such as an editorial team may place information in an editorial override data store <NUM> that overrides any data in the catalog <NUM>, the image service <NUM> and so on.

A change monitoring / signaling service <NUM>, which can be coupled to or incorporated into the notification (publisher) system <NUM>, detects and signals whenever a change to one of the data sources <NUM> is made; for example an event may be output on any database write, along with information as to what information changed. Filtering, batching, sorting, classification and so on (e.g., this database write is of type "change" and is relevant to a data item associated with the root menu having an identifier of "urn:hbo:navigation:root") may be performed so that relevant events with contextual information are propagated to downstream listeners that are interested in certain types of events.

To propagate the relevant events, the change monitoring / signaling service <NUM> / the notification (publisher) system <NUM> outputs a message or other similar event notification to consuming subscriber entities, two of which are exemplified in <FIG> as a user-specific data caching ("watchlist") service <NUM> and the timepoint service <NUM>. Note that instead of message propagation / publication, a feasible alternative is to place the messages in a commonly accessible storage or the like for polling by interested consumer entities. As used herein, the term "change event" with respect to an entity may be used interchangeably with "message" or "notification" and covers the concept of propagated change events as well as change events obtained via polling.

As described herein, for events that affect timepoints, the timepoint service <NUM> / timepoint collection component <NUM> and/or the coordinator <NUM> take action to invalidate (and/or replace) any data made obsolete by the change. This prevents incorrect data items from being served when they would otherwise become active at a specified time.

Another type of event, which is independent of the data sources <NUM>, relates to events that affect user login statuses. Such events can be detected at the front end data service. For login events, the watchlist service <NUM> may pre-populate the content selection graph data store <NUM> (<FIG>) with information based on per-user data <NUM>. It should be noted that a user can get a different graph when logged in or not, e.g., particularly with respect to the per-user data <NUM>.

In this way, the various databases and the like that support user interface content are scanned for timepoints corresponding to future graphs. Requests to generate the future graphs are then sent to the coordinator <NUM>, which coordinates the generation, validation and mapping of those graphs.

Turning to aspects related to garbage collection, the system <NUM> needs to safely reclaim space in the content selection graph data store <NUM> (<FIG>), e.g., corresponding to expired graphs (e.g., expired graph set <NUM>) that are no longer in use, as well as other associated storage space. As can be readily appreciated, the building of the set of graphs, validation of each graph and the graphs themselves can consume relatively significant amounts of memory.

To safely reclaim such memory space, at appropriate times, garbage collection logic <NUM> runs with a set mutex to safely delete the various data structures, and delete each expired graph once a more recent graph is mapped and is being used. The garbage collection technology described herein also locates and deletes orphaned graphs, which are those that were replaced because of a programming / graph node change.

Note that there is not simply an expired graph and related data structures to reclaim, but rather a number of cache memory consumers that need to be carefully and safely reclaimed. This can include graph mapping data, graph metadata, graph build data structures (e.g., queues, status data, etc.), graph validation data structures (e.g., queues, status data, etc.), error data, such as build errors, and so forth.

At any instant in time relative to the content selection graph data store <NUM>, a number of current graphs are in use, future graphs may be being built or validated, there may be graph metadata, build structures, failed graphs, orphaned (successfully generated, validated and mapped but later replaced) graphs, and so on, each of which need to be left intact, or need to be fully reclaimed (or else the amount of available cache memory will decline over time). Note that in one or more implementations, the content selection graph data store <NUM> is not only used for the graphs, but also for the various data structures used for generating and validating graphs. In one or more alternative implementations, a separate data store can be used for the structures needed to generate the graphs.

The garbage collection logic <NUM> designed for the content selection graph data store <NUM> is run, e.g., periodically and/or possibly on an event driven basis, such as when the graph set (formerly) in use in association with a timepoint becomes expired, when storage reaches a threshold capacity, and/or upon a need for new future graph generation. As shown in the <FIG> and <FIG>, garbage collection logic operates by setting a write mutex (operation <NUM>, e.g., via the SET command) on the content selection graph data store <NUM> (Redis cache) so that the coordinator <NUM> can finish operations and thereafter wait for the mutex to be released. Note that the Redis Scan command gets the set of keys in the cache; however if a build mutex (e.g., written by the coordinator) has the cache locked, garbage collection cannot be performed until a next iteration. Further note that the mutex is a write mutex, so that the cache can continue to serve content during garbage collection.

At operation <NUM> the garbage collection logic <NUM> waits for an interval (e.g. longer than the generation status polling interval) for the other operations to finish, and then starts collecting garbage.

To collect the garbage, at operation <NUM> the garbage collection logic <NUM> scans the content selection graph data store <NUM> to get the set of keys (e.g., namespace | graph ID | optional suffix, such as outstanding_graph_IDs) that exist in the Redis cache. With the graph IDs, the garbage collection logic <NUM> looks at the mappings to determine old graphs (operation <NUM>). Note that this corresponds to any graph that is mapped to a time before the current time, other than the set of graphs currently in use (of the mapped times; the graph set in use has the greatest time less than or equal to the current time).

The garbage collection logic <NUM> also determines the graphs that are outstanding (yet to be fully built and/or validated), so that these are not cleaned up. Such graphs are determined based on the keys, e.g., identified as outstanding graph IDs via their cache keys (operation <NUM>).

To determine orphaned graphs (operation <NUM>), the garbage collector looks for graphs that are not mapped and are not outstanding graphs, e.g., the graph that was replaced; (note that failed graphs are removed from the outstanding set so that they will be garbage collected). Once determined, as represented by operation <NUM> of <FIG>, the garbage collection logic <NUM> deletes the old and orphaned graphs, and other structures that do not correspond to outstanding graphs. Note that this also deletes hashed entity pointers associated with that graph.

As represented by operation <NUM>, the garbage collection logic <NUM> fetches the hashes for good, existing graphs, that is, those graphs currently in use and those graphs planned to be used in the future. At operation <NUM>, the garbage collection logic <NUM> collects the set of referenced entity keys; these referenced keys are compared to the full set of entity keys (also obtained via operation <NUM>) to determine orphaned entity keys, which are then deleted along with their corresponding data blobs, along with any other keys / data that are not needed (operation <NUM>). The garbage collection logic <NUM> deletes the old mappings (operation <NUM>) and unlocks the mutex (operation <NUM>).

Note that any deleted information may be moved (e.g., to a hard drive) before or as part of deletion, e.g., archived for debugging, data analysis and the like. Further, note that the garbage collector, if relatively slow compared to the need for new graph generation, can be partially run, e.g., for a certain length of time, and then resumed at a later time. In general, however, for the current data in use, running the garbage collection operations once per day, which takes on the order of <NUM> seconds, has proved sufficient.

One or more example aspects, such as corresponding to operations of a method, are represented in <FIG>. Operation <NUM> represents generating a content selection graph corresponding to a future timepoint, comprising processing node data representing content associated with the timepoint into node identifiers and response data for respective node identifiers, and processing edge data associated with the node data into graph edges. Operation <NUM> represents preloading the content selection graph into an in-memory data storage in association with a start time, corresponding to the future timepoint, at which the content selection graph becomes active.

Aspects can comprise receiving a request for content, the request comprising a node identifier of a node in the content selection graph, and returning respective response data associated with the node in response to the request.

Processing the edge data can comprise using first edge data associated with first node identifier of a first graph node to locate second node data of a second graph node having a second node identifier.

Generating the content selection graph can comprise obtaining a first node identifier from a build data structure, adding a second node identifier corresponding to first edge data associated with the first node identifier to the build data structure, adding first node data to the content selection graph as a first node identified by the first node identifier, and removing the first identifier from the build data structure.

Aspects can comprise adding the first node identifier to a visited data structure.

Generating the content selection graph can comprise obtaining a node identifier from a build data structure, determining that the node identifier has not been previously processed during the generating the content selection graph, and in response to the determining, processing the node identifier, including removing the identifier from the build data structure and adding the node identifier to a visited queue.

Aspects can comprise marking the node identifier as invisible for a defined time. Aspects can comprise adding the node identifier to a validation data structure.

Processing the node data representing the content associated with the timepoint into the node identifiers and the response data for the respective node identifiers can comprise communicating, for a first node identifier, time data corresponding to the timepoint to a data retrieval service, and receiving first response data corresponding to the first node identifier and the timepoint from the data retrieval service.

Processing the node data representing the content associated with the timepoint into the node identifiers and the response data for the respective node identifiers can comprise communicating, for a first node identifier, client-specific information and time data corresponding to the timepoint to a data retrieval service, and receiving first response data corresponding to the first node identifier and the timepoint from the data retrieval service, wherein the first response data is formatted based on the client-specific information.

One or more aspects can be embodied in a system, such as represented in <FIG>, and for example can comprise a memory that stores computer executable instructions and/or components, and a processor that executes computer executable instructions and/or components stored in the memory to perform operations. Example operations can comprise generating a content selection graph (operation <NUM>), the content selection graph comprising node identifier, response data associations (e.g., the response data for a given node can be accessed via a hash of the node identifier of that node) via for nodes representing content. Operation <NUM> represents obtaining a first node identifier and first edge data associated with the first node identifier. Operation <NUM> represents obtaining first response data for the first node identifier. Operation <NUM> represents storing the first response data in association with the first node identifier. Operation <NUM> represents obtaining a second node identifier based on the first edge data associated with the first node identifier. Operation <NUM> represents obtaining second response data for the second node identifier. Operation <NUM> represents storing the second response data in association with the second node identifier.

The content selection graph can be associated with a future timepoint, and obtaining the first response data for the first node identifier can comprise communicating with a data retrieval service that returns the first response data for the node identifier based on the future timepoint.

The content selection graph can be associated with associated with client-specific information, and obtaining the first response data for the first node identifier can comprise communicating with a data retrieval service that returns the first response data for the node identifier based on the client-specific information.

The content selection graph can be associated with a future timepoint and client-specific information, and obtaining the first response data for the first node identifier can comprise communicating with a data retrieval service that returns the first response data for the node identifier based on the future timepoint and the client-specific information.

Storing the first response data can comprise writing the first response data to a Redis cache.

<FIG> summarizes various example operations, e.g., corresponding to executable instructions of a machine-readable storage medium, in which the executable instructions, when executed by a processor, facilitate performance of the example operations. Operations <NUM>, <NUM> and <NUM> represent obtaining a timepoint, obtaining client-specific information and obtaining a first node identifier, respectively. Operation <NUM> represents obtaining first response data associated with the first node identifier and the timepoint, the first response data formatted based on the client-specific information. Operation <NUM> represents maintaining the first response data in association with the first node identifier in an in-memory data structure. Operation <NUM> represents accessing the first response data in the in-memory data structure in response to a request for data corresponding to the first node identifier.

Maintaining the first response data in association with the first node identifier in the in-memory data structure can comprise storing the first response data at a location in the in-memory data structure based on a hash of the first node identifier.

Further instructions can comprise, determining first edge data associated with the first node identifier, determining a second node identifier from based on the first edge data, obtaining second response data associated with the second node identifier and the timepoint, wherein the second response data is formatted based on the client-specific information, maintaining the second response data in association with the second node identifier in an in-memory data structure, and accessing the second response data in the in-memory data structure in response to a second request for second data corresponding to the second node identifier.

Further instructions can comprise, before obtaining the second response data associated with the second node identifier, determining that the second node identifier has not previously been used to previously obtain the second response data.

Obtaining the first response data can comprise communicating request data to a data retrieval service; the request data can comprise first node identifier data, timepoint data, and client-specific information.

As can be seen, there is described a technology, for generating a preloaded content selection graph for use in rapid retrieval of content selection data. The technology facilitates building graphs / graph sets that become active at a specified time. The technology facilitates loading graphs / graph sets that correspond to client-specific information, and can have prebuilt responses therein to substantially reduce or eliminate the need for subsequent processing to return a response to a request, further facilitating rapid retrieval, including from the requesting client's perspective.

The techniques described herein can be applied to any device or set of devices (machines) capable of running programs and processes. It can be understood, therefore, that personal computers, laptops, handheld, portable and other computing devices and computing objects of all kinds including cell phones, tablet / slate computers, gaming / entertainment consoles and the like are contemplated for use in connection with various implementations including those exemplified herein. Accordingly, the general purpose computing mechanism described below in <FIG> is but one example of a computing device.

Implementations can partly be implemented via an operating system, for use by a developer of services for a device or object, and/or included within application software that operates to perform one or more functional aspects of the various implementations described herein. Software may be described in the general context of computer executable instructions, such as program modules, being executed by one or more computers, such as client workstations, servers or other devices. Those skilled in the art will appreciate that computer systems have a variety of configurations and protocols that can be used to communicate data, and thus, no particular configuration or protocol is considered limiting.

<FIG> thus illustrates a schematic block diagram of a computing environment <NUM> with which the disclosed subject matter can interact. The system <NUM> comprises one or more remote component(s) <NUM>. The remote component(s) <NUM> can be hardware and/or software (e.g., threads, processes, computing devices). In some embodiments, remote component(s) <NUM> can be a distributed computer system, connected to a local automatic scaling component and/or programs that use the resources of a distributed computer system, via communication framework <NUM>. Communication framework <NUM> can comprise wired network devices, wireless network devices, mobile devices, wearable devices, radio access network devices, gateway devices, femtocell devices, servers, etc..

The system <NUM> also comprises one or more local component(s) <NUM>. The local component(s) <NUM> can be hardware and/or software (e.g., threads, processes, computing devices). In some embodiments, local component(s) <NUM> can comprise an automatic scaling component and/or programs that communicate / use the remote resources <NUM> and <NUM>, etc., connected to a remotely located distributed computing system via communication framework <NUM>.

One possible communication between a remote component(s) <NUM> and a local component(s) <NUM> can be in the form of a data packet adapted to be transmitted between two or more computer processes. Another possible communication between a remote component(s) <NUM> and a local component(s) <NUM> can be in the form of circuit-switched data adapted to be transmitted between two or more computer processes in radio time slots. The system <NUM> comprises a communication framework <NUM> that can be employed to facilitate communications between the remote component(s) <NUM> and the local component(s) <NUM>, and can comprise an air interface, e.g., Uu interface of a UMTS network, via a long-term evolution (LTE) network, etc. Remote component(s) <NUM> can be operably connected to one or more remote data store(s) <NUM>, such as a hard drive, solid state drive, SIM card, device memory, etc., that can be employed to store information on the remote component(s) <NUM> side of communication framework <NUM>. Similarly, local component(s) <NUM> can be operably connected to one or more local data store(s) <NUM>, that can be employed to store information on the local component(s) <NUM> side of communication framework <NUM>.

In order to provide additional context for various embodiments described herein, <FIG> and the following discussion are intended to provide a brief, general description of a suitable computing environment <NUM> in which the various embodiments of the embodiment described herein can be implemented. While the embodiments have been described above in the general context of computer-executable instructions that can run on one or more computers, those skilled in the art will recognize that the embodiments can be also implemented in combination with other program modules and/or as a combination of hardware and software.

Generally, program modules include routines, programs, components, data structures, etc., that perform particular tasks or implement particular abstract data types. Moreover, those skilled in the art will appreciate that the methods can be practiced with other computer system configurations, including single-processor or multiprocessor computer systems, minicomputers, mainframe computers, Internet of Things (IoT) devices, distributed computing systems, as well as personal computers, hand-held computing devices, microprocessor-based or programmable consumer electronics, and the like, each of which can be operatively coupled to one or more associated devices.

The illustrated embodiments of the embodiments herein can be also practiced in distributed computing environments where certain tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules can be located in both local and remote memory storage devices.

Computing devices typically include a variety of media, which can include computer-readable storage media, machine-readable storage media, and/or communications media, which two terms are used herein differently from one another as follows. Computer-readable storage media or machine-readable storage media can be any available storage media that can be accessed by the computer and includes both volatile and nonvolatile media, removable and non-removable media. By way of example, and not limitation, computer-readable storage media or machine-readable storage media can be implemented in connection with any method or technology for storage of information such as computer-readable or machine-readable instructions, program modules, structured data or unstructured data.

Computer-readable storage media can include, but are not limited to, random access memory (RAM), read only memory (ROM), electrically erasable programmable read only memory (EEPROM), flash memory or other memory technology, compact disk read only memory (CD-ROM), digital versatile disk (DVD), Blu-ray disc (BD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, solid state drives or other solid state storage devices, or other tangible and/or non-transitory media which can be used to store desired information. In this regard, the terms "tangible" or "non-transitory" herein as applied to storage, memory or computer-readable media, are to be understood to exclude only propagating transitory signals per se as modifiers and do not relinquish rights to all standard storage, memory or computer-readable media that are not only propagating transitory signals per se.

Computer-readable storage media can be accessed by one or more local or remote computing devices, e.g., via access requests, queries or other data retrieval protocols, for a variety of operations with respect to the information stored by the medium.

Communications media typically embody computer-readable instructions, data structures, program modules or other structured or unstructured data in a data signal such as a modulated data signal, e.g., a carrier wave or other transport mechanism, and includes any information delivery or transport media. The term "modulated data signal" or signals refers to a signal that has one or more of its characteristics set or changed in such a manner as to encode information in one or more signals. By way of example, and not limitation, communication media include wired media, such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media.

With reference again to <FIG>, the example environment <NUM> for implementing various embodiments of the aspects described herein includes a computer <NUM>, the computer <NUM> including a processing unit <NUM>, a system memory <NUM> and a system bus <NUM>. The system bus <NUM> couples system components including, but not limited to, the system memory <NUM> to the processing unit <NUM>. The processing unit <NUM> can be any of various commercially available processors. Dual microprocessors and other multi-processor architectures can also be employed as the processing unit <NUM>.

The system bus <NUM> can be any of several types of bus structure that can further interconnect to a memory bus (with or without a memory controller), a peripheral bus, and a local bus using any of a variety of commercially available bus architectures. The system memory <NUM> includes ROM <NUM> and RAM <NUM>. A basic input/output system (BIOS) can be stored in a non-volatile memory such as ROM, erasable programmable read only memory (EPROM), EEPROM, which BIOS contains the basic routines that help to transfer information between elements within the computer <NUM>, such as during startup. The RAM <NUM> can also include a highspeed RAM such as static RAM for caching data.

The computer <NUM> further includes an internal hard disk drive (HDD) <NUM> (e.g., EIDE, SATA), and can include one or more external storage devices <NUM> (e.g., a magnetic floppy disk drive (FDD) <NUM>, a memory stick or flash drive reader, a memory card reader, etc.). While the internal HDD <NUM> is illustrated as located within the computer <NUM>, the internal HDD <NUM> can also be configured for external use in a suitable chassis (not shown). Additionally, while not shown in environment <NUM>, a solid state drive (SSD) could be used in addition to, or in place of, an HDD <NUM>.

Other internal or external storage can include at least one other storage device <NUM> with storage media <NUM> (e.g., a solid state storage device, a nonvolatile memory device, and/or an optical disk drive that can read or write from removable media such as a CD-ROM disc, a DVD, a BD, etc.). The external storage <NUM> can be facilitated by a network virtual machine. The HDD <NUM>, external storage device(s) <NUM> and storage device (e.g., drive) <NUM> can be connected to the system bus <NUM> by an HDD interface <NUM>, an external storage interface <NUM> and a drive interface <NUM>, respectively.

The drives and their associated computer-readable storage media provide nonvolatile storage of data, data structures, computer-executable instructions, and so forth. For the computer <NUM>, the drives and storage media accommodate the storage of any data in a suitable digital format. Although the description of computer-readable storage media above refers to respective types of storage devices, it should be appreciated by those skilled in the art that other types of storage media which are readable by a computer, whether presently existing or developed in the future, could also be used in the example operating environment, and further, that any such storage media can contain computer-executable instructions for performing the methods described herein.

A number of program modules can be stored in the drives and RAM <NUM>, including an operating system <NUM>, one or more application programs <NUM>, other program modules <NUM> and program data <NUM>. All or portions of the operating system, applications, modules, and/or data can also be cached in the RAM <NUM>. The systems and methods described herein can be implemented utilizing various commercially available operating systems or combinations of operating systems.

Computer <NUM> can optionally comprise emulation technologies. For example, a hypervisor (not shown) or other intermediary can emulate a hardware environment for operating system <NUM>, and the emulated hardware can optionally be different from the hardware illustrated in <FIG>. In such an embodiment, operating system <NUM> can comprise one virtual machine (VM) of multiple VMs hosted at computer <NUM>. Furthermore, operating system <NUM> can provide runtime environments, such as the Java runtime environment or the. NET framework, for applications <NUM>. Runtime environments are consistent execution environments that allow applications <NUM> to run on any operating system that includes the runtime environment. Similarly, operating system <NUM> can support containers, and applications <NUM> can be in the form of containers, which are lightweight, standalone, executable packages of software that include, e.g., code, runtime, system tools, system libraries and settings for an application.

Further, computer <NUM> can be enable with a security module, such as a trusted processing module (TPM). For instance with a TPM, boot components hash next in time boot components, and wait for a match of results to secured values, before loading a next boot component. This process can take place at any layer in the code execution stack of computer <NUM>, e.g., applied at the application execution level or at the operating system (OS) kernel level, thereby enabling security at any level of code execution.

A user can enter commands and information into the computer <NUM> through one or more wired/wireless input devices, e.g., a keyboard <NUM>, a touch screen <NUM>, and a pointing device, such as a mouse <NUM>. Other input devices (not shown) can include a microphone, an infrared (IR) remote control, a radio frequency (RF) remote control, or other remote control, a joystick, a virtual reality controller and/or virtual reality headset, a game pad, a stylus pen, an image input device, e.g., camera(s), a gesture sensor input device, a vision movement sensor input device, an emotion or facial detection device, a biometric input device, e.g., fingerprint or iris scanner, or the like. These and other input devices are often connected to the processing unit <NUM> through an input device interface <NUM> that can be coupled to the system bus <NUM>, but can be connected by other interfaces, such as a parallel port, an IEEE <NUM> serial port, a game port, a USB port, an IR interface, a BLUETOOTH® interface, etc..

A monitor <NUM> or other type of display device can be also connected to the system bus <NUM> via an interface, such as a video adapter <NUM>. In addition to the monitor <NUM>, a computer typically includes other peripheral output devices (not shown), such as speakers, printers, etc..

The computer <NUM> can operate in a networked environment using logical connections via wired and/or wireless communications to one or more remote computers, such as a remote computer(s) <NUM>. The remote computer(s) <NUM> can be a workstation, a server computer, a router, a personal computer, portable computer, microprocessor-based entertainment appliance, a peer device or other common network node, and typically includes many or all of the elements described relative to the computer <NUM>, although, for purposes of brevity, only a memory/storage device <NUM> is illustrated. The logical connections depicted include wired/wireless connectivity to a local area network (LAN) <NUM> and/or larger networks, e.g., a wide area network (WAN) <NUM>. Such LAN and WAN networking environments are commonplace in offices and companies, and facilitate enterprise-wide computer networks, such as intranets, all of which can connect to a global communications network, e.g., the Internet.

When used in a LAN networking environment, the computer <NUM> can be connected to the local network <NUM> through a wired and/or wireless communication network interface or adapter <NUM>. The adapter <NUM> can facilitate wired or wireless communication to the LAN <NUM>, which can also include a wireless access point (AP) disposed thereon for communicating with the adapter <NUM> in a wireless mode.

When used in a WAN networking environment, the computer <NUM> can include a modem <NUM> or can be connected to a communications server on the WAN <NUM> via other means for establishing communications over the WAN <NUM>, such as by way of the Internet. The modem <NUM>, which can be internal or external and a wired or wireless device, can be connected to the system bus <NUM> via the input device interface <NUM>. In a networked environment, program modules depicted relative to the computer <NUM> or portions thereof, can be stored in the remote memory/storage device <NUM>. It will be appreciated that the network connections shown are example and other means of establishing a communications link between the computers can be used.

When used in either a LAN or WAN networking environment, the computer <NUM> can access cloud storage systems or other network-based storage systems in addition to, or in place of, external storage devices <NUM> as described above. Generally, a connection between the computer <NUM> and a cloud storage system can be established over a LAN <NUM> or WAN <NUM> e.g., by the adapter <NUM> or modem <NUM>, respectively. Upon connecting the computer <NUM> to an associated cloud storage system, the external storage interface <NUM> can, with the aid of the adapter <NUM> and/or modem <NUM>, manage storage provided by the cloud storage system as it would other types of external storage. For instance, the external storage interface <NUM> can be configured to provide access to cloud storage sources as if those sources were physically connected to the computer <NUM>.

The computer <NUM> can be operable to communicate with any wireless devices or entities operatively disposed in wireless communication, e.g., a printer, scanner, desktop and/or portable computer, portable data assistant, communications satellite, any piece of equipment or location associated with a wirelessly detectable tag (e.g., a kiosk, news stand, store shelf, etc.), and telephone. This can include Wireless Fidelity (Wi-Fi) and BLUETOOTH® wireless technologies. Thus, the communication can be a predefined structure as with a conventional network or simply an ad hoc communication between at least two devices.

The above description of illustrated embodiments of the subject disclosure, comprising what is described in the Abstract, is not intended to be exhaustive or to limit the disclosed embodiments to the precise forms disclosed. While specific embodiments and examples are described herein for illustrative purposes, various modifications are possible that are considered within the scope of such embodiments and examples, as those skilled in the relevant art can recognize.

As it employed in the subject specification, the term "processor" can refer to substantially any computing processing unit or device comprising, but not limited to comprising, single-core processors; single-processors with software multithread execution capability; multi-core processors; multi-core processors with software multithread execution capability; multi-core processors with hardware multithread technology; parallel platforms; and parallel platforms with distributed shared memory. Additionally, a processor can refer to an integrated circuit, an application specific integrated circuit, a digital signal processor, a field programmable gate array, a programmable logic controller, a complex programmable logic device, a discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. Processors can exploit nano-scale architectures such as, but not limited to, molecular and quantum-dot based transistors, switches and gates, in order to optimize space usage or enhance performance of user equipment. A processor may also be implemented as a combination of computing processing units.

Claim 1:
A method comprising:
generating a content selection graph (<NUM>) for storing response data to be returned in response to a client request (<NUM>), wherein nodes of the content selection graph comprising node data representing content, each node having a node identifier, and each of the response data corresponding to a respective node identifier, and wherein edge data associated with a first node references a second node of the content selection graph,
wherein the generating the content selection graph comprises:
obtaining a node identifier from a build data structure (<NUM>), wherein the build data structure includes the node identifiers, including the obtained node identifier, to be processed for generating the content selection graph,
determining, via a visited set data structure (<NUM>), whether the obtained node identifier has not been previously processed during the generating the content selection graph, wherein the visited set data structure represents a set of node identifiers that have already been handled, and
in response to the determining that the obtained node identifier has not been previously processed, processing the obtained node identifier, including:
formatting the response data that corresponds to the obtained node identifier based on client-specific information,
removing the obtained node identifier from the build data structure, and
adding the obtained node identifier to the visited set data structure; and
preloading the content selection graph into an in-memory data storage (<NUM>) in association with a start time at which the content selection graph becomes active.