Patent Publication Number: US-11665265-B2

Title: Method for resolving delivery path unavailability

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
     This application is a continuation of U.S. application Ser. No. 16/219,220 filed Dec. 13, 2018, which is a continuation of U.S. application Ser. No. 12/967,714 filed Dec. 14, 2010, now U.S. Pat. No. 10,187,496, each of which is hereby incorporated by reference in its entirety. 
    
    
     FIELD OF THE DISCLOSURE 
     The present disclosure relates to content delivery, and, more particularly, to resolving bandwidth constriction using multiple bandwidths and/or multiple content delivery paths. 
     BACKGROUND 
     Content available for viewing typically comprises a file resident on a server remote from the viewer. For content such as Video on Demand (VoD), particular video content is requested, obtained from the remote server and streamed, such as via one or more real time streaming servers, over a network to the requesting user. 
     A VoD server may stream video content to a user to allow viewing in real time. The user may receive the streamed video content on a device associated with the user, such as a display device, digital video recorder (DVR), a personal video recorder (PVR), a settop box (STB), or a portable media player, for example, for viewing at any time. Providers offer VoD real time streaming, such as pay-per-view wherein a user buys or selects content in the form of a movie or television program that begins to play almost instantaneously, and VoD downloading, such as to a DVR, for viewing or using of the downloaded content at that time or in the future. 
     For VOD-type content, download and streaming may provide the user with a subset of functionality, such as functionality typically associated with VCR or DVD players, hereinafter referred to as VCR functionality. As used herein, VCR functionality may include pause, fast forward, fast rewind, slow forward, slow rewind, and jump to previous/future frame, for example. For VoD streaming systems that store and stream programs from at least one hard disk drive, VCR functionality may require additional processing and storage, in part because separate files for fast forward and rewind must be stored. On the other hand, memory-based VoD streaming systems may perform VCR functionality directly from a local memory, such a local RAM. 
     At least one server, such as a video server, may typically be located at a central location of a provider, such as a control or distribution center. The central location typically serves a particular market, and larger markets may employ hubs in conjunction with the central location server(s). Delivery of the content from the central location may ultimately be to a device at a user&#39;s premise. Communicatively coupled between the central location and the user&#39;s premise device(s) may be one or more intermediate servers, often referred to as edge servers, which may operate as infrastructure nodes. 
     An edge server may be configured to operate as a gateway to multiple end user devices, for example. An edge server may include storage suitable to save information to be provided to end user devices, including, but not limited to, content such as television shows, movies, advertisements and the like. 
     A distribution network extending from the central location, through, for example, other networks, one or more gateways, and/or one or more edge servers to one or more end user devices, may include bandwidth monitors, regional servers and/or other necessary or desired servers and distribution components, as would be understood by those possessing an ordinary skill in the pertinent arts. The distribution network may also include a vault server, such as in association with the central location, which may store the majority of, or all of, the titles available, although other copies of titles may be stored in other locations. For example, titles in use locally may be stored on a local edge server, and titles used on several edge servers may be stored at a gateway. The vault server may comprise a single server with a large volume of computerized storage, or a multitude of servers that work together to maintain copies of each title. 
     A switched digital video (SDV) system is a content distribution system that may, at least in part, be employed on the distribution network discussed herein. SDV delivers only content that is requested by a user. For example, only the channels or content that are requested by a user may be delivered from an edge server to the requesting user. This is in contrast to, for example, non-switched video where all channels/content may be delivered from the edge server to all users associated with the edge server. SDV thus enables conservation of bandwidth in that only the bandwidth associated with requested content is used. 
     In periods of high demand, a request for SDV content, or for VoD content, may be denied due to bandwidth and other distribution network-related limitations. Current remedies for such problems generally result in denial of the request. Such denial is sought to be prevented by content providers. 
     Thus, there exists a need for a solution that resolves bandwidth constriction that may prevent fulfilling a user request for delivery of content. 
     SUMMARY OF THE DISCLOSURE 
     The present disclosure relates to resolving bandwidth constriction using multiple allocated bandwidths within a single delivery path, and also to multiple allocated bandwidths using multiple content delivery paths. The disclosure relates to an apparatus, system and method for increasing effectiveness of delivery of content, such as data content and video content, such as for VoD or SDV, for example. During periods of insufficient bandwidth for delivery of requested content, a message may be delivered allowing the requested content to be stored, such as at a network DVR, for viewing at a later or relatively contemporaneous point in time over the same or over a different bandwidth (or portion thereof) than the bandwidth (or portion thereof) subjected to the request. 
     The disclosed apparatus, system and method resolve bandwidth constriction using multiple content delivery paths by receiving a request for content and/or monitoring available bandwidth for delivery of the content. Upon encountering a bandwidth constriction, the requester of the content may be queried about recording, and based on an affirmative acknowledgment of the query, the requested content may be recorded. The bandwidth constriction may be resolved, for example, by delivering the video content, such as when it is determined that available bandwidth exists for the delivery, for example. 
     In one aspect, when there is insufficient bandwidth to deliver the requested data and/or video content, a message may be delivered to the requester giving the option to have the requested content recorded, on a network DVR, for example, for viewing later, or with a certain time delay, or using an alternate delivery bandwidth. When there is a constriction during a request for data and/or video content, the requester may optionally receive an alert when the bandwidth limitation subsides, at which time the requester may elect to view the requested content. To view the requested content, the requester may make a single click on the alert, for example. 
     In another aspect, when bandwidth limitation may occur with respect to SDV allocated bandwidth, delivery of the content may occur in substantially real time, such as via VoD allocated bandwidth. Likewise, when there is bandwidth limitation with respect to VoD allocated bandwidth, substantially real time delivery of the requested content may be made via the SDV allocated bandwidth. In each case, an alert may be generated proposing a solution to the bandwidth constriction, and/or when the bandwidth necessary for delivery of the requested content becomes available. The alert may be sent to the requester of the content, such as to a device at a requestor&#39;s premises, or to a mobile device. The alert may be a message shown on a television, for example. The requested content may be played, for example, following a single click acknowledgement on a banner associated with the alert. 
     In these other aspects, the disclosure provides a solution that resolves bandwidth constriction that may prevent fulfilling a request for data and/or video content. 
    
    
     
       BRIEF DESCRIPTION OF THE FIGURES 
       Understanding of the disclosure will be facilitated by consideration of the following detailed description taken in conjunction with the accompanying drawings, in which like numerals refer to like parts: 
         FIG.  1 A  depicts an exemplary architecture for content delivery; 
         FIG.  1 B  depicts an exemplary architecture for content delivery; 
         FIG.  1 C  depicts an exemplary architecture for content delivery; 
         FIG.  2    shows a method in accordance with aspects of the disclosure; and, 
         FIG.  3    shows another method in accordance with aspects of the disclosure. 
     
    
    
     DETAILED DESCRIPTION 
     It is to be understood that the figures and descriptions have been simplified to illustrate elements that are relevant for an understanding, while eliminating, for the purpose of brevity, many other elements found in content delivery systems and methods. Those of ordinary skill in the art may recognize that other elements and/or steps may be desirable and/or required in implementing the disclosure. The disclosure herein is also directed to all such variations and modifications to such elements and methods known to those skilled in the art. 
     The disclosure relates to increasing the effectiveness of delivery of content, such as VoD or SDV type delivery, for example. As used herein, content refers to data and/or video content, or any other type of content. During periods when insufficient bandwidth exists to deliver requested content, and/or where there is a more desirable delivery methodology, a message may be delivered to a user with an option for allowing the requested content to be stored. Such storage may be implemented by recording on a network DVR (nDVR), for example, as discussed in more detail below. The stored content may then be viewed at a later time, or at a relatively contemporaneous point in time. 
     While the disclosure herein describes, by way of example, constriction with respect to VoD and SDV allocated bandwidth, and delivery of content using SDV and VoD allocated bandwidth, respectively, the disclosure is likewise applicable to overcome bandwidth constriction when delivering content via other methodologies. 
     For example, content requested for delivery over SDV or VoD allocated bandwidth in a single delivery path, for example, may be interchangeably delivered via a packet switched network such as the internet, such as by delivering IP packets via a high speed internet connection, in light of the discussion herein. Content delivered via a packet switched network internet allocated bandwidth may be viewed using a display device, or a display device interconnected to another device such as a settop box, for example. A display device connected to the internet, for example, may include a wireless handheld device, a laptop or personal computer, for example. Other delivery bandwidth available to overcome bandwidth constrictions may include an Ethernet or 802.11 connection, by way of non-limiting example. 
     A message may be initiated upon encountering insufficient bandwidth to deliver requested content, wherein the message may query whether to record the requested content on a network DVR (nDVR), for example. In some instances, such as when the constriction is with respect to VoD type delivery, the requester may optionally receive an alert when the bandwidth limitation subsides, at which time the requester may elect to view the requested content. Additionally, the message, or another message, may query as to whether delivery of the requested content over alternate, non-constricted bandwidth, is acceptable. To view the requested content, the requester may optionally play the requested content by, for example, a single click on the alert message. 
     In one aspect, if the bandwidth limitation occurs with respect to the SDV allocated bandwidth, delivery of the content may occur in substantially real time, via the VoD allocated bandwidth, for example. In such a case, an nDVR or other device may serve as a switch that records the requested SDV content and that contemporaneously switches the content to be played on the VoD allocated bandwidth. Of course, other hardware and/or software elements within a network, such as a central processing location (e.g., headend), gateway servers, or edge servers, or the operating systems thereof as discussed herein, may be used to perform this switching. Alternatively, the requesting user may be given an option to view the content over the requested allocated bandwidth, but at a later time, such as after recording at the switch/nDVR. For example, when the bandwidth limitation is with respect to VoD, an alert may be generated when the VoD allocated bandwidth necessary for delivery of the requested VoD content becomes available. 
     An alert may be sent to a user, such as to the device used by the user to request the content, or to another device. The alert may be a banner-type message, for example, displayed on a screen of the requesting device or a screen communicatively connected to the requesting device, alerting the user to the proposed alternate delivery for the content and/or indicating that the requested content is available. The alert may also take the form of an email, a specified display, a phone call, SMS or MMS message, or other prompt recognizable to a user, for example. The requested content may, in some embodiments, be played by, for example, a single click acknowledgement on a message associated with the alert. 
     Referring now to  FIG.  1 A , there is shown an exemplary content delivery system  100 . As shown in  FIG.  1 A , system  100  may include a vault server  110 , a regional network  120 , such as a converged regional area network (CRAN), and on SDV system  130 , having an associated SDV allocated bandwidth. Also shown is nDVR  140 , and VoD system  150 , having an associated VoD allocated bandwidth. 
     Any number of regional networks  120  may be included in delivery system  100 , although one regional network  120  is illustratively shown in  FIG.  1 A . Similarly, any number of vault servers  110  may be included in the delivery system  100 . Likewise, any number of SDV system  130  and VoD system  150  may be employed. A single nDVR  140  is shown in  FIG.  1 A , although multiple nDVR may be interconnected, functioning as a single unit or operating distinctly. Vault server  110  may be located at a provider&#39;s central processing facility  103  of delivery system  100 , and may be communicatively connected to regional network  120 . 
     Communicatively interconnected with regional network  120  may be one or more gateway servers  160 , one or more edge servers  170  and one or more hub edge QAMs  180  (for systems employing such devices). Interconnected with hub edge QAM  180  and/or edge server  170  may be one or more end user devices  190 , such as content receivers, local gateways or STBs, for example. Regional network  120  and/or vault server  110  may have communicatively connected thereto nDVR  140 , for example. 
     The delivery of content from edge server  170  to user devices  190  may be by SDV system  130 . VOD system  150  may also deliver content from a dedicated device such as an edge server  170 , or any other dedicated or shared device, to user device  190 . SDV system  130  and VoD system  150  may share bandwidth for distribution of content to user devices  190 , or may have distinct bandwidth allocations. 
     Vault server  110  may contain content available for request. Vault server  110  may, for example, contain or store all of the available titles for content delivery system  100 . Vault server  110  may be configured to monitor delivery system  100 , and may provide distribution information and monitor statistics associated with one or more user devices  190  and/or end users  198 . 
     Regional network  120  may be any network that can carry voice, video or data. Regional network  120  may allow voice, video and data, such as Internet traffic, over a single network, and may be enhanced with redundant networks. Regional network  120  may connect to a delivery backbone and may include distribution components, and gateways, routers, servers and switches, for example, as would be understood by those possessing an ordinary skill in the pertinent arts. 
     SDV system  130  may transmit or distribute content, such as digital video and may include one or more SDV servers. SDV system  130  takes advantage of the fact that only a percentage of user devices  190  actively watch certain content at any given time, and thus rarely if ever are all channels accessed by all user devices  190 . SDV system  130  may thus send actively viewed digital video to user devices  190 , in order to conserve bandwidth and/or free bandwidth. SDV system  130  may be used in digital video distribution for various types of content distribution systems, such as, for example, systems using QAM, and/or Internet Protocol television (IPTV) systems. IPTV systems may deliver digital television using Internet Protocol over a packet-switched network infrastructure, such as the Internet or like broadband access, rather than delivering through traditional radio frequency broadcast and television formats. 
     SDV system  130  may reduce bandwidth consumption by delivering only requested channels, that is, delivery of only those channels requested by users of delivery system  100  and/or SDV system  130 , as discussed hereinabove. As such, an exemplary bandwidth allotment for SDV system  130  may take into account only those channels that are requested. Bandwidth allocation for SDV system  130  may be based on the number of homes served, number of user devices served, time of day, day of the week, and like factors, for example. Bandwidth allocation for SDV system  130  may, at any given time, be a fixed allocation or an allocation within predetermined limits, and thus a bandwidth limitation or constriction may arise despite the advantages provided by SDV. For example, such a bandwidth limitation would arise if an SDV system  130  channel were requested, but if available bandwidth was insufficient to deliver the requested channel. 
     An nDVR  140 , which may also be referred to as remote storage digital video recorder (RS-DVR), is a digital video recorder that provides content storage at a location communicatively connected to the regional network  120 . Traditionally, content may be stored in user device&#39;s  190  hard drive, but nDVR  140  may provide a much larger volume of storage comprising many servers, including vault, gateway and/or edge servers, for the requested content. 
     VoD system  150  may stream content to user devices  190  and may include one or more VoD servers. VoD system  150  may allow content viewing in real time, or allow content to be downloaded to a device, such as a computer, digital video recorder, personal video recorder or portable media player, for example, for viewing at any time. The majority of providers offer VoD streaming, such as pay-per-view, in which a user buys or selects a movie or television program and may begin to play the content on a television semi-instantaneously, and/or VoD downloading, such as to download requested content to a DVR for viewing in the immediate or more distant future. 
     User device  190  may connect display device  195  and an external source of signal, and may render the received external signal into content for display on the television. User device  190  may modulate data for upstream transmission and may demodulate received data for subsequent display for user  198 . User device  190  may be coupled to and/or incorporate display device  195 , which display device  195  may be capable of rendering the signals received by user device  190  for display to user  198 . User device  190  may receive external signals from edge servers  170  and/or hub edge QAM  180 , for example. User device  190  may provide interactivity, such as wherein user  198  may send a signal into system  100  using user device  190 , and may provide bidirectional communication, for example, such as between user  198  and content system  100 . User  198 , as used herein, is one who interacts with user device  190 , including but not limited to controlling user device  190 . User  198  may identify herself or himself to the system using an account, such as a user account or a username and password, for example. In some aspects, user  198  may access system  100  without an account. 
     User devices  190  may be of different types, such as types based on the transmission path for delivery of content to user  198 . For example, user device  190  may be a settop box  191 . Settop box  191  may modulate data for transmission and may demodulate received data for display to user  198 . Settop box  191  may be coupled to and/or incorporate a display device  195 , which may be capable of rendering received signals for display to user  198 . Settop box  191  may operate using bidirectional communication, meaning settop box  191  may enable user  198  to interact with system  100 . Bidirectional communication may allow user  198  to select alternative delivery paths in the event of a bandwidth constriction, and/or may allow system  100  to notify user  198  of a bandwidth constriction and/or offer alternate delivery path(s). 
     User device  190  may also be tuner  192  within display device  195 , for example. Tuner  192  may modulate data for transmission and may demodulate received data for subsequent display to user  198 . Tuner  192  may provide bidirectional communication, for example, such as between user  198  and content system  100 , which communication may allow user  198  to select alternative delivery paths and/or may allow content system  100  to notify user  198  of a constriction. 
     User device  190  may be IPTV  193 . IPTV  193  may perform signal processing on data for transmission and received data. IPTV  193  may be integral with and/or include display device  195 . IPTV  193  may operate using bidirectional communication to thereby enable user  198  to interact with systems that deliver content. 
     User device  190  may be mobile device  196 . Mobile device  196  may operate in a receive-only mode, such due to bandwidth constraints in transmitting content wirelessly, and therefore may enable user  198  to receive content from, but not enable user  198  to interact with, systems that deliver content. 
     User device  190  may be computer  197 . Computer  197  may operate in a receive-only mode, such as due to bandwidth constraints in transmitting content over computer networks, and therefore may not enable a user  198  to interact with systems that deliver content. 
     Those skilled in the art will appreciate that user device  190  may include other types of devices, such as landline telephones, satellite receivers and broadband receivers, for example. In accordance with the disclosure, such devices are associated with display device  195  for generating a display of requested content to user  198 , and may operate bidirectionally, or in receive-only mode, as discussed with respect to the examples above. 
     A single request, or multiple requests, from a user may go unfulfilled if bandwidth allocation constricts delivery of requested content over a requested communication path, such as over SDV system  130  or VoD system  150 , to the requesting user device  190  or an alternate user device  190 . In order to alleviate such a bandwidth constriction, multiple bandwidth tiers, or alternate content paths, may be provided. For example, in one alternate path, nDVR  140  may record the requested content, such as with appropriate identification to ensure appropriate delivery. Such identification may include, for example, meta data containing information identifying the requested content, user  198 , requesting user device  190 , other user devices  190  of the requesting user  198 , and/or preferred delivery path and time. 
     An nDVR  140  may record the requested content for later delivery over the bandwidth allocated to the requested delivery path, or may serve as a bandwidth switch to contemporaneously or later deliver the requested content over an alternate delivery path. For example, once the recording of requested SDV content by nDVR  140  begins, delivery of the recorded, requested SDV content may fall to a later time and be over the bandwidth allocation of SDV system  130 . Alternatively, delivery of the requested SDV content may, if the SDV allocated bandwidth is constricted, be switched by nDVR  140  for contemporaneous delivery over the VoD allocated bandwidth of VoD system  150 . Effectively, this may eliminate the bandwidth constriction, at least insofar as a particular user is concerned, because the user may thus receive the requested content. 
     Central facility  103  may be communicatively coupled to vault server  110 , and may control vault server  110 . Central facility  103  may receive content signals, such as audiovisual content signals, from a myriad of sources, may process the received signals, and may distribute the processed signals over a provider network. Central facility  103  may be a head-end within a network, for example. A central facility, as used herein, may include any facility for receiving content signals, and for processing and distributing received signals over a provider&#39;s network(s). While central facility  103  is depicted independently from vault server  110 , these elements may be combined. 
     Central facility  103  may verify, establish and/or identify additional paths for distribution of requested content. Central facility  103  may include verification techniques to identify additional content delivery paths, such as by searching a database registration of system users, including interrelations of internet, television and phone users, for example. Such database registration may be used to identify an appropriate alternative path over which requested content may be delivered. 
     Central facility  103  may be interconnected to regional area network  120 , such as via vault server  110 , as discussed above. Central facility  103  may also be interconnected, such as via a broadband path that may or may not include end user device  190 , such as computer  197 , for example, to display device  195 , such as a display for a laptop, personal computer or mobile device, for example. The interconnection to display device  195  may take the form of web connectivity or a similar communicative coupling, such as a wired or wireless coupling. For example, when a customer requests content, such as VoD content or an SDV channel, and bandwidth constraints prevent delivery of the requested content, alternative delivery paths for providing content to a user, such as those including display device  195 , may be determined by central facility  103 . 
     Referring now to  FIG.  1 B , there is shown another exemplary content delivery system  100 . In the illustrated embodiment, system  100  may include multiple vault servers  110   a  and  110   b  communicatively connected, such as via a delivery backbone  105 , to a series of regional networks  120   a ,  120   b , and  120   c . Communicatively coupled to regional network  120   a  may be gateway server(s)  160 , and edge servers  170 . Each of edge servers  170  may be uniquely communicatively coupled to at least one user device  190 . 
     Transmission of content may include delivery of certain content across backbone  105 , through regional network(s)  120 , to end user devices  190 , such as via edge server  170 . Similarly, multicasting may occur across backbone  105  and regional network(s)  120 , such as through edge server  170 , to end user devices  190  that request the multicast content. On the other hand, unicasting may deliver content specifically requested by a unique end user or device  190  only to that requesting end user or device  190 . 
     Referring now to  FIG.  1 C , there is shown another exemplary content delivery system  100 . System  100  may include vault servers  110   a  and  110   b , communicatively coupled via backbone  105  to regional networks  120   a  and  120   b . Communicatively coupled to backbone  105  and/or regional networks  120   a  and  120   b  may be nDVRs  140   a  and  140   b , respectively. Communicatively coupled to regional network  120   a  may be gateway server  160 , a plurality of VoD servers  150   a  and  150   b , and edge servers  170   a  and  170   b . Each edge server  170  may be uniquely communicatively coupled to at least one user device  190 . Associated with each edge server  170  may be SDV system  130 , illustrated as edge server  170   a  and associated SDV server  130   a , and edge server  170   b  and associated SDV server  130   b . Regional network  120   b  may be configured similarly to regional network  120   a , with interconnectivity to gateway server  160 , VoD server  150   c , and edge server  170   c  with associated SDV server  130   c.    
     SDV, which may be multicast as discussed above, provides content to users who desire the content at the same time, thereby providing linear television. SDV system  130  may maintain and transmit a listing of content available to user device  190 , and the required tuning information to access the content. In the event that end user device  190  requests content that is not presently being transmitted, end user device  190  may signal representative SDV system  130 , requesting the specific content. SDV system  130  may interface edge server  170  to identify the requested channel frequency. SDV system  130  may configure an available frequency on which to deliver the requested content to the requesting end user device  190 , and may transport the content using that frequency. 
     VoD, which may be unicast as discussed above, provides content non-linearly to a single end user device  190 . When end user device  190  requests VoD content, VoD system  150  locates that specific content and negotiates parameters for the delivery of that specific content to the requesting end user device  190 . 
     A configuration file for an end user device  190  may be delivered in accordance with an applicable protocol or specification. The configuration file may describe, among other things, a specific output channel lineup mapping for an input channel source and tuner frequency assignment. The configuration file may thereby indicate, such as through the use of in band and out of band messaging data, the desired conversion of input channel map information to the output channel lineup. The desired conversion may indicate the delivery frequency and/or location in a delivered data stream of the output channel lineup for VoD content and SDV channels, for example. 
     The channel mapping may, for example, indicate the Electronic Industries Association (EIA) output channel correspondent to a particular source identification (ID), such as VoD system  150  or SDV system  130 . 
     Additionally, an auxiliary output channel map may be used to map auxiliary input identification(s) to an EIA channel number. Such auxiliary input identifications may also include, for example, VoD system  150  and/or SDV system  130 . 
     Referring now to  FIG.  2   , there is shown a flow diagram of an example content delivery method  200 . As illustrated, the method of content delivery may include recording requested content on an nDVR. The method may include receiving a request for content at step  210 , such as from a user via a user device. Available bandwidth may be monitored, or specifically checked, at step  220  for delivery of the requested content. If the necessary bandwidth for delivery is available, the requested content may be delivered at step  260 , such as through the use of VoD or SDV allocated bandwidth. If the necessary bandwidth for delivery of the requested content is not available over the requested delivery path, a message may be sent, such as from a provider, for example, providing the requester the option of recording the content, such as on a nDVR, for later delivery over the requested or an alternate delivery path, or for contemporaneous delivery over an alternate delivery path, at step  230 . The message may be sent from a hardware or software device interoperably connected to a content delivery network, and to a user device, for prompting a user to respond to a message. 
     The message of step  230  may state that the delivery system is under heavy load, and/or may provide a time expectation of when the load is expected to subside. Such heavy loads are typically transient, and thus may last only a very short time, such as on the order of a minute to a few minutes. Of course, method  200  may be carried out without providing a message at step  230  and by instead carrying out a proposed alternate delivery solution without informing the requesting user, for example. 
     If the content is to be recorded on the nDVR, such as pursuant to a response to a message, a request may be sent to the nDVR to record the content for an identified user or an associated device at step  240 . Further, available bandwidth may be monitored at step  250 , continually or discretely at intervals, such as every minute, for example, and if available bandwidth becomes sufficient along the requested delivery path or along an alternate delivery path for delivery of the requested content, the requested content may be delivered at step  260 . 
     For example, a SDV allocated channel that is unavailable due to bandwidth constriction within the SDV allocated bandwidth may be delivered by utilizing the method  200  by switching, such as by a device at the central processing office, of the requested SDV channel from the SDV bandwidth allocation to the VoD bandwidth allocation. A switch to the VoD allocated bandwidth may comprise switching to the bandwidth allotted to the VoD source identification in the channel mapping, as discussed hereinabove, for example. The SDV channel may be recorded by an nDVR and, once the recording starts, the nDVR may execute a switch to the VoD allocated bandwidth to deliver the requested SDV channel. For example, at step  230 , the message sent to a user may ask whether an alternative delivery is acceptable. At step  240  the alternate bandwidth may be reserved, and the method provides for the delivery of the SDV channel via the VOD allocated bandwidth in this example. At step  250 , the alternate bandwidth, such as the VOD allocated bandwidth, may be monitored for delivery of the requested content, such as the SDV channel, which is delivered at step  260 . 
     In method  200 , the nDVR, for example, may operate as a switch that switches delivery from a constricted bandwidth, such as the SDV allocated bandwidth, to a non-constricted bandwidth, such as the VoD allocated bandwidth. Additional or other switches between other delivery paths may be similarly employed in method  200 . For example switching may occur between wired or wireless television delivery paths, mobile networks, data networks, and packet switched networks such as the internet. Switches for switching content from the constricted bandwidth to available bandwidth may comprise hardware and/or software switches, and may include digital recorders, central facilities, servers, and the like. 
     By way of more particular example, a user may request a SDV channel, and it may be determined that there is insufficient bandwidth to play the requested SDV channel. A message may be sent to the user device of the requesting user to display a message, such as “Record in the Network for Future viewing.” If the user chooses to record for future viewing, a request may be sent to an nDVR, identifying the user or device and the SDV channel requested, such that the nDVR can record the SDV channel. The nDVR may then record the content for the identified requester. In this example, if the bandwidth allocated for nDVR is managed independently of the bandwidth for SDV, the nDVR may give the user the option to start watching the requested content immediately, thereby avoiding the bandwidth limitation in the SDV. 
     Referring now to  FIG.  3   , there is shown a flow diagram of another content delivery method  300 . As illustrated, if bandwidth is not available for delivery of requested content at step  310 , a request for content may be tracked at step  320 , and may be sent, such as in a message form, to an edge resource manager (ERM) at step  330 . The request may initiate the system to track the availability of bandwidth, and may include a request to be informed when sufficient bandwidth becomes available, at step  340 . The ERM may, for example, send a “bandwidth availability” message to the VoD systems at step  350 . The VoD system may responsively reserve available bandwidth at step  360 . Alternatively, bandwidth may not be reserved. If bandwidth is reserved, a release or allocation of the bandwidth may be configured. This reservation of available bandwidth may include an elapsed time timer, for example, that monitors the time that has elapsed since the reservation of the bandwidth. In the event that no use of the bandwidth has occurred during a predetermined amount of elapsed time, the reserved bandwidth may be released. Of course, other metrics may be used to cause the release of bandwidth, including but not limited to, overall bandwidth usage levels and subsequent requests by the content requester. In the case bandwidth is not reserved, the VoD may operate on a first come first served basis. In such a configuration, a lower threshold may be used to determine that bandwidth availability exists. For example, if the requested content is 3.75 Mbps and the total capacity of the VoD system is 37 Mbs, bandwidth may be assessed as available at any level of less than 30 Mbps. 
     Once bandwidth is available, the ERM may send a message to the requesting user device, or an associated device, to display a banner, for example, indicating that the requested content can then be viewed, at step  370 . When the requester chooses to play the requested content, it may be played, such as by a single click without having to navigate a VoD menu, at step  380 . 
     The methods described in  FIGS.  2 ,  3   , and other disclosed methods may be implemented via software stored on computer readable media that may be executed by a processor. Further, the steps and/or actions described in connection with the aspects disclosed herein may be embodied directly in hardware, in a software module executed by the processor, or in a combination of the two. A software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium may be coupled to the processor, such that the processor can read information from the storage medium. Alternatively, the storage medium may be integral to the processor. Further, in some aspects, the processor and the storage medium may reside in an ASIC. Alternatively, the processor and the storage medium may reside as discrete components. Additionally, in some aspects, the steps and/or actions of a method or algorithm may reside as one or any combination or set of instructions stored on a machine readable storage medium and/or a computer readable storage medium. 
     Although the disclosure has been described and pictured in an exemplary form with a certain degree of particularity, it is understood that the present disclosure has been made by way of example, and that numerous changes in the details of construction and combination and arrangement of parts and steps may be made without departing from the spirit and scope of the disclosure as set forth and of the claims hereinafter.