US20100251313A1 - Bi-directional transfer of media content assets in a content delivery network - Google Patents

Bi-directional transfer of media content assets in a content delivery network Download PDF

Info

Publication number
US20100251313A1
US20100251313A1 US12/751,231 US75123110A US2010251313A1 US 20100251313 A1 US20100251313 A1 US 20100251313A1 US 75123110 A US75123110 A US 75123110A US 2010251313 A1 US2010251313 A1 US 2010251313A1
Authority
US
United States
Prior art keywords
media content
content
video
asset
demand
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US12/751,231
Inventor
Weidong Mao
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Comcast Cable Communications LLC
Original Assignee
Comcast Cable Communications LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Comcast Cable Communications LLC filed Critical Comcast Cable Communications LLC
Priority to US12/751,231 priority Critical patent/US20100251313A1/en
Assigned to COMCAST CABLE COMMUNICATIONS, LLC reassignment COMCAST CABLE COMMUNICATIONS, LLC ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: MAO, WEIDONG
Publication of US20100251313A1 publication Critical patent/US20100251313A1/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/21Server components or server architectures
    • H04N21/218Source of audio or video content, e.g. local disk arrays
    • H04N21/21815Source of audio or video content, e.g. local disk arrays comprising local storage units
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/21Server components or server architectures
    • H04N21/222Secondary servers, e.g. proxy server, cable television Head-end
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/61Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1095Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/56Provisioning of proxy services
    • H04L67/568Storing data temporarily at an intermediate stage, e.g. caching
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/56Provisioning of proxy services
    • H04L67/568Storing data temporarily at an intermediate stage, e.g. caching
    • H04L67/5681Pre-fetching or pre-delivering data based on network characteristics
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/56Provisioning of proxy services
    • H04L67/568Storing data temporarily at an intermediate stage, e.g. caching
    • H04L67/5682Policies or rules for updating, deleting or replacing the stored data
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/231Content storage operation, e.g. caching movies for short term storage, replicating data over plural servers, prioritizing data for deletion
    • H04N21/23103Content storage operation, e.g. caching movies for short term storage, replicating data over plural servers, prioritizing data for deletion using load balancing strategies, e.g. by placing or distributing content on different disks, different memories or different servers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/231Content storage operation, e.g. caching movies for short term storage, replicating data over plural servers, prioritizing data for deletion
    • H04N21/23106Content storage operation, e.g. caching movies for short term storage, replicating data over plural servers, prioritizing data for deletion involving caching operations
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/231Content storage operation, e.g. caching movies for short term storage, replicating data over plural servers, prioritizing data for deletion
    • H04N21/2312Data placement on disk arrays
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/23614Multiplexing of additional data and video streams
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/2387Stream processing in response to a playback request from an end-user, e.g. for trick-play
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/258Client or end-user data management, e.g. managing client capabilities, user preferences or demographics, processing of multiple end-users preferences to derive collaborative data
    • H04N21/25808Management of client data
    • H04N21/25841Management of client data involving the geographical location of the client
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47End-user applications
    • H04N21/478Supplemental services, e.g. displaying phone caller identification, shopping application
    • H04N21/4788Supplemental services, e.g. displaying phone caller identification, shopping application communicating with other users, e.g. chatting
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/632Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing using a connection between clients on a wide area network, e.g. setting up a peer-to-peer communication via Internet for retrieving video segments from the hard-disk of other client devices

Definitions

  • VOD video-on-demand
  • Alternative video delivery methods such as movie download or video streaming via the Internet are also becoming more practical and feasible as service providers deploy either DOCSIS 3.0 wideband or fiber-to-the-home technologies.
  • VOD content is typically encoded in MPEG-2 format and replicated/pushed along with metadata via a satellite or Internet Protocol (IP) backbone to local VOD systems.
  • IP Internet Protocol
  • the broadband Internet is typically used as the content distribution and streaming platform.
  • content aggregators and integrators license and publish movies and television shows via Internet websites.
  • Client devices such as set-top boxes may be able to access media content via the Internet using a broadband pipe such as via a cable modem, DSL connection, or fiber-to-the-home (FTTH) network.
  • FTH fiber-to-the-home
  • VOD architecture provides an expansive amount of content
  • VOD offerings to devices other than conventional set-top boxes, such as personal computers and portable media players.
  • Such a new architecture may be capable of handling larger non-VOD content libraries as well.
  • An integrated video-on-demand (VOD) content library platform may be provided that supports virtually an unlimited amount of media content assets such as movies, television shows, Internet video, and user-generated content.
  • This approach may combine features of existing managed network approaches with emerging over-the-top approaches, by introducing a content delivery network that has a large content library, typically made up of smaller libraries interconnected together and with content providers and local head ends via a high-speed backbone, such as an Internet Protocol (IP) backbone, and/or via regional networks.
  • IP Internet Protocol
  • the content delivery network may enable operators to cost-effectively provide a much larger amount of media content, such as VOD content, by serving at least some of the content from national and regional libraries instead of replicating all content to the local distribution systems (e.g., head end systems) as is conventionally done.
  • VOD content media content
  • the content delivery network may enable operators to cost-effectively provide a much larger amount of media content, such as VOD content, by serving at least some of the content from national and regional libraries instead of replicating all content to the local distribution systems (e.g., head end systems) as is conventionally done.
  • Intelligent caching may be used by the content delivery network and/or by the local systems, where the caching locations and caching timeframes for each piece of content may be based on such priority factors as the actual or expected popularity (global or local) of the content, the actual or expected usage (global or local) of the content, the quality of service (QoS) of the content, the data size of the content, storage and responsiveness expectations defined by service-level agreements (SLAs), the demographics of the expected audience for the content, and the identity of the provider or owner of the content.
  • SLAs service-level agreements
  • Such intelligent caching may be expected to reduce network bandwidth usage and enhance overall service performance by potentially reducing the amount of redundant storage and transfer that would ordinarily be needed as the amount of available content increases.
  • most content may be stored in the main content library. Then, depending upon content popularity and/or other factors, the content may be replicated and propagated ahead of time, or in response to a client request, to or near one or more of the local head end systems.
  • the local system serving that subscriber may begin immediately streaming the content if the content is already cached at the local system. If the content is not cached at the local system, then the local system may pull the content from the content library or elsewhere. The pulled content may thereafter continue to be cached at the local system for a period of time to serve expected future requests from other subscribers served by that local system, and then later removed if desired.
  • certain content such as trick files
  • a bi-directional transfer of content between local regions of the network may be provided for.
  • a first head end system may not only receive content downstream from the main network, but may also send content upstream through the network to another head end system requesting the content.
  • some aspects as described herein may be directed to systems, apparatuses, methods, and software for receiving from a first client device a first request for a media content asset; responsive to the first request, determining whether the media content asset is stored at a first location in a network; responsive to determining that the media content asset is not stored at the first location, fetching the media content asset from a second location in the network and storing the media content asset in a computer-readable medium at the first location; streaming to the first client device the media content asset stored at the first location; and responsive to a second request from a second client device, streaming to the second client device the media content asset stored at the first location.
  • Still further aspects are directed to systems, apparatuses, methods, and software for receiving a request for a first media content asset; determining whether the first media content asset is already stored; and responsive to determining that the first media content asset is not already stored, generating by a computer the first media content asset from a stored second media content asset.
  • Yet further aspects are directed to systems, apparatuses, methods, and software for receiving first media content and associated first metadata at a first video-on-demand system, the first video-on-demand system being configured to stream media content assets to a first plurality of client devices; storing, by the first video-on-demand system, a first media content asset in a first computer-readable medium; and sending, by the first video-on-demand system, the first metadata to a database, wherein the database is accessible by a second video-on-demand system configured to stream media content assets to a second plurality of client devices to which the first video-on-demand system is not configured to stream media content assets.
  • FIG. 1 is a functional block diagram of an illustrative content delivery network 100 and surrounding environment.
  • FIG. 2 is another illustrative functional block diagram of a portion of content delivery network 100 in conjunction with head ends and client devices.
  • FIG. 3 is a diagram of illustrative interactions between various elements of a content delivery network and its environment, when performing ingest of non-real-time media content assets.
  • FIG. 4 is a diagram of illustrative interactions between various elements of a content delivery network and its environment, when performing ingest of real-time media content assets.
  • FIG. 5 is a diagram of illustrative interactions between various elements of a content delivery network and its environment, when pre-positioning a media content asset already stored in a content library to a replicated location.
  • FIG. 6 is a diagram of illustrative interactions between various elements of a content delivery network and its environment, when streaming content to a client device in response to a request from the client device.
  • FIG. 7 is a diagram of illustrative interactions between various elements of a content delivery network and its environment, when a pre-stored trick file is requested to be streamed to a client device.
  • FIG. 8 is another diagram of illustrative interactions between various elements of a content delivery network and its environment, when a trick file that has not yet been created is requested to be streamed to a client device.
  • FIG. 9 is a functional block diagram of an example of how a content delivery network may be used to perform bi-directional local content sharing between head ends.
  • FIG. 10 shows illustrative interactions between various equipment when a local media content asset is shared between streaming servers of two different head ends.
  • FIG. 1 is a functional block diagram of an illustrative content delivery network 100 and surrounding environment.
  • content delivery network 100 includes a content library 101 , a caching gateway 102 , a content propagation manager (CPM) 103 , a content library service (CLS) 104 , a content ingest block 105 , and a real-time ingest block 106 , each being communicatively coupled to each other (bidirectionally or unidirectionally as desired) in the manner shown in FIG. 1 .
  • Content delivery network 100 in this example may be communicatively coupled to (again, bidirectionally or unidirectionally as desired) the following functional blocks: a content ingest manager 107 , a transcoder 108 , a derived content generator 109 , a real-time manager 110 , a rights management system (RMS) 111 , a content management system (CMS) 112 , a metadata distribution hub (MD H) 113 , an asset management system (AMS) 114 , one or more video-on-demand (VOD) backoffices 115 , one or more edge resource managers 116 , one or more streaming servers 117 , one or more edge quadrature amplitude modulation (QAM) units 118 , one or more staging servers 119 , one or more cable modem termination systems (CMTSs) 120 , a data warehouse server 121 , and a network management system 122 Together, VOD backoffices 115 , edge resource managers 116 , streaming servers 117 , edge QAMs
  • Content delivery network 100 may be any type of network, and may be a single network or a combination of multiple networks, such as a television distribution network, a telephone network, and/or the Internet. Physically, content delivery network 100 may be embodied as multiple computers communicatively coupled together in a wired and/or wireless manner. Content delivery network 100 may also be communicatively coupled to a plurality of end-user client devices 201 A-H ( FIG. 2 ) in a wired and/or wireless manner, such as via coaxial cable, optical fiber, hybrid-fiber-coaxial cable, and/or cellular data or telephone links. While content delivery network 100 is shown to encompass certain functional blocks and not other functional blocks, it is noted that this division may be functional rather than necessarily physical, and somewhat arbitrary.
  • content delivery network 100 may alternatively include others of the functions shown in FIG. 1 .
  • head ends 190 may be considered part of content delivery network 100 .
  • some of the functional blocks shown in FIG. 1 as part of content delivery network 100 may be considered outside of content delivery network 100 .
  • any of the above-mentioned functional blocks 101 - 122 may each be implemented, for example, as a computer or as a system or device that includes a computer.
  • Non-limiting examples of a computer include one or more personal computers (e.g., desktop or laptop), servers, smart phones, personal digital assistants (PDAs), television set top boxes, and/or a system of these in any combination or subcombination.
  • a given computer may be physically located completely in one location or may be distributed amongst a plurality of locations (i.e., may implement distributive computing).
  • a computer may be or include a general-purpose computer and/or a dedicated computer configured to perform only certain limited functions.
  • a computer typically includes hardware that may execute software and/or be configured in hardware to perform specific functions.
  • the software may be stored on a computer-readable medium in the form of computer-readable instructions.
  • a computer may read those computer-readable instructions, and in response perform various steps as defined by those computer-readable instructions.
  • any functions attributed to any of functional blocks 101 - 122 as described herein may be implemented, for example, by reading and executing such computer-readable instructions for performing those functions, and/or by any hardware subsystem (e.g., a processor) from which the computer is composed.
  • computer-readable medium includes not only a single physical medium or single type of medium, but also a combination of one or more physical media and/or types of media. Examples of a computer-readable medium include, but are not limited to, one or more memories, hard drives, optical discs (such as CDs or DVDs), magnetic discs, and magnetic tape drives.
  • Such a computer-readable medium may store computer-readable instructions (e.g., software) and/or computer-readable data (i.e., information that may or may not be executable).
  • a computer-readable medium (such as memory) may be included in any one or more of functional blocks 101 - 122 and may store computer-executable instructions and/or data used by any of those blocks 101 - 122 .
  • such a computer-readable medium storing the data and/or software may be physically separate from, yet accessible by, any of blocks 101 - 122 .
  • content delivery network 100 is configured to receive a plurality of media content assets, store the media content assets in various distributed locations such as content library 101 , one or more caching gateways 102 , and/or one or more head ends 190 such as one or more streaming servers 117 .
  • Content delivery network 100 is further configured to forward selected ones of the media content assets to end users via edge QAMs 118 .
  • media content assets may be streamed to client devices 201 by other additional or alternative means, such as over the Internet or over a cellular data network.
  • QAMs 118 may be replaced or augmented with other devices appropriate for providing the requested media content assets to client devices 201 .
  • Each media content asset may be stored at a single location within content delivery network 100 and/or head ends 190 , or replicated among multiple different locations within content delivery network 100 and/or head ends 190 .
  • a “media content asset” is any unit of media content that includes audio and/or video content.
  • video content asset is a media content asset that includes video content and may optionally also include audio content.
  • audio content asset is a media content asset that includes audio content and may optionally also include video content. Examples of a media content asset includes, without limitation, movies, television programs, news programs, advertisements, video clips, audio (e.g., radio) programs, audio clips, and trick files.
  • Media content assets may include live content (e.g., a live sports game) and/or pre-recorded content, and may include VOD content or pre-scheduled broadcast content.
  • a media content asset may also be associated with or include metadata that is descriptive of the media content asset and/or the content therein.
  • metadata may include or otherwise indicate a description of the content in the media content assets, a date or date range of the content, a time length of the content, a data size of the content, a format of the content, a bit rate of the content, etc.
  • one or more content providers provide media content assets in the form of files (typically for non-real-time content) and/or streams (typically for real-time content), along with any associated content metadata to transcoder 108 , which may transcode the incoming content to a target format, such as by transcoding the content to different CODEC standards and resolutions.
  • Derived content generator 109 generates trick files and other types of derived content from the original content, such as fast-forward and rewind trick files, movie trailers, re-formatted content, and advertising-spliced content.
  • Content ingest manager 107 and content ingest block 105 handle the receipt and ingest of the non-real-time content into content delivery network 100 , including managing ingest provisioning and life cycle and negotiating with CPM 103 for storage locations within content library 101 .
  • Real-time manager 110 and real-time ingest block 106 have a similar function as content ingest manager 107 and content ingest block 105 , except that these functions are performed for incoming streamed real-time content.
  • real-time manager 110 assigns multicast addresses and ports for real-time content distribution.
  • the encoded video program of a real-time media content asset may be sent via, e.g., IP multicast, and real-time manager 110 may direct real-time ingest block 106 to join the corresponding multicast and record the encoded stream based on the start and end times.
  • the resulting files may be stored in content library 101 , caching gateways 102 , and/or streaming servers 117 as desired.
  • Client devices 201 may request session and streaming of a real-time media content asset during and/or after the real-time ingest of that particular asset into content delivery network 100 , and may further perform certain trick modes on real-time content assets as appropriate, such as rewind and pause.
  • MDH 113 interfaces with content delivery network 100 , and the metadata and status for stored media content assets may be reported to MDH 113 so as to make the assets available for applications such as for queries by, and storage to, a unified database 901 ( FIG. 9 ), and for asset status and verification.
  • CMS 112 publishes the asset metadata to AMS 114 , such as via a CableLabs ADI interface.
  • the asset metadata of the ADI package is sent to AMS 114 while the content files are ingested into content delivery network 100 .
  • CMS 112 and RMS 111 may support both VOD content metadata (such as using CableLabs ADI) and Internet video metadata (such as using Media Really Simple Syndication, or RSS) formats.
  • the content metadata is published to the Regional Asset Management Systems via the CableLabs ADI interface. Only the metadata is sent via this interface while the content files are ingested into the CDN.
  • RMS 111 manages the licensing rights of real-time media content assets, including enabling and disabling based on licensing rights whether each real-time media content asset may be real-time ingested, determining licensing start and end times of real-time media content assets, and controlling certain business rules such as disabling fast forward trick play for real-time media content assets.
  • Data warehouse server 121 archives content usage statistics periodically received from content delivery network 100 and/or VOD backoffices 115 .
  • Network management system 122 provides a network management interface for configuration, monitoring, fault detection, and alarm functions.
  • Content library 101 includes one or more physical computer-readable media for storing the media content assets ingested by content ingest 105 and real-time ingest 106 , along with one or more computers for managing the input, output, and internal data management of content library 101 . While content library 101 is shown as a single functional block in FIG. 1 , in reality the various computer-readable media may include multiple computer-readable media and computers distributed over a wide geographical area, especially where content delivery network 100 itself services client devices 201 that are geographically diverse. The computer-readable media and computers may be interconnected via, e.g., an IP network. Thus, content library 101 may actually be a collection of multiple libraries that together are functionally treated as one logical library. In some embodiments, content library 101 may have a multi-tiered hierarchical topology of the various computer-readable media.
  • Caching gateways 102 include one or more physical computer-readable media for storing at least a subset of the media content assets stored in content library 101 , along with one or more computers for managing the input, output, and internal data management of caching gateways 102 .
  • media content assets may be replicated into one or more of caching gateways 102 as desired.
  • any media content assets stored in caching gateways 102 may also be stored somewhere in content library 101 .
  • the various computer-readable media of caching gateways 102 may also be distributed over a wide geographical area. While caching gateways 102 and content library 101 are shown as separate functional blocks, physically they may share some or all of the same computer-readable media and/or computers. Alternatively, caching gateways 102 and content library 101 may be embodied as physically separate systems.
  • CPM 103 may contain multiple content library 101 nodes coupled via national and/or regional networks, such as IP networks.
  • CPM 103 is responsible for replicating and/or moving the media content assets through various storage locations of content library 110 and/or caching gateways 102 in a dynamic manner based on content popularity, content usage, and/or other factors.
  • CPM 103 is further responsible for deciding and directing which particular ones of the streaming servers 117 will stream particular content to client devices 201 . This decision may be based on, for example, the current or expected load of the various streaming servers 117 .
  • the locations for all media content assets within content delivery network 100 are maintained and updated by the CLS 104 .
  • the content Upon a session setup request from a client device 201 , if the requested content is already pre-positioned or cached at a streaming server 117 , the content will be streamed from streaming server 117 to the requesting client device 117 . If the content is not available at the streaming server 117 , head end 190 will query CLS 104 for the locations of the requested media content asset within content library 101 and/or caching gateways 102 in order to fetch the media content asset and stream it to the requesting client device 201 .
  • content ingest block 105 and real-time ingest block 106 report the status and location of the media content asset to CLS 104 . Then, when the location is requested by head end 190 , CPM 103 fetches the reported location from CLS 104 . Where a media content asset is to be later replicated or moved, CPM 103 is responsible for updating CLS 104 dynamically on the new media content asset location and/or status. Thus, in general CPM 103 is responsible for deciding where media content assets are to be stored, and CLS 104 is responsive to keeping track of those locations.
  • multiple head ends 190 may be distributed geographically to serve the various client devices 201 , and may each contain the functional blocks as shown in FIG. 1 , which may operate as follows. Also, as shown by way of example in FIG. 2 , each head end 190 may be coupled to, and serve, only a subset of the total set of client devices 201 . Likewise, each streaming server 117 within a respective headend may be coupled to, and serve, only that respective subset of client devices 201 . Thus, content to be delivered to a given client device 201 is forwarded to and provided by one of the streaming servers 117 that is coupled to the target client device 201 .
  • VOD backoffice 115 for each of head ends 190 may manage the receipt and fulfillment of VOD requests from those client devices 201 that are served by the respective head end 190 , including session setup and stream control management of VOD media content assets.
  • VOD backoffice 115 may receive asset title and content metadata from CMS 112 through AMS 114 , and pass business rules such as trick mode restriction to streaming server 117 upon session setup time, assist with allocating edge QAM 118 resources for VOD sessions, and assist with advertisement insertion into the stream.
  • that VOD backoffice 115 may obtain the requested VOD media content asset from content delivery network 100 (if not already stored in head end 190 ) and cause the asset to be streamed in well-known ways to the requesting client device 201 via streaming server 117 and edge QAM 118 , and/or CMTS 120 (which provides IP-based content streaming to client devices 201 ).
  • Streaming server 117 may also include one or more computer-readable media for caching one or more of the media content assets, especially those that have been recently streamed by that streaming server 117 .
  • Staging server 119 is used for Internet Protocol (IP) based streaming services for client data devices such as personal computers and smart phones.
  • Staging server 119 supports various content formats and protocols, such as hypertext transfer protocol (HTTP) progressive download, FLASH download, and WINDOWS media streaming.
  • Staging server 119 may also use the standard HTTP-based content locate and streaming protocol for pulling content from content delivery network 100 .
  • staging server 119 utilizes caching algorithms for caching library content from content delivery network 100 .
  • Edge resource managers 116 manage bandwidth and program resources on QAMs 118 .
  • Edge resource managers 116 may support session requests from multiple session managers. If an edge device such as edge QAM 118 or CMTS 120 announces a failure to one of the edge resource managers 116 , that edge resource manager 116 may be configured to not make any session related decisions. That edge resource manager 116 may instead forward a notification to the VOD system to determine how to resolve the issue.
  • the media content assets may be permanently or temporarily stored in content delivery network 100 and/or at one or more head ends 190 at various distributed locations, including content library 101 , one or more caching gateways 102 , and/or one or more streaming servers 117 .
  • the actual locations at which each media content asset is stored may depend upon one or more factors, such as how popular the media content asset is to the end users, how popular the media content asset is expected to be, how often the media content assets is requested by one or more of the end users, and/or which end users have requested or are expected to request the media content assets.
  • the locations at which the media content assets are stored may change dynamically over time in responses to changes in these and/or other factors.
  • FIG. 2 shows another illustrative functional block diagram of a portion of content delivery network 100 in conjunction with head ends 190 A-D and client devices 201 A-H.
  • caching gateways 102 are shown as multiple caching gateways 102 A-E.
  • the number of caching gateways shown here is merely an example; there may be a fewer or greater number of caching gateways.
  • caching gateways 102 A-E are shown as being inter-coupled in a multi-tiered hierarchical topology.
  • a first tier of caching gateways 102 A, 102 B and a second tier of caching gateways 102 C-E are provided.
  • a third tier in the hierarchy may be considered to be head ends 190 A-D.
  • Such a hierarchical topology may make certain organizations of media content assets easier. For example, a tier that is more local to a head end 190 may store copies of those content media assets that are the most requested or most popular (e.g., top ten) for client devices 201 of that head end 190 , and a tier that is less local to that head end 190 may store copies of those content media assets that are less requested or less popular (e.g., top twenty) for client devices 201 of that head end.
  • each tier may have its own network bandwidth resource management capability. For instance, each tier may be able to independently manage bit rates, compression, statistical multiplexing, and user limits.
  • any topology of caching gateways and head ends may be used.
  • content library 101 may also have a multi-tiered hierarchical topology.
  • Example operation scenarios of content delivery network 100 will now be described with reference to FIGS. 3-8 .
  • FIG. 3 is a diagram of illustrative interactions between various elements of content delivery network 100 and its environment, when performing ingest of non-real-time media content assets.
  • metadata associated with a certain media content asset is delivered from a content source to RMS 111 and/or CMS 112 .
  • RMS 111 and/or CMS 112 generate a unique identifier for the media content asset, and provision the media content asset with content ingest manager 107 .
  • Content ingest manager 107 then instructs content ingest block 105 to begin content ingest.
  • Content ingest block 105 queries CPM 103 , and in response CPM 103 determines and returns to content ingest block 105 the target location(s) at which the media content asset will be stored in content library 101 .
  • content ingest manager 107 periodically provides the content transfer status to RMS 111 and/or CMS 112 .
  • Next content ingest block 105 retrieves the media content asset file from the content provider, and also interfaces with transcoder 108 and derived content generator 109 as needed, for transcoding the media content asset file and generating auxiliary trick files.
  • the retrieved files and any generated trick files are saved to content library 101 at the previously determined location(s).
  • Content ingest block 105 reports to CLS 104 upon completion of ingesting the content, and also to content ingest manager 107 about content transfer status. Then, content ingest manager 107 reports, or responds to a request from, RMS 111 and/or CMS 112 regarding content status.
  • FIG. 4 is a diagram of illustrative interactions between various elements of content delivery network 100 and its environment, when performing ingest of real-time media content assets. The process is similar, with the main difference being that real-time manager 110 is used in place of content ingest manager 107 , and real-time ingest block 106 is used in place of content ingest block 105 .
  • program guide metadata including a real-time program schedule is delivered from a content source to RMS 111 and/or CMS 112 .
  • RMS 111 and/or CMS 112 generate a unique identifier for the real-time media content asset, and provision the media content asset with content ingest manager 107 .
  • Real-time manager 110 then instructs content real-time ingest block 106 to begin stream ingest at times defined by the real-time program schedule.
  • Real-time ingest block 106 queries CPM 103 , and in response CPM 103 determines and returns to content ingest block 105 the target location(s) at which the real-time media content asset will be stored in content library 101 .
  • content ingest manager 107 periodically provides the content transfer status to RMS 111 and/or CMS 112 .
  • real-time ingest block 106 retrieves the media content asset stream from the content provider such as via IP multicast, and also interfaces with transcoder 108 and derived content generator 109 as needed, for transcoding the media content asset file and generating auxiliary trick files.
  • the retrieved files and any generated trick files are saved to content library 101 at the previously determined location(s).
  • Real-time ingest block 106 reports to CLS 104 upon completion of ingesting the stream, and also to real-time manager 110 about content transfer status. Then, real-time manager 110 reports, or responds to a request from, RMS 111 and/or CMS 112 regarding content status.
  • FIG. 5 is a diagram of illustrative interactions between various elements of content delivery network 100 and its environment, when pre-positioning an entire media content asset, or a portion thereof, already stored in content library 101 to a replicated location.
  • This pre-positioning may be performed regardless of any client device 201 request for the media content asset, and may be performed so as to replicate the media content asset to a location that is closer—geographically or logically—to client devices 201 that are expected to request the media content asset.
  • a media content asset (or a portion thereof) is pre-positioned from content library 110 to a streaming server 117 .
  • this process could alternatively be used to pre-position the media content asset from and to any other locations, such as caching gateway 102 or elsewhere.
  • the media content asset is a VOD asset, however any type of media content asset may be used.
  • New content is provisioned and ingested into content distribution network 100 by RMS 111 and/or CMS 112 , which publish media content asset metadata to AMS 114 .
  • AMS 114 publishes the metadata to some or all of the VOD backoffices 115 .
  • the VOD backoffice 115 associated with the target streaming server 117 determines that pre-positioning at the streaming server 117 is desired, and initiates a content transfer command to streaming server 117 .
  • streaming server 117 sends a content locate and transfer request to CLS 104 .
  • CLS 103 redirects streaming server 117 to the actual location of the desired media content asset in content library 101 .
  • the located media content asset (or a portion thereof) from content library 101 is replicated to streaming server 117 .
  • pre-positioning of a media content asset by replication occurred in response to a request from VOD backoffice 115 .
  • CPM 103 may alternatively initiate pre-positioning.
  • the media content asset was pre-positioned to streaming server 117
  • such pre-positioning may be made to any computer-readable medium in content delivery network 100 and/or outside of content delivery network 100 , such as in head end 190 .
  • a media content asset (or a portion thereof) may be pre-positioned to one or more caching gateways 102 .
  • the particular location(s) to which a media content asset is pre-positioned, as well as whether or not such pre-positioning should occur in the first place may be determined responsive to a determination that the media content asset is popular or is expected to be popular. This determination may be made by, e.g., CPM 103 and/or VOD backoffice 115 . And, the particular location(s) to which the media content asset is pre-positioned may be determined based on which geographical locations served by content data network 100 and/or head ends 190 the popularity is expected to occur.
  • a newly-released movie may be expected to be popular throughout the country, and so the movie (or a portion thereof) may be pre-positioned to all or most caching gateways 102 and/or VOD backoffices 115 .
  • a media content asset, or portion thereof, of particular interest to only a certain geographic region may be pre-positioned only to one or more caching gateways 102 and/or VOD backoffices 115 that serve that geographic region.
  • a media content asset may be pre-positioned prior to any or substantial requests for that media content asset by client devices 201
  • the media content asset (or portion thereof) may further be replicated to one or more additional locations based on actual experienced requests by client devices 201 for that media content asset.
  • the replicated copy of the media content asset may remain at that location for a predetermined period of time or until it is later determined that the popularity for that media content asset has dropped below a predetermined threshold, after which time the replicated copy may be deleted or moved to yet another location in the network.
  • Popularity of a media content asset may be determined in many ways, such as being based on a measured frequency of client device 201 requests for the media content asset, determining whether the media content asset has been requested by client devices 201 a sufficient number of times over a predetermined period of time, and/or based on historical or predicted future demand for the media content asset. Also, such determinations may be made on a global basis (i.e., across the entire network) and/or on a geographic regional basis, and may be made more than once over time to re-determine the popularity of the media content asset and re-replicate the entire media content asset or a portion thereof as appropriate based on the newly-determined popularity.
  • Trick files may be treated like any other type of media content asset, and thus may be pre-positioned and otherwise replicated in the same manner as any other type of media content asset. In some cases, it may be desirable to locate trick files in the same computer-readable media and/or otherwise a same node of the network as their associated program content files. In other cases, it may be desirable to locate trick files independently of the location of their associated program content if it is not expected that the trick file will be as popular as the program content itself.
  • FIG. 6 is a diagram of illustrative interactions between various elements of content delivery network 100 and its environment, when streaming content to a client device 201 in response to a request from the client device 201 .
  • the media content asset is a VOD asset; however any type of media content asset may be used.
  • the desired media content asset is streamed from a location in content library 101 , however the media content asset may be stored anywhere such as in caching gateway 102 or in streaming server 117 .
  • new content is provisioned and ingested into content distribution network 100 by RMS 111 and/or CMS 112 , which publish media content asset metadata to AMS 114 .
  • AMS 114 publishes the metadata to some or all of the VOD backoffices 115 .
  • One of the VOD backoffices 115 optimistically processes a session setup request from client device 201 , and in response to the request sends a session setup request to streaming server 117 .
  • streaming server 117 checks its local cache for the requested content. If the content is available at the local cache of streaming server 117 , then streaming server 117 will stream the content directly to the requesting client device 201 . If the requested content is not stored at the local cache of streaming server 117 , then streaming server 117 sends a content locate and transfer request to CLS 104 .
  • CLS 104 redirects streaming server 117 to the actual location in content library 101 (or elsewhere) where the requested media content asset is stored.
  • streaming server 117 performs content transfer of the media content asset from content library 101 , and streams the transferred content to the requesting client device 201 .
  • FIG. 7 is a diagram of illustrative interactions between various elements of content delivery network 100 and its environment, when a trick file or other type of derived content is requested to be streamed to a client device 201 .
  • the requested trick file is already generated and is stored in content library 101 .
  • the trick file may be stored elsewhere, such as in caching gateway 102 or streaming server 117 .
  • content from content library 101 is streamed by streaming server 117 to client device 201 .
  • client device 201 requests a trick play function, such as by selecting “fast forward” on the remote control.
  • client device 201 sends a trick play command from client device 201 to streaming server 117 .
  • streaming server 117 checks its local cache for the requested trick file. If the trick file is available at the local cache of streaming server 117 , then streaming server 117 will stream the trick file directly to the requesting client device 201 . If the requested trick file is not stored at the local cache of streaming server 117 , then streaming server 117 sends a content locate and transfer request to CLS 104 .
  • CLS 104 redirects streaming server 117 to the actual location in content library 101 (or elsewhere) where the requested trick file is stored.
  • streaming server 117 performs transfer of the trick file from content library 101 , and streams the transferred trick file to the requesting client device 201 .
  • client device 201 may request that the trick play end (in response to a user request to end the trick play function) and that the content stream resume to the normal content that was streaming prior to the trick play. This request is received by streaming server 117 , and in response streaming server 117 resumes normal content streaming to client device 201 .
  • FIG. 8 is another diagram of illustrative interactions between various elements of content delivery network 100 and its environment, when a trick file or other type of derived content is requested to be streamed to a client device 201 .
  • the requested trick file is not already generated and stored, and is to be generated in response to the client device 201 request, such as by deriving the trick file from an existing pre-stored or live media content asset.
  • a trick file is requested and generated in this example, such dynamic generation may be performed to generate any type of media content file, such as a VOD movie or television program.
  • Trick files and other types of derived media content assets may be derived from original, or parent, media content assets in several ways.
  • the derived content may be one or more portions of the original content, such as where the derived content is a trick file or movie trailer.
  • the derived trick file may be a video file having every nth (n>1) video frame of the original content, such as in a fast-forward trick file.
  • Another way to derive content is to generate a re-formatted version of the original content.
  • the derived content may be based on the original content except at a lower video and/or audio resolution, different video frame size, being transcoded using a different CODEC, or configured to be played at a different bit rate or frame rate.
  • This type of derivation may be desirable where, for example, the client device 201 that will be receiving the derived content is not compatible with the format of the original content.
  • Still another way to derive content from original content is to add content to the original content, such as by splicing in local or non-local advertising. This may be useful where, for example, it is desired to insert local advertising relevant to the geographical region in which client device 201 that will be receiving the derived content is located.
  • Any or all of these types of derivation may be used separately or together in any combination to provide a derived media content asset from an original live or stored media content asset.
  • content from content library 101 is streamed by streaming server 117 to client device 201 .
  • client device 201 requests a trick play function, such as by selecting “fast forward” on the remote control.
  • client device 201 sends a trick play command from client device 201 to streaming server 117 .
  • streaming server 117 checks its local cache for the requested trick file. If the trick file is available at the local cache of streaming server 117 , then streaming server 117 will stream the trick file directly to the requesting client device 201 . If the requested trick file is not stored at the local cache of streaming server 117 , then streaming server 117 sends a content locate and transfer request to CLS 104 .
  • CLS 104 determines that the trick file is not stored in content library 101 (or elsewhere), and sends a trick file locate response to streaming server 117 indicating this.
  • streaming server 117 sends a trick file transfer request to content library 101 , which in turn sends a trick file object request to real-time ingest 106 .
  • real-time ingest 106 sends a trick play generation request to derived content generator 109 , identifying the particular trick file that is needed, and streams the transferred trick file to the requesting client device 201 .
  • derived content generator 109 In response to the trick play generation request, derived content generator 109 generates the trick file, by deriving it from original live or store content such as described previously, and sends it (or an identifier that identifies the newly-generated trick file) back to real-time ingest 106 in the form of a trick play generation response.
  • the derived content is a trick file.
  • the derived content may be any type of derived content, such as a movie trailer, reformatted content, or content spliced with local advertising.
  • real-time ingest 106 sends a trick file object response indicating or including the trick file to content library 101 , and then in response to that content library sends a trick file transfer response to streaming server 117 .
  • Content library 101 may also store the newly-generated trick file in the event that it is requested again.
  • streaming server 117 begins streaming the trick file to client device 201 .
  • client device 201 may request that the trick play end (in response to a user request to end the trick play function) and that the content stream resume to the normal content that was streaming prior to the trick play. This request is received by streaming server 117 , and in response streaming server 117 resumes normal content streaming to client device 201 .
  • a command may be generated by client device 201 , with or without user intervention, that requests derived content (trick file or otherwise).
  • FIGS. 7 and 8 might be modified, for example, by the “trick play command” being replaced with the more generic “derived content request,” which may be sent automatically responsive to establishing a session.
  • client device 201 may request that a particular type of formatted content be provided, such as a particular coding format, video frame size, bit rate, video and/or audio resolution, etc.
  • the type of format requested may depend upon the type of device that client device 201 is. For example, where client device 201 is a smart phone with a cellular connection (directly or indirectly) to streaming server 117 , client device 201 may request a low-resolution and/or low bit-rate version of the content.
  • one of the locations at which a media content asset may be stored is at a streaming server 117 of a head end 190 . While this may occur through normal replication of the asset from content library 101 , it is also possible that the media content asset may be stored only locally at streaming server 117 and not centrally or globally at content library 101 . In such a case, the ingested media content asset may either be transferred from content library 101 to streaming server 117 without maintaining a copy at content library 101 , or the media content asset may be ingested and stored directly in streaming server 117 without first being stored in content library 101 . Any of these situations may be determined and controlled by, for example, content propagation manager 103 .
  • a media content asset may be stored at one or more streaming servers 117 but not necessarily at content library 101 when the media content asset is considered a local media content asset. That is, a media content asset that is expected to have interested viewers only in one or more local geographic regions, or an asset that is licensed only to be viewed in one or more local geographic regions rather than nationwide.
  • a local semi-professional baseball game may be recorded and provided to viewers in northern California. It would not be expected that many viewers anywhere other than northern California would be interested in viewing that game. Thus, it would not necessarily be efficient to store a media content asset showing that game in content library 101 or at head ends 190 or caching servers 102 not located in northern California. Therefore, it might be preferable in such a situation to normally store the asset only locally in one or more network locations in or near northern California.
  • FIG. 9 is a functional block diagram of an example of how content delivery network 100 may be used to perform such bi-directional local content sharing.
  • FIG. 9 shows that there are multiple content ingest managers 107 , real-time ingest managers 110 , content ingest blocks 105 , and real-time ingest blocks 106 that are part of content delivery network 100 , each serving a different geographic region.
  • FIG. 9 shows that a first geographic region is served by content ingest block CI 1 , real-time ingest block RTI 1 , content ingest manager CIM 1 , and real-time ingest manager RTM 1 .
  • a second geographic region is served by content ingest block CI 2 , real-time ingest block RTI 2 , content ingest manager CIM 2 , and real-time ingest manager RTM 2 .
  • a first head end 190 serving the first geographic region includes VOD backoffice VB 1 and streaming server SS 1
  • a second head end 190 serving the second geographic region includes VOD backoffice VB 2 and streaming server SS 2 .
  • Each geographic region also serves their own sets of client devices 201 , represented illustratively in FIG. 9 as client device C 1 for the first geographic region and as client device C 2 for the second geographic region.
  • the first and second geographic regions may be geographically separate from each other, such as being in different cities, counties, states, or countries. In terms of distance, the first and second geographic regions may be close to each other or far from each other, such as at least five hundred miles apart from each other.
  • a unified database (UDB) 901 for storing metadata describing media content assets is communicatively coupled (uni-directionally or bi-directionally) to equipment serving both the first and second geographic regions.
  • UDB 901 is coupled to content ingest manager CIM 1 , real-time ingest manager RTM 1 , content ingest manager CIM 2 , real-time ingest manager RTM 2 , VOD backoffice VB 1 , and VOD backoffice VB 2 . Any or all of these blocks are capable of querying and updating the data stored in UDB 901 .
  • the media content assets for which metadata is stored in UDB 901 may include local media content assets received by a content source that serves or is located in the first or second geographic region, such as Local Content Source 1 and Local Content Source 2 in FIG. 9 . These local media content assets are received into content ingest manager CIM 1 , real-time ingest manager RTM 1 , content ingest manager CIM 2 , or real-time ingest manager RTM 2 .
  • the local media content asset When a local media content asset is ingested at one of the geographic locations, the local media content asset (either real-time or non-real-time) may be stored at a head end 190 , such as the head end 190 serving that geographic location.
  • the media content asset may be stored at the streaming server or otherwise at a computer-readable medium to which the streaming server has access.
  • the metadata for that local media content asset may be passed on to UDB 901 . Because UDB 901 shares access to multiple geographic regions, such as the first and second geographic regions of FIG. 9 , the metadata for a media content asset may be available to any of those geographic regions even though the media content asset itself may only be stored at one of those geographic regions.
  • the local media content asset may be stored at streaming server SS 1 , and the metadata for that local media content asset may be stored in UDB 901 , such as via a path from content ingest block CI 1 to content ingest manager CIM 1 to UDB 901 .
  • the local media content asset is a VOD asset. If client device C 1 wishes to view the local media content asset, then VOD backoffice VB 1 can look up the metadata for that asset in UDB 901 and determine from CLS 104 that the asset is stored at streaming server SS 1 . The asset is then streamed to client device C 1 from streaming server SS 1 .
  • VOD backoffice VB 2 can also look up that same metadata for the asset in UDB 901 and determine from CLS 104 that the asset is stored at streaming server SS 1 .
  • the asset can then be transferred to streaming server SS 2 , such as via a caching gateway 102 .
  • Streaming server SS 2 then streams the asset to client device C 2 .
  • locally-stored content may be shared between different geographic regions of the network.
  • Metadata for a local media content asset is received by content ingest block CI 1 (for a non-real-time asset) or real-time ingest block RTI 1 (for a real-time asset).
  • the metadata is then forwarded by content ingest manager CIM 1 or real-time manager RTM 1 to UDB 901 for storage.
  • the actual local media content asset may be ingested by content ingest CI 1 or real-time ingest RTI 1 , and stored at streaming server SS 1 and/or a caching gateway 102 local to streaming server SS 1 .
  • the metadata for that local media content asset is replicated, in whole or in part, from UDB 901 to VOD backoffice VB 2 , either spontaneously or in response to a request for the local media content asset by VOD backoffice VB 2 , and some or all of the metadata for that asset may be passed on to client device C 2 , such as in the form of an electronic program guide indicating the local media content asset as an available choice.
  • client device C 2 such as in the form of an electronic program guide indicating the local media content asset as an available choice.
  • VOD backoffice VB 2 sends a content locate request to its local caching gateway 102 (not necessarily the same caching gateway at which the local media content is stored).
  • caching gateway 102 performs a content check with CLS 104 , which returns the location of the desired local media content asset to caching gateway 102 and then on to VOD backoffice VB 2 .
  • VOD backoffice VB 2 then sends a session setup response to client device C 2 and requests that the found local media content asset be replicated to streaming server SS 2 .
  • the transfer is performed, and streaming server SS 2 streams the local content media asset to client device C 2 .
  • client device C 2 desires a different format of the media content asset. In that case, either during or after session setup, client device C 2 may request that the media content asset be in a particular format. If the particular format is not already pre-stored, then similar to the FIG. 8 embodiments, derived content generator 109 may derive the requested version of the media content asset such that the derived version is streamed to client device C 2 .
  • any of the media content assets shared between video-on-demand systems may be live media content assets or non-live media content assets.

Abstract

Systems, apparatuses, methods, and software for using a network to efficiently distributing media content assets from a virtually unlimited content library and/or other storage to a plurality of client devices, as well as bi-directional local content sharing between head ends, and dynamic distribution and generation of media content assets within the network.

Description

    CROSS-REFERENCE TO RELATED APPLICATIONS
  • The present application claims priority to U.S. provisional patent application Ser. No. 61/165,197, filed Mar. 31, 2009, entitled “Building Large VOD Libraries With Next Generation On Demand Architecture,” hereby incorporated by reference as to its entirety.
  • BACKGROUND
  • Increasingly, cable operators are using video-on-demand (VOD) as a competitive advantage. Alternative video delivery methods such as movie download or video streaming via the Internet are also becoming more practical and feasible as service providers deploy either DOCSIS 3.0 wideband or fiber-to-the-home technologies.
  • Using the existing managed network approach that is adopted by various cable and telephone network operators, VOD content is typically encoded in MPEG-2 format and replicated/pushed along with metadata via a satellite or Internet Protocol (IP) backbone to local VOD systems. However, this approach does not necessarily scale well as the amount of available content increases. For instance, as the network grows and the amount of VOD content expands, it quickly becomes overly burdensome on the network to replicate all of the content out to local VOD systems.
  • In an alternative emerging “over-the-top” approach, the broadband Internet is typically used as the content distribution and streaming platform. In this approach, content aggregators and integrators license and publish movies and television shows via Internet websites. Client devices such as set-top boxes may be able to access media content via the Internet using a broadband pipe such as via a cable modem, DSL connection, or fiber-to-the-home (FTTH) network. Content distribution within the Internet is often driven by a “pull” model in response to client device requests.
  • However, there are several limitations of this over-the-top approach. For instance, it may be difficult to achieve high concurrency for high-definition (HD) VOD streaming, and this approach relies on public Internet infrastructure that imposes quality of service constraints, which may result in substantial network congestion. Moreover, there is typically a lack of end-to-end network resource management, as well as inconsistent premium content offerings due to lack of programming agreements with content providers. In addition, a pure over-the-top approach typically requires subscribers to purchase a separate client device appliance for viewing VOD assets.
  • There are significant opportunities for network operators to expand the current VOD architecture in order to support larger VOD content libraries that provide an expansive amount of content, and to provide the VOD offerings to devices other than conventional set-top boxes, such as personal computers and portable media players. Such a new architecture may be capable of handling larger non-VOD content libraries as well.
  • SUMMARY
  • An integrated video-on-demand (VOD) content library platform may be provided that supports virtually an unlimited amount of media content assets such as movies, television shows, Internet video, and user-generated content. This approach may combine features of existing managed network approaches with emerging over-the-top approaches, by introducing a content delivery network that has a large content library, typically made up of smaller libraries interconnected together and with content providers and local head ends via a high-speed backbone, such as an Internet Protocol (IP) backbone, and/or via regional networks.
  • The content delivery network may enable operators to cost-effectively provide a much larger amount of media content, such as VOD content, by serving at least some of the content from national and regional libraries instead of replicating all content to the local distribution systems (e.g., head end systems) as is conventionally done. Intelligent caching may be used by the content delivery network and/or by the local systems, where the caching locations and caching timeframes for each piece of content may be based on such priority factors as the actual or expected popularity (global or local) of the content, the actual or expected usage (global or local) of the content, the quality of service (QoS) of the content, the data size of the content, storage and responsiveness expectations defined by service-level agreements (SLAs), the demographics of the expected audience for the content, and the identity of the provider or owner of the content. Such intelligent caching may be expected to reduce network bandwidth usage and enhance overall service performance by potentially reducing the amount of redundant storage and transfer that would ordinarily be needed as the amount of available content increases.
  • As a default, most content may be stored in the main content library. Then, depending upon content popularity and/or other factors, the content may be replicated and propagated ahead of time, or in response to a client request, to or near one or more of the local head end systems. Upon a subscriber's request for content, the local system serving that subscriber may begin immediately streaming the content if the content is already cached at the local system. If the content is not cached at the local system, then the local system may pull the content from the content library or elsewhere. The pulled content may thereafter continue to be cached at the local system for a period of time to serve expected future requests from other subscribers served by that local system, and then later removed if desired.
  • In addition, certain content, such as trick files, may be generated dynamically as needed. In this way, it is not necessarily to pre-generate and pre-store all possible trick files for real-time and non-real-time content.
  • And, because not all content will necessarily be stored at all local regions of the network, a bi-directional transfer of content between local regions of the network may be provided for. For example, a first head end system may not only receive content downstream from the main network, but may also send content upstream through the network to another head end system requesting the content.
  • Thus, some aspects as described herein may be directed to systems, apparatuses, methods, and software for receiving from a first client device a first request for a media content asset; responsive to the first request, determining whether the media content asset is stored at a first location in a network; responsive to determining that the media content asset is not stored at the first location, fetching the media content asset from a second location in the network and storing the media content asset in a computer-readable medium at the first location; streaming to the first client device the media content asset stored at the first location; and responsive to a second request from a second client device, streaming to the second client device the media content asset stored at the first location.
  • Further aspects are directed to systems, apparatuses, methods, and software utilizing a network storing a plurality of media content assets, for determining a popularity of each of the media content assets; and for each of the media content assets, replicating the stored media content asset to a particular computer-readable medium in the network that depends upon the determined popularity for that media content asset.
  • Still further aspects are directed to systems, apparatuses, methods, and software for receiving a request for a first media content asset; determining whether the first media content asset is already stored; and responsive to determining that the first media content asset is not already stored, generating by a computer the first media content asset from a stored second media content asset.
  • Yet further aspects are directed to systems, apparatuses, methods, and software for receiving first media content and associated first metadata at a first video-on-demand system, the first video-on-demand system being configured to stream media content assets to a first plurality of client devices; storing, by the first video-on-demand system, a first media content asset in a first computer-readable medium; and sending, by the first video-on-demand system, the first metadata to a database, wherein the database is accessible by a second video-on-demand system configured to stream media content assets to a second plurality of client devices to which the first video-on-demand system is not configured to stream media content assets.
  • These and other aspects of the disclosure will be apparent upon consideration of the following detailed description.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • A more complete understanding of the present disclosure and the potential advantages of various aspects described herein may be acquired by referring to the following description in consideration of the accompanying drawings, in which like reference numbers indicate like features, and wherein:
  • FIG. 1 is a functional block diagram of an illustrative content delivery network 100 and surrounding environment.
  • FIG. 2 is another illustrative functional block diagram of a portion of content delivery network 100 in conjunction with head ends and client devices.
  • FIG. 3 is a diagram of illustrative interactions between various elements of a content delivery network and its environment, when performing ingest of non-real-time media content assets.
  • FIG. 4 is a diagram of illustrative interactions between various elements of a content delivery network and its environment, when performing ingest of real-time media content assets.
  • FIG. 5 is a diagram of illustrative interactions between various elements of a content delivery network and its environment, when pre-positioning a media content asset already stored in a content library to a replicated location.
  • FIG. 6 is a diagram of illustrative interactions between various elements of a content delivery network and its environment, when streaming content to a client device in response to a request from the client device.
  • FIG. 7 is a diagram of illustrative interactions between various elements of a content delivery network and its environment, when a pre-stored trick file is requested to be streamed to a client device.
  • FIG. 8 is another diagram of illustrative interactions between various elements of a content delivery network and its environment, when a trick file that has not yet been created is requested to be streamed to a client device.
  • FIG. 9 is a functional block diagram of an example of how a content delivery network may be used to perform bi-directional local content sharing between head ends.
  • FIG. 10 shows illustrative interactions between various equipment when a local media content asset is shared between streaming servers of two different head ends.
  • DETAILED DESCRIPTION
  • FIG. 1 is a functional block diagram of an illustrative content delivery network 100 and surrounding environment. In this example, content delivery network 100 includes a content library 101, a caching gateway 102, a content propagation manager (CPM) 103, a content library service (CLS) 104, a content ingest block 105, and a real-time ingest block 106, each being communicatively coupled to each other (bidirectionally or unidirectionally as desired) in the manner shown in FIG. 1.
  • Content delivery network 100 in this example may be communicatively coupled to (again, bidirectionally or unidirectionally as desired) the following functional blocks: a content ingest manager 107, a transcoder 108, a derived content generator 109, a real-time manager 110, a rights management system (RMS) 111, a content management system (CMS) 112, a metadata distribution hub (MD H) 113, an asset management system (AMS) 114, one or more video-on-demand (VOD) backoffices 115, one or more edge resource managers 116, one or more streaming servers 117, one or more edge quadrature amplitude modulation (QAM) units 118, one or more staging servers 119, one or more cable modem termination systems (CMTSs) 120, a data warehouse server 121, and a network management system 122 Together, VOD backoffices 115, edge resource managers 116, streaming servers 117, edge QAMs 118, staging servers 119, and CMTSs 120 may be considered as one or more head ends 190 for content delivery network 100.
  • Content delivery network 100 may be any type of network, and may be a single network or a combination of multiple networks, such as a television distribution network, a telephone network, and/or the Internet. Physically, content delivery network 100 may be embodied as multiple computers communicatively coupled together in a wired and/or wireless manner. Content delivery network 100 may also be communicatively coupled to a plurality of end-user client devices 201A-H (FIG. 2) in a wired and/or wireless manner, such as via coaxial cable, optical fiber, hybrid-fiber-coaxial cable, and/or cellular data or telephone links. While content delivery network 100 is shown to encompass certain functional blocks and not other functional blocks, it is noted that this division may be functional rather than necessarily physical, and somewhat arbitrary. Thus, content delivery network 100 may alternatively include others of the functions shown in FIG. 1. For instance, head ends 190 may be considered part of content delivery network 100. Alternatively or additionally, some of the functional blocks shown in FIG. 1 as part of content delivery network 100 may be considered outside of content delivery network 100.
  • Any of the above-mentioned functional blocks 101-122 may each be implemented, for example, as a computer or as a system or device that includes a computer. The term “computer” as referred to herein broadly refers to any electronic, electro-optical, and/or mechanical device, or system of multiple physically separate or physically joined such devices, that is able to process and manipulate information, such as in the form of data. Non-limiting examples of a computer include one or more personal computers (e.g., desktop or laptop), servers, smart phones, personal digital assistants (PDAs), television set top boxes, and/or a system of these in any combination or subcombination. In addition, a given computer may be physically located completely in one location or may be distributed amongst a plurality of locations (i.e., may implement distributive computing). A computer may be or include a general-purpose computer and/or a dedicated computer configured to perform only certain limited functions.
  • A computer typically includes hardware that may execute software and/or be configured in hardware to perform specific functions. The software may be stored on a computer-readable medium in the form of computer-readable instructions. A computer may read those computer-readable instructions, and in response perform various steps as defined by those computer-readable instructions. Thus, any functions attributed to any of functional blocks 101-122 as described herein may be implemented, for example, by reading and executing such computer-readable instructions for performing those functions, and/or by any hardware subsystem (e.g., a processor) from which the computer is composed.
  • The term “computer-readable medium” as used herein includes not only a single physical medium or single type of medium, but also a combination of one or more physical media and/or types of media. Examples of a computer-readable medium include, but are not limited to, one or more memories, hard drives, optical discs (such as CDs or DVDs), magnetic discs, and magnetic tape drives.
  • Such a computer-readable medium may store computer-readable instructions (e.g., software) and/or computer-readable data (i.e., information that may or may not be executable). In the present example, a computer-readable medium (such as memory) may be included in any one or more of functional blocks 101-122 and may store computer-executable instructions and/or data used by any of those blocks 101-122. Alternatively or additionally, such a computer-readable medium storing the data and/or software may be physically separate from, yet accessible by, any of blocks 101-122.
  • In general, content delivery network 100 is configured to receive a plurality of media content assets, store the media content assets in various distributed locations such as content library 101, one or more caching gateways 102, and/or one or more head ends 190 such as one or more streaming servers 117. Content delivery network 100 is further configured to forward selected ones of the media content assets to end users via edge QAMs 118. In other embodiments, media content assets may be streamed to client devices 201 by other additional or alternative means, such as over the Internet or over a cellular data network. In such a case, QAMs 118 may be replaced or augmented with other devices appropriate for providing the requested media content assets to client devices 201. Each media content asset may be stored at a single location within content delivery network 100 and/or head ends 190, or replicated among multiple different locations within content delivery network 100 and/or head ends 190.
  • A “media content asset” is any unit of media content that includes audio and/or video content. As used herein, the term, “video content asset,” is a media content asset that includes video content and may optionally also include audio content. Likewise, an “audio content asset” is a media content asset that includes audio content and may optionally also include video content. Examples of a media content asset includes, without limitation, movies, television programs, news programs, advertisements, video clips, audio (e.g., radio) programs, audio clips, and trick files. Media content assets may include live content (e.g., a live sports game) and/or pre-recorded content, and may include VOD content or pre-scheduled broadcast content. A media content asset may also be associated with or include metadata that is descriptive of the media content asset and/or the content therein. For example, such metadata may include or otherwise indicate a description of the content in the media content assets, a date or date range of the content, a time length of the content, a data size of the content, a format of the content, a bit rate of the content, etc.
  • Referring again to FIG. 1, one or more content providers provide media content assets in the form of files (typically for non-real-time content) and/or streams (typically for real-time content), along with any associated content metadata to transcoder 108, which may transcode the incoming content to a target format, such as by transcoding the content to different CODEC standards and resolutions. Derived content generator 109 generates trick files and other types of derived content from the original content, such as fast-forward and rewind trick files, movie trailers, re-formatted content, and advertising-spliced content. Content ingest manager 107 and content ingest block 105 handle the receipt and ingest of the non-real-time content into content delivery network 100, including managing ingest provisioning and life cycle and negotiating with CPM 103 for storage locations within content library 101.
  • Real-time manager 110 and real-time ingest block 106 have a similar function as content ingest manager 107 and content ingest block 105, except that these functions are performed for incoming streamed real-time content. In addition, real-time manager 110 assigns multicast addresses and ports for real-time content distribution. The encoded video program of a real-time media content asset may be sent via, e.g., IP multicast, and real-time manager 110 may direct real-time ingest block 106 to join the corresponding multicast and record the encoded stream based on the start and end times. The resulting files may be stored in content library 101, caching gateways 102, and/or streaming servers 117 as desired. Client devices 201 may request session and streaming of a real-time media content asset during and/or after the real-time ingest of that particular asset into content delivery network 100, and may further perform certain trick modes on real-time content assets as appropriate, such as rewind and pause.
  • MDH 113 interfaces with content delivery network 100, and the metadata and status for stored media content assets may be reported to MDH 113 so as to make the assets available for applications such as for queries by, and storage to, a unified database 901 (FIG. 9), and for asset status and verification.
  • AMS 114 manages VOD asset metadata, and CMS 112 publishes the asset metadata to AMS 114, such as via a CableLabs ADI interface. The asset metadata of the ADI package is sent to AMS 114 while the content files are ingested into content delivery network 100. Together, CMS 112 and RMS 111 may support both VOD content metadata (such as using CableLabs ADI) and Internet video metadata (such as using Media Really Simple Syndication, or RSS) formats.
  • Interface with Asset Management System: The content metadata is published to the Regional Asset Management Systems via the CableLabs ADI interface. Only the metadata is sent via this interface while the content files are ingested into the CDN.
  • RMS 111 manages the licensing rights of real-time media content assets, including enabling and disabling based on licensing rights whether each real-time media content asset may be real-time ingested, determining licensing start and end times of real-time media content assets, and controlling certain business rules such as disabling fast forward trick play for real-time media content assets.
  • Data warehouse server 121 archives content usage statistics periodically received from content delivery network 100 and/or VOD backoffices 115.
  • Network management system 122 provides a network management interface for configuration, monitoring, fault detection, and alarm functions.
  • Content library 101 includes one or more physical computer-readable media for storing the media content assets ingested by content ingest 105 and real-time ingest 106, along with one or more computers for managing the input, output, and internal data management of content library 101. While content library 101 is shown as a single functional block in FIG. 1, in reality the various computer-readable media may include multiple computer-readable media and computers distributed over a wide geographical area, especially where content delivery network 100 itself services client devices 201 that are geographically diverse. The computer-readable media and computers may be interconnected via, e.g., an IP network. Thus, content library 101 may actually be a collection of multiple libraries that together are functionally treated as one logical library. In some embodiments, content library 101 may have a multi-tiered hierarchical topology of the various computer-readable media.
  • Caching gateways 102 include one or more physical computer-readable media for storing at least a subset of the media content assets stored in content library 101, along with one or more computers for managing the input, output, and internal data management of caching gateways 102. In general, media content assets may be replicated into one or more of caching gateways 102 as desired. Thus, while not necessarily always the case, it may be expected that any media content assets stored in caching gateways 102 may also be stored somewhere in content library 101. As is the case with content library 101, the various computer-readable media of caching gateways 102 may also be distributed over a wide geographical area. While caching gateways 102 and content library 101 are shown as separate functional blocks, physically they may share some or all of the same computer-readable media and/or computers. Alternatively, caching gateways 102 and content library 101 may be embodied as physically separate systems.
  • CPM 103 may contain multiple content library 101 nodes coupled via national and/or regional networks, such as IP networks. CPM 103 is responsible for replicating and/or moving the media content assets through various storage locations of content library 110 and/or caching gateways 102 in a dynamic manner based on content popularity, content usage, and/or other factors. CPM 103 is further responsible for deciding and directing which particular ones of the streaming servers 117 will stream particular content to client devices 201. This decision may be based on, for example, the current or expected load of the various streaming servers 117.
  • The locations for all media content assets within content delivery network 100 are maintained and updated by the CLS 104. Upon a session setup request from a client device 201, if the requested content is already pre-positioned or cached at a streaming server 117, the content will be streamed from streaming server 117 to the requesting client device 117. If the content is not available at the streaming server 117, head end 190 will query CLS 104 for the locations of the requested media content asset within content library 101 and/or caching gateways 102 in order to fetch the media content asset and stream it to the requesting client device 201.
  • Upon initial ingest of a media content asset, content ingest block 105 and real-time ingest block 106 report the status and location of the media content asset to CLS 104. Then, when the location is requested by head end 190, CPM 103 fetches the reported location from CLS 104. Where a media content asset is to be later replicated or moved, CPM 103 is responsible for updating CLS 104 dynamically on the new media content asset location and/or status. Thus, in general CPM 103 is responsible for deciding where media content assets are to be stored, and CLS 104 is responsive to keeping track of those locations.
  • In the present example, multiple head ends 190 may be distributed geographically to serve the various client devices 201, and may each contain the functional blocks as shown in FIG. 1, which may operate as follows. Also, as shown by way of example in FIG. 2, each head end 190 may be coupled to, and serve, only a subset of the total set of client devices 201. Likewise, each streaming server 117 within a respective headend may be coupled to, and serve, only that respective subset of client devices 201. Thus, content to be delivered to a given client device 201 is forwarded to and provided by one of the streaming servers 117 that is coupled to the target client device 201.
  • Returning to FIG. 1, VOD backoffice 115 for each of head ends 190 may manage the receipt and fulfillment of VOD requests from those client devices 201 that are served by the respective head end 190, including session setup and stream control management of VOD media content assets. In addition, VOD backoffice 115 may receive asset title and content metadata from CMS 112 through AMS 114, and pass business rules such as trick mode restriction to streaming server 117 upon session setup time, assist with allocating edge QAM 118 resources for VOD sessions, and assist with advertisement insertion into the stream.
  • For instance, in response to a VOD request from one of client devices 201 served by a particular VOD backoffice 115, that VOD backoffice 115 may obtain the requested VOD media content asset from content delivery network 100 (if not already stored in head end 190) and cause the asset to be streamed in well-known ways to the requesting client device 201 via streaming server 117 and edge QAM 118, and/or CMTS 120 (which provides IP-based content streaming to client devices 201). Streaming server 117 may also include one or more computer-readable media for caching one or more of the media content assets, especially those that have been recently streamed by that streaming server 117.
  • Staging server 119 is used for Internet Protocol (IP) based streaming services for client data devices such as personal computers and smart phones. Staging server 119 supports various content formats and protocols, such as hypertext transfer protocol (HTTP) progressive download, FLASH download, and WINDOWS media streaming. Staging server 119 may also use the standard HTTP-based content locate and streaming protocol for pulling content from content delivery network 100. In addition, staging server 119 utilizes caching algorithms for caching library content from content delivery network 100.
  • Edge resource managers 116 manage bandwidth and program resources on QAMs 118. Edge resource managers 116 may support session requests from multiple session managers. If an edge device such as edge QAM 118 or CMTS 120 announces a failure to one of the edge resource managers 116, that edge resource manager 116 may be configured to not make any session related decisions. That edge resource manager 116 may instead forward a notification to the VOD system to determine how to resolve the issue.
  • As stated above, the media content assets may be permanently or temporarily stored in content delivery network 100 and/or at one or more head ends 190 at various distributed locations, including content library 101, one or more caching gateways 102, and/or one or more streaming servers 117. The actual locations at which each media content asset is stored may depend upon one or more factors, such as how popular the media content asset is to the end users, how popular the media content asset is expected to be, how often the media content assets is requested by one or more of the end users, and/or which end users have requested or are expected to request the media content assets. The locations at which the media content assets are stored may change dynamically over time in responses to changes in these and/or other factors.
  • FIG. 2 shows another illustrative functional block diagram of a portion of content delivery network 100 in conjunction with head ends 190A-D and client devices 201A-H. In this view, caching gateways 102 are shown as multiple caching gateways 102A-E. The number of caching gateways shown here is merely an example; there may be a fewer or greater number of caching gateways. Also in this example, caching gateways 102A-E are shown as being inter-coupled in a multi-tiered hierarchical topology. In particular, a first tier of caching gateways 102A, 102B and a second tier of caching gateways 102C-E, are provided. Also, a third tier in the hierarchy may be considered to be head ends 190A-D. Such a hierarchical topology may make certain organizations of media content assets easier. For example, a tier that is more local to a head end 190 may store copies of those content media assets that are the most requested or most popular (e.g., top ten) for client devices 201 of that head end 190, and a tier that is less local to that head end 190 may store copies of those content media assets that are less requested or less popular (e.g., top twenty) for client devices 201 of that head end. Using such a hierarchical caching technique, those storage nodes that are closer and more local to head ends may not need to be as large as those storage nodes that are more global and less local to head ends. Moreover, each tier may have its own network bandwidth resource management capability. For instance, each tier may be able to independently manage bit rates, compression, statistical multiplexing, and user limits. However, any topology of caching gateways and head ends may be used. As mentioned previously, content library 101 may also have a multi-tiered hierarchical topology.
  • Example operation scenarios of content delivery network 100 will now be described with reference to FIGS. 3-8.
  • FIG. 3 is a diagram of illustrative interactions between various elements of content delivery network 100 and its environment, when performing ingest of non-real-time media content assets. In this example, metadata associated with a certain media content asset is delivered from a content source to RMS 111 and/or CMS 112. RMS 111 and/or CMS 112 generate a unique identifier for the media content asset, and provision the media content asset with content ingest manager 107. Content ingest manager 107 then instructs content ingest block 105 to begin content ingest. Content ingest block 105 queries CPM 103, and in response CPM 103 determines and returns to content ingest block 105 the target location(s) at which the media content asset will be stored in content library 101. Also, content ingest manager 107 periodically provides the content transfer status to RMS 111 and/or CMS 112.
  • Next content ingest block 105 retrieves the media content asset file from the content provider, and also interfaces with transcoder 108 and derived content generator 109 as needed, for transcoding the media content asset file and generating auxiliary trick files. The retrieved files and any generated trick files are saved to content library 101 at the previously determined location(s). Content ingest block 105 reports to CLS 104 upon completion of ingesting the content, and also to content ingest manager 107 about content transfer status. Then, content ingest manager 107 reports, or responds to a request from, RMS 111 and/or CMS 112 regarding content status.
  • FIG. 4 is a diagram of illustrative interactions between various elements of content delivery network 100 and its environment, when performing ingest of real-time media content assets. The process is similar, with the main difference being that real-time manager 110 is used in place of content ingest manager 107, and real-time ingest block 106 is used in place of content ingest block 105. First, program guide metadata including a real-time program schedule is delivered from a content source to RMS 111 and/or CMS 112. RMS 111 and/or CMS 112 generate a unique identifier for the real-time media content asset, and provision the media content asset with content ingest manager 107. Real-time manager 110 then instructs content real-time ingest block 106 to begin stream ingest at times defined by the real-time program schedule. Real-time ingest block 106 queries CPM 103, and in response CPM 103 determines and returns to content ingest block 105 the target location(s) at which the real-time media content asset will be stored in content library 101. Also, content ingest manager 107 periodically provides the content transfer status to RMS 111 and/or CMS 112.
  • Upon the scheduled start of the real-time program, real-time ingest block 106 retrieves the media content asset stream from the content provider such as via IP multicast, and also interfaces with transcoder 108 and derived content generator 109 as needed, for transcoding the media content asset file and generating auxiliary trick files. The retrieved files and any generated trick files are saved to content library 101 at the previously determined location(s). Real-time ingest block 106 reports to CLS 104 upon completion of ingesting the stream, and also to real-time manager 110 about content transfer status. Then, real-time manager 110 reports, or responds to a request from, RMS 111 and/or CMS 112 regarding content status.
  • FIG. 5 is a diagram of illustrative interactions between various elements of content delivery network 100 and its environment, when pre-positioning an entire media content asset, or a portion thereof, already stored in content library 101 to a replicated location. This pre-positioning may be performed regardless of any client device 201 request for the media content asset, and may be performed so as to replicate the media content asset to a location that is closer—geographically or logically—to client devices 201 that are expected to request the media content asset. In this particular example, a media content asset (or a portion thereof) is pre-positioned from content library 110 to a streaming server 117. However, this process could alternatively be used to pre-position the media content asset from and to any other locations, such as caching gateway 102 or elsewhere. Also in this particular example, the media content asset is a VOD asset, however any type of media content asset may be used.
  • New content is provisioned and ingested into content distribution network 100 by RMS 111 and/or CMS 112, which publish media content asset metadata to AMS 114. AMS 114, in turn publishes the metadata to some or all of the VOD backoffices 115. The VOD backoffice 115 associated with the target streaming server 117 determines that pre-positioning at the streaming server 117 is desired, and initiates a content transfer command to streaming server 117. In response streaming server 117 sends a content locate and transfer request to CLS 104. In response, CLS 103 redirects streaming server 117 to the actual location of the desired media content asset in content library 101. In response, the located media content asset (or a portion thereof) from content library 101 is replicated to streaming server 117.
  • In the example of FIG. 5, pre-positioning of a media content asset by replication occurred in response to a request from VOD backoffice 115. However, CPM 103 may alternatively initiate pre-positioning. Also, although in FIG. 5 the media content asset was pre-positioned to streaming server 117, such pre-positioning may be made to any computer-readable medium in content delivery network 100 and/or outside of content delivery network 100, such as in head end 190. For example, a media content asset (or a portion thereof) may be pre-positioned to one or more caching gateways 102.
  • Moreover, the particular location(s) to which a media content asset is pre-positioned, as well as whether or not such pre-positioning should occur in the first place, may be determined responsive to a determination that the media content asset is popular or is expected to be popular. This determination may be made by, e.g., CPM 103 and/or VOD backoffice 115. And, the particular location(s) to which the media content asset is pre-positioned may be determined based on which geographical locations served by content data network 100 and/or head ends 190 the popularity is expected to occur. For example, a newly-released movie may be expected to be popular throughout the country, and so the movie (or a portion thereof) may be pre-positioned to all or most caching gateways 102 and/or VOD backoffices 115. Or, a media content asset, or portion thereof, of particular interest to only a certain geographic region may be pre-positioned only to one or more caching gateways 102 and/or VOD backoffices 115 that serve that geographic region.
  • In addition, although a media content asset may be pre-positioned prior to any or substantial requests for that media content asset by client devices 201, the media content asset (or portion thereof) may further be replicated to one or more additional locations based on actual experienced requests by client devices 201 for that media content asset. And, once a media content asset has been pre-positioned or otherwise replicated to a location, the replicated copy of the media content asset may remain at that location for a predetermined period of time or until it is later determined that the popularity for that media content asset has dropped below a predetermined threshold, after which time the replicated copy may be deleted or moved to yet another location in the network.
  • Popularity of a media content asset may be determined in many ways, such as being based on a measured frequency of client device 201 requests for the media content asset, determining whether the media content asset has been requested by client devices 201 a sufficient number of times over a predetermined period of time, and/or based on historical or predicted future demand for the media content asset. Also, such determinations may be made on a global basis (i.e., across the entire network) and/or on a geographic regional basis, and may be made more than once over time to re-determine the popularity of the media content asset and re-replicate the entire media content asset or a portion thereof as appropriate based on the newly-determined popularity.
  • Trick files may be treated like any other type of media content asset, and thus may be pre-positioned and otherwise replicated in the same manner as any other type of media content asset. In some cases, it may be desirable to locate trick files in the same computer-readable media and/or otherwise a same node of the network as their associated program content files. In other cases, it may be desirable to locate trick files independently of the location of their associated program content if it is not expected that the trick file will be as popular as the program content itself.
  • FIG. 6 is a diagram of illustrative interactions between various elements of content delivery network 100 and its environment, when streaming content to a client device 201 in response to a request from the client device 201. In this particular example, the media content asset is a VOD asset; however any type of media content asset may be used. Also in this particular example, the desired media content asset is streamed from a location in content library 101, however the media content asset may be stored anywhere such as in caching gateway 102 or in streaming server 117.
  • As before, new content is provisioned and ingested into content distribution network 100 by RMS 111 and/or CMS 112, which publish media content asset metadata to AMS 114. AMS 114, in turn publishes the metadata to some or all of the VOD backoffices 115. One of the VOD backoffices 115 optimistically processes a session setup request from client device 201, and in response to the request sends a session setup request to streaming server 117. In response, streaming server 117 checks its local cache for the requested content. If the content is available at the local cache of streaming server 117, then streaming server 117 will stream the content directly to the requesting client device 201. If the requested content is not stored at the local cache of streaming server 117, then streaming server 117 sends a content locate and transfer request to CLS 104.
  • In response, CLS 104 redirects streaming server 117 to the actual location in content library 101 (or elsewhere) where the requested media content asset is stored. In response to this redirection, streaming server 117 performs content transfer of the media content asset from content library 101, and streams the transferred content to the requesting client device 201.
  • FIG. 7 is a diagram of illustrative interactions between various elements of content delivery network 100 and its environment, when a trick file or other type of derived content is requested to be streamed to a client device 201. In this particular example, the requested trick file is already generated and is stored in content library 101. However, the trick file may be stored elsewhere, such as in caching gateway 102 or streaming server 117.
  • After an initial setup request and response between client device 201 and VOD backoffice 201, content from content library 101 is streamed by streaming server 117 to client device 201. During the content streaming, the user of client device 201 requests a trick play function, such as by selecting “fast forward” on the remote control. In response to the user request, client device 201 sends a trick play command from client device 201 to streaming server 117. In response, streaming server 117 checks its local cache for the requested trick file. If the trick file is available at the local cache of streaming server 117, then streaming server 117 will stream the trick file directly to the requesting client device 201. If the requested trick file is not stored at the local cache of streaming server 117, then streaming server 117 sends a content locate and transfer request to CLS 104.
  • In response, CLS 104 redirects streaming server 117 to the actual location in content library 101 (or elsewhere) where the requested trick file is stored. In response to this redirection, streaming server 117 performs transfer of the trick file from content library 101, and streams the transferred trick file to the requesting client device 201.
  • Later, during streaming of the trick file, client device 201 may request that the trick play end (in response to a user request to end the trick play function) and that the content stream resume to the normal content that was streaming prior to the trick play. This request is received by streaming server 117, and in response streaming server 117 resumes normal content streaming to client device 201.
  • FIG. 8 is another diagram of illustrative interactions between various elements of content delivery network 100 and its environment, when a trick file or other type of derived content is requested to be streamed to a client device 201. This time, the requested trick file is not already generated and stored, and is to be generated in response to the client device 201 request, such as by deriving the trick file from an existing pre-stored or live media content asset. Although a trick file is requested and generated in this example, such dynamic generation may be performed to generate any type of media content file, such as a VOD movie or television program.
  • Trick files and other types of derived media content assets may be derived from original, or parent, media content assets in several ways. In one way, the derived content may be one or more portions of the original content, such as where the derived content is a trick file or movie trailer. For instance, the derived trick file may be a video file having every nth (n>1) video frame of the original content, such as in a fast-forward trick file.
  • Another way to derive content is to generate a re-formatted version of the original content. For example, the derived content may be based on the original content except at a lower video and/or audio resolution, different video frame size, being transcoded using a different CODEC, or configured to be played at a different bit rate or frame rate. This type of derivation may be desirable where, for example, the client device 201 that will be receiving the derived content is not compatible with the format of the original content.
  • Still another way to derive content from original content is to add content to the original content, such as by splicing in local or non-local advertising. This may be useful where, for example, it is desired to insert local advertising relevant to the geographical region in which client device 201 that will be receiving the derived content is located.
  • Any or all of these types of derivation may be used separately or together in any combination to provide a derived media content asset from an original live or stored media content asset.
  • In the example of FIG. 8, after an initial setup request and response between client device 201 and VOD backoffice 201, content from content library 101 is streamed by streaming server 117 to client device 201. During the content streaming, the user of client device 201 requests a trick play function, such as by selecting “fast forward” on the remote control. In response to the user request, client device 201 sends a trick play command from client device 201 to streaming server 117. In response, streaming server 117 checks its local cache for the requested trick file. If the trick file is available at the local cache of streaming server 117, then streaming server 117 will stream the trick file directly to the requesting client device 201. If the requested trick file is not stored at the local cache of streaming server 117, then streaming server 117 sends a content locate and transfer request to CLS 104.
  • In response, CLS 104 determines that the trick file is not stored in content library 101 (or elsewhere), and sends a trick file locate response to streaming server 117 indicating this. In response to the trick file locate response, streaming server 117 sends a trick file transfer request to content library 101, which in turn sends a trick file object request to real-time ingest 106. In response, real-time ingest 106 sends a trick play generation request to derived content generator 109, identifying the particular trick file that is needed, and streams the transferred trick file to the requesting client device 201. In response to the trick play generation request, derived content generator 109 generates the trick file, by deriving it from original live or store content such as described previously, and sends it (or an identifier that identifies the newly-generated trick file) back to real-time ingest 106 in the form of a trick play generation response. In this example of FIG. 8, the derived content is a trick file. However, the derived content may be any type of derived content, such as a movie trailer, reformatted content, or content spliced with local advertising.
  • In response to the trick play generation response, real-time ingest 106 sends a trick file object response indicating or including the trick file to content library 101, and then in response to that content library sends a trick file transfer response to streaming server 117. Content library 101 may also store the newly-generated trick file in the event that it is requested again. Next, streaming server 117 begins streaming the trick file to client device 201.
  • Later, during streaming of the trick file, client device 201 may request that the trick play end (in response to a user request to end the trick play function) and that the content stream resume to the normal content that was streaming prior to the trick play. This request is received by streaming server 117, and in response streaming server 117 resumes normal content streaming to client device 201.
  • In other embodiments, a command may be generated by client device 201, with or without user intervention, that requests derived content (trick file or otherwise). In such a situation, FIGS. 7 and 8 might be modified, for example, by the “trick play command” being replaced with the more generic “derived content request,” which may be sent automatically responsive to establishing a session. In the derived content request, client device 201 may request that a particular type of formatted content be provided, such as a particular coding format, video frame size, bit rate, video and/or audio resolution, etc. The type of format requested may depend upon the type of device that client device 201 is. For example, where client device 201 is a smart phone with a cellular connection (directly or indirectly) to streaming server 117, client device 201 may request a low-resolution and/or low bit-rate version of the content.
  • As previously discussed, one of the locations at which a media content asset may be stored is at a streaming server 117 of a head end 190. While this may occur through normal replication of the asset from content library 101, it is also possible that the media content asset may be stored only locally at streaming server 117 and not centrally or globally at content library 101. In such a case, the ingested media content asset may either be transferred from content library 101 to streaming server 117 without maintaining a copy at content library 101, or the media content asset may be ingested and stored directly in streaming server 117 without first being stored in content library 101. Any of these situations may be determined and controlled by, for example, content propagation manager 103. In the latter situation, a media content asset may be stored at one or more streaming servers 117 but not necessarily at content library 101 when the media content asset is considered a local media content asset. That is, a media content asset that is expected to have interested viewers only in one or more local geographic regions, or an asset that is licensed only to be viewed in one or more local geographic regions rather than nationwide.
  • For example, a local semi-professional baseball game may be recorded and provided to viewers in northern California. It would not be expected that many viewers anywhere other than northern California would be interested in viewing that game. Thus, it would not necessarily be efficient to store a media content asset showing that game in content library 101 or at head ends 190 or caching servers 102 not located in northern California. Therefore, it might be preferable in such a situation to normally store the asset only locally in one or more network locations in or near northern California.
  • However, there may be an occasion where someone outside of northern California (in the above example) would like to view the game. To accomplish this, the network may be configured to allow bi-directional sharing between head ends 190 that serve different geographic regions, or in fact between any two head ends 190 in the network. FIG. 9 is a functional block diagram of an example of how content delivery network 100 may be used to perform such bi-directional local content sharing.
  • In the example of FIG. 9, there are multiple content ingest managers 107, real-time ingest managers 110, content ingest blocks 105, and real-time ingest blocks 106 that are part of content delivery network 100, each serving a different geographic region. For instance, FIG. 9 shows that a first geographic region is served by content ingest block CI1, real-time ingest block RTI1, content ingest manager CIM1, and real-time ingest manager RTM1. Likewise, a second geographic region is served by content ingest block CI2, real-time ingest block RTI2, content ingest manager CIM2, and real-time ingest manager RTM2. Also, a first head end 190 serving the first geographic region includes VOD backoffice VB1 and streaming server SS1, whereas a second head end 190 serving the second geographic region includes VOD backoffice VB2 and streaming server SS2. Each geographic region also serves their own sets of client devices 201, represented illustratively in FIG. 9 as client device C1 for the first geographic region and as client device C2 for the second geographic region.
  • The first and second geographic regions may be geographically separate from each other, such as being in different cities, counties, states, or countries. In terms of distance, the first and second geographic regions may be close to each other or far from each other, such as at least five hundred miles apart from each other.
  • A unified database (UDB) 901 for storing metadata describing media content assets is communicatively coupled (uni-directionally or bi-directionally) to equipment serving both the first and second geographic regions. For instance, as shown in FIG. 9, UDB 901 is coupled to content ingest manager CIM1, real-time ingest manager RTM1, content ingest manager CIM2, real-time ingest manager RTM2, VOD backoffice VB1, and VOD backoffice VB2. Any or all of these blocks are capable of querying and updating the data stored in UDB 901.
  • The media content assets for which metadata is stored in UDB 901 may include local media content assets received by a content source that serves or is located in the first or second geographic region, such as Local Content Source 1 and Local Content Source 2 in FIG. 9. These local media content assets are received into content ingest manager CIM1, real-time ingest manager RTM1, content ingest manager CIM2, or real-time ingest manager RTM2.
  • When a local media content asset is ingested at one of the geographic locations, the local media content asset (either real-time or non-real-time) may be stored at a head end 190, such as the head end 190 serving that geographic location. In particular, the media content asset may be stored at the streaming server or otherwise at a computer-readable medium to which the streaming server has access. In addition, the metadata for that local media content asset may be passed on to UDB 901. Because UDB 901 shares access to multiple geographic regions, such as the first and second geographic regions of FIG. 9, the metadata for a media content asset may be available to any of those geographic regions even though the media content asset itself may only be stored at one of those geographic regions.
  • For example, if a local media content asset is ingested by content ingest block CI1, the local media content asset may be stored at streaming server SS1, and the metadata for that local media content asset may be stored in UDB 901, such as via a path from content ingest block CI1 to content ingest manager CIM1 to UDB 901. In this example, the local media content asset is a VOD asset. If client device C1 wishes to view the local media content asset, then VOD backoffice VB1 can look up the metadata for that asset in UDB 901 and determine from CLS 104 that the asset is stored at streaming server SS1. The asset is then streamed to client device C1 from streaming server SS1. If client device C2 wishes to view the local media content asset, then VOD backoffice VB2 can also look up that same metadata for the asset in UDB 901 and determine from CLS 104 that the asset is stored at streaming server SS1. The asset can then be transferred to streaming server SS2, such as via a caching gateway 102. Streaming server SS2 then streams the asset to client device C2. Thus locally-stored content may be shared between different geographic regions of the network.
  • An example of interactions between various equipment when a local media content asset is shared between streaming servers is shown in the diagram of FIG. 10. Metadata for a local media content asset is received by content ingest block CI1 (for a non-real-time asset) or real-time ingest block RTI1 (for a real-time asset). The metadata is then forwarded by content ingest manager CIM1 or real-time manager RTM1 to UDB 901 for storage. The actual local media content asset may be ingested by content ingest CI1 or real-time ingest RTI1, and stored at streaming server SS1 and/or a caching gateway 102 local to streaming server SS1.
  • At some future point in time, the metadata for that local media content asset is replicated, in whole or in part, from UDB 901 to VOD backoffice VB2, either spontaneously or in response to a request for the local media content asset by VOD backoffice VB2, and some or all of the metadata for that asset may be passed on to client device C2, such as in the form of an electronic program guide indicating the local media content asset as an available choice. In response to a session setup request from client device C2, such as by the user selecting the indicated local media content asset from the program guide, VOD backoffice VB2 sends a content locate request to its local caching gateway 102 (not necessarily the same caching gateway at which the local media content is stored). In response, caching gateway 102 performs a content check with CLS 104, which returns the location of the desired local media content asset to caching gateway 102 and then on to VOD backoffice VB2. VOD backoffice VB2 then sends a session setup response to client device C2 and requests that the found local media content asset be replicated to streaming server SS2. The transfer is performed, and streaming server SS2 streams the local content media asset to client device C2.
  • Alternatively, rather than streaming the replicated media content asset, it may be possible that client device C2 desires a different format of the media content asset. In that case, either during or after session setup, client device C2 may request that the media content asset be in a particular format. If the particular format is not already pre-stored, then similar to the FIG. 8 embodiments, derived content generator 109 may derive the requested version of the media content asset such that the derived version is streamed to client device C2.
  • The process of FIG. 10 may also be reversed, such as where the local media content asset is initially received, ingested, and stored at the second geographic region and transferred to the first geographic region. And, as in the other embodiments described herein, any of the media content assets shared between video-on-demand systems may be live media content assets or non-live media content assets.
  • Thus, various systems, apparatuses, methods, and software have been described by way of example for using a network to efficiently distributing media content assets from a virtually unlimited content library and/or other storage to a plurality of client devices. In addition, it has been shown how bi-directional local content sharing between head ends may be accomplished, as well as dynamic distribution and generation of media content assets within the network.

Claims (20)

1. A method for sharing media content assets between video-on-demand systems of a service provider network, the method comprising:
receiving first media content and associated first metadata at a first video-on-demand system, the first video-on-demand system being configured to stream media content assets to a first plurality of client devices;
generating a first media content asset representing the first media content;
sending the first metadata to a database,
retrieving the first metadata from the database by a second video-on-demand system configured to stream media content assets to a second plurality of client devices to which the first video-on-demand system is not configured to stream media content assets;
sending, by the second video-on-demand system, a request for the first media content asset, the request being based on the first metadata; and
responsive to the request from the second video-on-demand system, replicating at least a portion of the first media content asset to the second video-on-demand system.
2. The method of claim 1, wherein the first media content asset is a live media content asset.
3. The method of claim 1, further comprising streaming, by the second video-on-demand system, the replicated copy of the at least the portion of the first media content asset to at least one of the second plurality of client devices.
4. The method of claim 1, further comprising sending, by the second video-on-demand system, data to the second plurality of client devices, the data being based on the retrieved first metadata.
5. The method of claim 1, further comprising receiving, by the second video-on-demand system, a client request from one of the second plurality of client devices, wherein sending the request for the first media content asset is performed responsive to the client request.
6. The method of claim 1, wherein the first and second video-on-demand systems are geographically separate from each other.
7. The method of claim 1, further comprising:
receiving a second media content asset and associated second metadata at the second video-on-demand system;
generating a second media content asset representing the second media content
sending the second metadata to the database;
retrieving the second metadata from the database by the first video-on-demand system;
sending, by the first video-on-demand system, a request for the second media content asset, the request being based on the second metadata; and
responsive to the request from the first video-on-demand system, replicating at least a portion of the second media content asset to the first video-on-demand system.
8. A video-on-demand network for sharing media content assets between video-on-demand systems, the video-on-demand network comprising:
a first computer-readable medium;
a database; and
a first video-on-demand system configured to stream media content assets to a first plurality of client devices, wherein the first video-on-demand system is further configured to:
receive first media content and associated first metadata,
generate a first media content asset representing the first media content, and
send the first metadata to the database,
wherein the network is configured to replicate at least a portion of the first media content asset to a second video-on-demand system having access to the database and configured to stream media content assets to a second plurality of client devices to which the first video-on-demand system is not configured to stream media content assets, the replication being responsive to a request from the second video-on-demand system for the first media content asset.
9. The video-on-demand network of claim 8, wherein the second video-on-demand system is further configured to stream the replicated copy of the at least portion of the first media content asset to at least one of the second plurality of client devices.
10. The video-on-demand network of claim 8, wherein the second video-on-demand system is further configured to send data to the second plurality of client devices, the data being based on the first metadata stored in the database.
11. The video-on-demand network of claim 8, wherein the second video-on-demand system is further configured to send the request for the first media content asset responsive to receiving a client request from one of the second plurality of client devices.
12. The video-on-demand network of claim 8, wherein the first and second video-on-demand systems are geographically separate from each other.
13. The video-on-demand network of claim 8, wherein the second video-on-demand system is further configured to:
receive second media content and associated second metadata;
generate a second media content asset representing the second media content; and
send the second metadata to the database.
14. The video-on-demand network of claim 13, wherein the first video-on-demand system is further configured to:
retrieve the second metadata from the database; and
request the second media content asset, the request being based on the retrieved second metadata.
15. The video-on-demand network of claim 14, wherein the first video-on-demand system is further configured to:
receive a replicated copy of at least a portion of the second media content asset; and
stream the replicated copy of the at least the portion of the second media content asset to at least one of the first plurality of client devices.
16. A system for sharing media content assets between first and second video-on-demand systems each serving a different plurality of client devices, the system comprising:
a computer; and
a computer-readable medium,
wherein the computer is configured to:
receive a first media content asset from the first video-on-demand system, and store the received first media content asset in the computer-readable medium, wherein the first video-on-demand system is configured to stream media content assets to a first plurality of client devices,
receive a request from the second video-on-demand system for the first media content asset, and
responsive to the request from the second video-on-demand system, replicate at least a portion of the first media content asset to the second video-on-demand system, wherein the second video-on-demand system is configured to stream media content assets to a second plurality of client devices to which the first video-on-demand system is not configured to stream media content assets.
17. The system of claim 16, wherein the first plurality of client devices are located in a different city from the second plurality of client devices.
18. The system of claim 16, wherein the first and second video-on-demand systems are located at least five hundred miles from each other.
19. The system of claim 16, wherein the computer is further configured to:
receive a second media content asset from the second video-on-demand system, and store the received second media content asset in the computer-readable medium,
receive a request from the first video-on-demand system for the second media content asset, and
responsive to the request from the first video-on-demand system, replicate at least a portion of the second media content asset to the first video-on-demand system.
20. The system of claim 16, wherein the first media content asset is a live media content asset.
US12/751,231 2009-03-31 2010-03-31 Bi-directional transfer of media content assets in a content delivery network Abandoned US20100251313A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US12/751,231 US20100251313A1 (en) 2009-03-31 2010-03-31 Bi-directional transfer of media content assets in a content delivery network

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US16519709P 2009-03-31 2009-03-31
US12/751,231 US20100251313A1 (en) 2009-03-31 2010-03-31 Bi-directional transfer of media content assets in a content delivery network

Publications (1)

Publication Number Publication Date
US20100251313A1 true US20100251313A1 (en) 2010-09-30

Family

ID=42785646

Family Applications (7)

Application Number Title Priority Date Filing Date
US12/751,148 Active US9769504B2 (en) 2009-03-31 2010-03-31 Dynamic distribution of media content assets for a content delivery network
US12/751,257 Active 2030-11-17 US9055085B2 (en) 2009-03-31 2010-03-31 Dynamic generation of media content assets for a content delivery network
US12/751,231 Abandoned US20100251313A1 (en) 2009-03-31 2010-03-31 Bi-directional transfer of media content assets in a content delivery network
US14/707,192 Active 2030-11-06 US9729901B2 (en) 2009-03-31 2015-05-08 Dynamic generation of media content assets for a content delivery network
US15/674,976 Active US10701406B2 (en) 2009-03-31 2017-08-11 Dynamic distribution of media content assets for a content delivery network
US16/876,479 Active 2030-04-18 US11356711B2 (en) 2009-03-31 2020-05-18 Dynamic distribution of media content assets for a content delivery network
US16/876,506 Pending US20200280745A1 (en) 2009-03-31 2020-05-18 Dynamic Distribution of Media Content Assets For A Content Delivery Network

Family Applications Before (2)

Application Number Title Priority Date Filing Date
US12/751,148 Active US9769504B2 (en) 2009-03-31 2010-03-31 Dynamic distribution of media content assets for a content delivery network
US12/751,257 Active 2030-11-17 US9055085B2 (en) 2009-03-31 2010-03-31 Dynamic generation of media content assets for a content delivery network

Family Applications After (4)

Application Number Title Priority Date Filing Date
US14/707,192 Active 2030-11-06 US9729901B2 (en) 2009-03-31 2015-05-08 Dynamic generation of media content assets for a content delivery network
US15/674,976 Active US10701406B2 (en) 2009-03-31 2017-08-11 Dynamic distribution of media content assets for a content delivery network
US16/876,479 Active 2030-04-18 US11356711B2 (en) 2009-03-31 2020-05-18 Dynamic distribution of media content assets for a content delivery network
US16/876,506 Pending US20200280745A1 (en) 2009-03-31 2020-05-18 Dynamic Distribution of Media Content Assets For A Content Delivery Network

Country Status (1)

Country Link
US (7) US9769504B2 (en)

Cited By (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100250772A1 (en) * 2009-03-31 2010-09-30 Comcast Cable Communications, Llc Dynamic distribution of media content assets for a content delivery network
US20110191439A1 (en) * 2010-01-29 2011-08-04 Clarendon Foundation, Inc. Media content ingestion
US20120226770A1 (en) * 2011-03-02 2012-09-06 Comcast Cable Communications, Llc Delivery of Content
US20140095457A1 (en) * 2012-10-02 2014-04-03 Nextbit Systems Inc. Regulating data storage based on popularity
US20140108671A1 (en) * 2012-10-17 2014-04-17 Netflix, Inc Partitioning streaming media files on multiple content distribution networks
EP2728891A3 (en) * 2010-12-08 2014-09-03 Ericsson Television Inc. Systems and methods for distributed authentication of video services
US20150012593A1 (en) * 2012-02-23 2015-01-08 Ericsson Television Inc. System and method for delivering content in a content delivery network
WO2015172071A1 (en) * 2014-05-08 2015-11-12 Tank Design, Inc. Systems and methods for location-dependent electronic communications
US9438935B2 (en) * 2010-11-23 2016-09-06 Verizon Patent And Licensing Inc. Hybrid video selection, delivery, and caching
US9438487B2 (en) 2012-02-23 2016-09-06 Ericsson Ab Bandwith policy management in a self-corrected content delivery network
US20160269688A1 (en) * 2015-03-13 2016-09-15 At&T Intellectual Property I, L.P. Determination of a service office of a media content distribution system to record a media content item with a network recorder
US9883221B1 (en) 2015-03-25 2018-01-30 Concurrent Computer Corporation System and method for optimizing real-time video-on-demand recording in a content delivery network
US20230118793A1 (en) * 2021-10-15 2023-04-20 Netflix, Inc. Dynamic content steering based on server and client device capabilities

Families Citing this family (41)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8533606B2 (en) * 2008-06-13 2013-09-10 At&T Intellectual Property I, L.P. System and method for personalized hold
US11144969B2 (en) * 2009-07-28 2021-10-12 Comcast Cable Communications, Llc Search result content sequencing
US9706257B2 (en) 2009-09-14 2017-07-11 At&T Intellectual Property I, L.P. Viewing control management across multiple access points
US9325502B2 (en) * 2009-11-13 2016-04-26 At&T Intellectual Property I, L.P. Identity management for transactional content
US8738736B2 (en) * 2010-11-23 2014-05-27 Edgecast Networks, Inc. Scalable content streaming system with server-side archiving
CN102857320A (en) * 2011-06-30 2013-01-02 新奥特(北京)视频技术有限公司 Method and system for transmission of sport game data
US8806188B2 (en) 2011-08-31 2014-08-12 Sonic Ip, Inc. Systems and methods for performing adaptive bitrate streaming using automatically generated top level index files
EP2761856A1 (en) * 2011-09-30 2014-08-06 Interdigital Patent Holdings, Inc. Method and apparatus for managing content storage subsystems in a communications network
US8856272B2 (en) 2012-01-08 2014-10-07 Harman International Industries, Incorporated Cloud hosted audio rendering based upon device and environment profiles
US8930491B2 (en) * 2012-01-18 2015-01-06 Echostar Technologies L.L.C. Apparatus, systems and methods for providing edge cached media content to media devices based on user history
US20130298175A1 (en) * 2012-05-02 2013-11-07 International Business Machines Corporation Constructing a customized message in a video-on-demand service
WO2014036642A1 (en) 2012-09-06 2014-03-13 Decision-Plus M.C. Inc. System and method for broadcasting interactive content
US9128892B2 (en) 2012-12-10 2015-09-08 Netflix, Inc. Managing content on an ISP cache
US9479805B2 (en) 2013-02-15 2016-10-25 Cox Communications, Inc. Entitlement validation and quality control of content in a cloud-enabled network-based digital video recorder
US10601798B2 (en) 2013-03-15 2020-03-24 Cox Communications, Inc. Federated services managed access to services and content
US9602208B2 (en) * 2013-07-12 2017-03-21 Broadcom Corporation Content distribution system
US10554707B2 (en) * 2013-08-13 2020-02-04 Imvision Software Technologies Ltd. Method and system for self-detection and efficient transmission of real-time popular recorded over-the-top streams over communication networks
US9674252B2 (en) 2013-07-17 2017-06-06 Imvision Software Technologies Ltd. System and method for efficient delivery of repetitive multimedia content
US9432731B2 (en) 2013-07-17 2016-08-30 Imvision Software Technologies Ltd. Method and system for detecting live over the top (OTT) streams in communications networks
US20150036526A1 (en) * 2013-07-30 2015-02-05 Imvision Software Technologies Ltd. Method and system for efficient transmission of over-the-top streams over fixed-line networks
US10045088B2 (en) * 2014-09-30 2018-08-07 At&T Intellectual Property I, L.P. Method and apparatus for distributing content locally
US10477260B2 (en) 2014-10-17 2019-11-12 Cox Communications, Inc. Network based digital video recorder playback adapter
US20160162651A1 (en) * 2014-12-04 2016-06-09 Dogpatch Technology, Inc. Messaging system and method
ES2874748T3 (en) 2015-01-06 2021-11-05 Divx Llc Systems and methods for encoding and sharing content between devices
US9681163B1 (en) * 2015-03-26 2017-06-13 Amazon Technologies, Inc. Identify bad files using QoS data
US10484487B2 (en) 2015-04-01 2019-11-19 At&T Mobility Ii Llc System and method for predictive delivery of prioritized content
CN105072151A (en) * 2015-07-03 2015-11-18 中国联合网络通信集团有限公司 Content collaborative scheduling method and system for CDN
US10904229B2 (en) * 2015-12-29 2021-01-26 Akamai Technologies, Inc. Caching content securely within an edge environment, with pre-positioning
US10205975B2 (en) * 2016-01-20 2019-02-12 Avago Technologies International Sales Pte. Limited Trick mode operation with multiple video streams
US11012719B2 (en) 2016-03-08 2021-05-18 DISH Technologies L.L.C. Apparatus, systems and methods for control of sporting event presentation based on viewer engagement
US10491648B2 (en) * 2016-05-13 2019-11-26 Cisco Technology, Inc. Server-side interstitial content insertion
US11399218B2 (en) 2016-09-09 2022-07-26 Comcast Cable Communications, Llc Methods and systems for verification of asset availability
US10540364B2 (en) 2017-05-02 2020-01-21 Home Box Office, Inc. Data delivery architecture for transforming client response data
US10715615B1 (en) * 2018-08-01 2020-07-14 The Government Of The United States Of America As Represented By The Secretary Of The Air Force Dynamic content distribution system and associated methods
US10931778B2 (en) * 2019-01-09 2021-02-23 Margo Networks Pvt. Ltd. Content delivery network system and method
US11366823B2 (en) * 2019-03-15 2022-06-21 Unity Technologies Sf Method and system for transforming and delivering digital assets over a network
US11221998B2 (en) 2019-05-31 2022-01-11 Microsoft Technology Licensing, Llc Ingesting and processing content types
US11388458B1 (en) * 2020-12-16 2022-07-12 Meta Platforms, Inc. Systems and methods for tailoring media encoding to playback environments
CN112995771B (en) * 2021-04-25 2021-07-16 广州华源网络科技有限公司 Multimedia value-added service system based on wireless communication
US11695855B2 (en) 2021-05-17 2023-07-04 Margo Networks Pvt. Ltd. User generated pluggable content delivery network (CDN) system and method
WO2023224680A1 (en) 2022-05-18 2023-11-23 Margo Networks Pvt. Ltd. Peer to peer (p2p) encrypted data transfer/offload system and method

Citations (96)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5542072A (en) * 1992-12-31 1996-07-30 Sony Corporation Database system and method for accessing the same
US5839068A (en) * 1995-02-21 1998-11-17 Hughes Electronics Corporation Method of delivering service voice announcements in a satellite telephony communication system
US6272598B1 (en) * 1999-03-22 2001-08-07 Hewlett-Packard Company Web cache performance by applying different replacement policies to the web cache
US20020007491A1 (en) * 2000-01-13 2002-01-17 Schiller Jay B. Method and apparatus for identifying a signal route for delivery of video-on-demand to a subscriber terminal
US20020016970A1 (en) * 2000-06-14 2002-02-07 Shinji Negishi Data conversion apparatus and method, data distribution apparatus and method, and data distribution system
US6378130B1 (en) * 1997-10-20 2002-04-23 Time Warner Entertainment Company Media server interconnect architecture
US20020061012A1 (en) * 1999-04-13 2002-05-23 Thi James C. Cable modem with voice processing capability
US6438596B1 (en) * 1995-09-04 2002-08-20 Kabushiki Kaisha Toshiba Video on demand system that presents users with a selection list of proposed videos for which server and network resources are available to immediately serve the selected video
US6449730B2 (en) * 1995-10-24 2002-09-10 Seachange Technology, Inc. Loosely coupled mass storage computer cluster
US20020131428A1 (en) * 2001-03-13 2002-09-19 Vivian Pecus Large edge node for simultaneous video on demand and live streaming of satellite delivered content
US20020152364A1 (en) * 1998-10-30 2002-10-17 Kasenna, Inc. Media server system and process having device independent near-online storage support
US20020154892A1 (en) * 2001-02-13 2002-10-24 Hoshen-Eliav System for distributing video and content on demand
US6473858B1 (en) * 1999-04-16 2002-10-29 Digeo, Inc. Method and apparatus for broadcasting data with access control
US20030097663A1 (en) * 2001-11-19 2003-05-22 Matti Puputti Method and apparatus for dynamic provisioning of IP-based services in a DVB network
US20030118243A1 (en) * 2001-09-18 2003-06-26 Ugur Sezer Largest magnitude indices selection for (run, level) encoding of a block coded picture
US20030149988A1 (en) * 1998-07-14 2003-08-07 United Video Properties, Inc. Client server based interactive television program guide system with remote server recording
US20030217113A1 (en) * 2002-04-08 2003-11-20 Microsoft Corporation Caching techniques for streaming media
US20040093618A1 (en) * 2002-11-07 2004-05-13 Baldwin James Armand Trick mode support for VOD with long intra-frame intervals
US20040103120A1 (en) * 2002-11-27 2004-05-27 Ascent Media Group, Inc. Video-on-demand (VOD) management system and methods
US20040103437A1 (en) * 2002-11-26 2004-05-27 Concurrent Computer Corporation, A Delaware Corporation Video on demand management system
US20040107436A1 (en) * 2002-11-29 2004-06-03 Fujitsu Limited Digital broadcast signal distribution system and subscriber terminal
US20040110468A1 (en) * 2002-12-10 2004-06-10 Perlman Stephen G. Wireless network with presentation and media layers for broadcast satellite and cable services
US20040117850A1 (en) * 2002-12-11 2004-06-17 Jeyhan Karaoguz Media exchange network having media processing systems and personal computers with common user interfaces
US6774926B1 (en) * 1999-09-03 2004-08-10 United Video Properties, Inc. Personal television channel system
US20040187160A1 (en) * 2003-03-17 2004-09-23 Qwest Communications International Inc. Methods and systems for providing video on demand
US20040244058A1 (en) * 2002-05-03 2004-12-02 Carlucci John B. Programming content processing and management system and method
US20040246376A1 (en) * 2002-04-12 2004-12-09 Shunichi Sekiguchi Video content transmission device and method, video content storage device, video content reproduction device and method, meta data generation device, and video content management method
US20050028208A1 (en) * 1998-07-17 2005-02-03 United Video Properties, Inc. Interactive television program guide with remote access
US20050188055A1 (en) * 2003-12-31 2005-08-25 Saletore Vikram A. Distributed and dynamic content replication for server cluster acceleration
US20050262542A1 (en) * 1998-08-26 2005-11-24 United Video Properties, Inc. Television chat system
US20050267948A1 (en) * 2004-06-01 2005-12-01 Mckinley Brittain Method and system for resource management in a video on-demand server
US20050275758A1 (en) * 2002-06-21 2005-12-15 Alcatel Recording and playback system
US20060005224A1 (en) * 2004-06-30 2006-01-05 John Dunning Technique for cooperative distribution of video content
US20060020995A1 (en) * 2004-07-20 2006-01-26 Comcast Cable Communications, Llc Fast channel change in digital media systems
US20060085553A1 (en) * 2004-10-05 2006-04-20 Jon Rachwalski Method and system for broadcasting multimedia data
US20060085816A1 (en) * 2004-10-18 2006-04-20 Funk James M Method and apparatus to control playback in a download-and-view video on demand system
US7065778B1 (en) * 2001-05-25 2006-06-20 Enreach Technologies, Inc. Method and system for providing media from remote locations to a viewer
US20060146040A1 (en) * 2003-06-30 2006-07-06 Koninklijke Philips Electronics N.V. Trick play using crt scan modes
US7080400B1 (en) * 2001-08-06 2006-07-18 Navar Murgesh S System and method for distributed storage and presentation of multimedia in a cable network environment
US20060218607A1 (en) * 2005-03-09 2006-09-28 Vvond, Inc. System and method for trick play of highly compressed video data
US7143170B2 (en) * 2003-04-30 2006-11-28 Akamai Technologies, Inc. Automatic migration of data via a distributed computer network
US20060277581A1 (en) * 2003-03-10 2006-12-07 Avraham Eliyahu Local entity and a method for providing media streams
US20070143457A1 (en) * 2005-12-16 2007-06-21 Weidong Mao Method of using tokens and policy descriptors for dynamic on demand session management
US20070140647A1 (en) * 2003-12-19 2007-06-21 Yoshiaki Kusunoki Video data processing method and video data processing apparatus
US20070157281A1 (en) * 2005-12-23 2007-07-05 United Video Properties, Inc. Interactive media guidance system having multiple devices
US20070276926A1 (en) * 2006-05-24 2007-11-29 Lajoie Michael L Secondary content insertion apparatus and methods
US20080071859A1 (en) * 2002-02-14 2008-03-20 Level 3 Communications, Llc Popularity-based selective replication in content delivery network
US7350041B1 (en) * 2005-08-26 2008-03-25 Emc Corporation Methods and apparatus for managing the storage of content
US20080124052A1 (en) * 2006-08-31 2008-05-29 Opentv, Inc. Systems and methods to modify playout or playback
US20080148327A1 (en) * 2006-12-18 2008-06-19 General Instrument Corporation Method and Apparatus for Providing Adaptive Trick Play Control of Streaming Digital Video
US20080155614A1 (en) * 2005-12-22 2008-06-26 Robin Ross Cooper Multi-source bridge content distribution system and method
US20080168133A1 (en) * 2007-01-05 2008-07-10 Roland Osborne Video distribution system including progressive playback
US7404201B2 (en) * 2003-02-14 2008-07-22 Hitachi, Ltd. Data distribution server
US20080187283A1 (en) * 2006-12-29 2008-08-07 Broadband Royalty Corporation Source optimized dynamic trickplay
US20080209491A1 (en) * 2007-02-28 2008-08-28 Hasek Charles A Personal content server apparatus and methods
US20080253406A1 (en) * 2007-04-16 2008-10-16 Time Warner Cable Inc. Transport stream encapsulated trick modes
US20080270610A1 (en) * 2002-07-24 2008-10-30 Kasenna, Inc. System and metehod for highly scalable real-time and time-based data delivery using server clusters
US7454424B2 (en) * 2003-01-16 2008-11-18 Hewlett-Packard Development Company, L.P. System and method for efficiently replicating a file
US20080298773A1 (en) * 2000-11-17 2008-12-04 Masahiro Honjo Method and apparatus for recording/reproduction
US20080307479A1 (en) * 2007-06-11 2008-12-11 Alcatel Lucent Bandwidth-Efficient Deployment of Video-On-Demand Assets in an IPTV Network
US20090031390A1 (en) * 2007-07-26 2009-01-29 Broadcom Corporation Method and apparatus for synchronized transmission and reception of audiovisual data and index data in internet protocol television applications for implementing remote network record with instant personal video recorder support
US20090049186A1 (en) * 2007-08-16 2009-02-19 Sony Corporation, A Japanese Corporation Method to facilitate trick-modes for streaming video
US20090083806A1 (en) * 2003-10-10 2009-03-26 Microsoft Corporation Media organization for distributed sending of media data
US20090083813A1 (en) * 2007-09-26 2009-03-26 Verivue, Inc. Video Delivery Module
US20090113068A1 (en) * 2007-10-31 2009-04-30 Hitachi, Ltd. Content delivery system, cache server, and cache control server
US20090119322A1 (en) * 2007-11-07 2009-05-07 Mills Brendon W System and method for managing content
US20090136204A1 (en) * 2007-11-26 2009-05-28 Yueh-Hua Chen System and method for remote live pause
US20090158326A1 (en) * 2007-12-18 2009-06-18 Hunt Neil D Trick Play of Streaming Media
US20090161765A1 (en) * 2007-12-21 2009-06-25 General Instrument Corporation Enabling Trick Plays during VBR Playback of a CBR Transmitted Media File
US20090249419A1 (en) * 2008-03-25 2009-10-01 Kahn Brian E Method and System of Queued Management of Multimedia Storage
US20090271818A1 (en) * 2008-04-28 2009-10-29 General Instrument Corporation Method And Apparatus For Delivering Emergency Alert System (EAS) Messages Over A Switched Digital Video (SDV) System
US20090292526A1 (en) * 2008-05-20 2009-11-26 Aol Llc Monitoring conversations to identify topics of interest
US20090307329A1 (en) * 2008-06-06 2009-12-10 Chris Olston Adaptive file placement in a distributed file system
US20090310933A1 (en) * 2008-06-17 2009-12-17 Microsoft Corporation Concurrently Displaying Multiple Trick Streams for Video
US20100003008A1 (en) * 2008-07-01 2010-01-07 Cisco Technology, Inc. Dynamically Creating Trick Files To Hide Latency In Streaming Networks
US20100058405A1 (en) * 2008-08-29 2010-03-04 At&T Corp. Systems and Methods for Distributing Video on Demand
US20100082349A1 (en) * 2008-09-29 2010-04-01 Apple Inc. Systems and methods for selective text to speech synthesis
US20100094969A1 (en) * 2008-10-15 2010-04-15 Patentvc Ltd. Reduction of Peak-to-Average Traffic Ratio in Distributed Streaming Systems
US20100115575A1 (en) * 2008-11-03 2010-05-06 At&T Intellectual Property I, L.P. System and method for recording and distributing media content
US20100122282A1 (en) * 2008-11-10 2010-05-13 Time Warner Cable Inc. System and method for enhanced advertising in a video content network
US20100146139A1 (en) * 2006-09-29 2010-06-10 Avinity Systems B.V. Method for streaming parallel user sessions, system and computer software
US7761900B2 (en) * 2006-08-02 2010-07-20 Clarendon Foundation, Inc. Distribution of content and advertisement
US7764863B1 (en) * 2002-03-06 2010-07-27 Bigband Networks Inc. System and method for providing trick modes
US20100202509A1 (en) * 2009-02-10 2010-08-12 Cisco Technology, Inc. Near real time delivery of variable bit rate media streams
US20100218208A1 (en) * 2009-02-26 2010-08-26 Comcast Cable Communications, Llc Method and Apparatus for Generating Alternative Commercials
US7802286B2 (en) * 2007-07-24 2010-09-21 Time Warner Cable Inc. Methods and apparatus for format selection for network optimization
US20100246670A1 (en) * 2007-08-29 2010-09-30 Akira Takemoto Method for generating video data for trick play
US20100251304A1 (en) * 2009-03-30 2010-09-30 Donoghue Patrick J Personal media channel apparatus and methods
US20100251305A1 (en) * 2009-03-30 2010-09-30 Dave Kimble Recommendation engine apparatus and methods
US7822862B2 (en) * 2002-06-07 2010-10-26 Hewlett-Packard Development Company, L.P. Method of satisfying a demand on a network for a network resource
US20100312861A1 (en) * 2007-11-30 2010-12-09 Johan Kolhi Method, network, and node for distributing electronic content in a content distribution network
US7860948B2 (en) * 2001-09-26 2010-12-28 Telefonaktiebolaget L M Ericsson (Publ) Hierarchical caching in telecommunication networks
US20110099332A1 (en) * 2007-08-30 2011-04-28 Alcatel-Lucent Usa Inc. Method and system of optimal cache allocation in iptv networks
US7962942B1 (en) * 2006-02-28 2011-06-14 Rovi Guides, Inc. Systems and methods for enhanced trick-play functions
US7991883B1 (en) * 2008-12-15 2011-08-02 Adobe Systems Incorporated Server communication in a multi-tier server architecture
US8166510B1 (en) * 2001-07-17 2012-04-24 Vixs Systems, Inc. Method and apparatus for distributing video on demand loading

Family Cites Families (63)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6850252B1 (en) * 1999-10-05 2005-02-01 Steven M. Hoffberg Intelligent electronic appliance system and method
US5909638A (en) * 1996-08-06 1999-06-01 Maximum Video Systems, Inc. High speed video distribution and manufacturing system
US8191097B1 (en) * 1999-04-01 2012-05-29 Comcast Ip Holdings I, Llc Method and apparatus for hierarchical distribution of video content for an interactive information distribution system
WO2001067772A2 (en) 2000-03-09 2001-09-13 Videoshare, Inc. Sharing a streaming video
US7240100B1 (en) 2000-04-14 2007-07-03 Akamai Technologies, Inc. Content delivery network (CDN) content server request handling mechanism with metadata framework support
US6993508B1 (en) * 2000-12-29 2006-01-31 Novell, Inc. Method and mechanism for vending digital content
US7587500B2 (en) * 2001-01-10 2009-09-08 Xcelera Distributed selection of a content server
US7080138B1 (en) * 2001-04-11 2006-07-18 Cisco Technology, Inc. Methods and apparatus for content server selection
US20040034874A1 (en) * 2002-08-19 2004-02-19 Hord Phillip M. Pop-up PVR advertising
US20040117437A1 (en) * 2002-12-16 2004-06-17 Exanet, Co. Method for efficient storing of sparse files in a distributed cache
US7624158B2 (en) 2003-01-14 2009-11-24 Eycast Inc. Method and apparatus for transmission and storage of digital medical data
US7680897B1 (en) 2003-04-08 2010-03-16 Novell, Inc. Methods and systems for managing network traffic
US8423662B1 (en) 2003-04-28 2013-04-16 Akamai Technologies, Inc. Forward request queuing in a distributed edge processing environment
US7617516B2 (en) * 2003-05-15 2009-11-10 At&T Intellectual Property I, L.P. Methods and systems for providing video on demand over a communication network using managed quality of service, bandwidth allocation and/or user profiles
US7853980B2 (en) * 2003-10-31 2010-12-14 Sony Corporation Bi-directional indices for trick mode video-on-demand
US7346163B2 (en) 2003-10-31 2008-03-18 Sony Corporation Dynamic composition of pre-encrypted video on demand content
US7731360B2 (en) 2003-11-07 2010-06-08 Neuro Kinetics Portable video oculography system
US20050125838A1 (en) * 2003-12-04 2005-06-09 Meng Wang Control mechanisms for enhanced features for streaming video on demand systems
US20050262246A1 (en) * 2004-04-19 2005-11-24 Satish Menon Systems and methods for load balancing storage and streaming media requests in a scalable, cluster-based architecture for real-time streaming
US7747132B2 (en) * 2004-08-26 2010-06-29 Sony Corporation Method and system for displaying multiple media content instances during a single viewing session
US8271578B2 (en) 2004-12-08 2012-09-18 B-Obvious Ltd. Bidirectional data transfer optimization and content control for networks
US20060280431A1 (en) * 2005-06-03 2006-12-14 Kirk Blattman Supporting trick modes in a streaming digital video environment using a root trick mode stream
US9286388B2 (en) * 2005-08-04 2016-03-15 Time Warner Cable Enterprises Llc Method and apparatus for context-specific content delivery
EP1806919A1 (en) * 2006-01-05 2007-07-11 Alcatel Lucent Media delivery system with content-based trick play mode
WO2007109162A2 (en) 2006-03-17 2007-09-27 Viddler, Inc. Methods and systems for displaying videos with overlays and tags
US8095466B2 (en) 2006-05-15 2012-01-10 The Directv Group, Inc. Methods and apparatus to conditionally authorize content delivery at content servers in pay delivery systems
US8280982B2 (en) 2006-05-24 2012-10-02 Time Warner Cable Inc. Personal content server apparatus and methods
US8260881B1 (en) 2006-09-06 2012-09-04 Amazon Technologies, Inc. Remote download of content
US20080089299A1 (en) 2006-10-13 2008-04-17 Motorola, Inc. Method and system for distributing content in Ad-hoc networks using super peers
US20080101764A1 (en) * 2006-11-01 2008-05-01 General Instrument Corporation Method and Apparatus for Managing Multimedia Content Recording Assets
JP2008134966A (en) 2006-11-29 2008-06-12 Sony Corp Data management server, data management system, data management method and program
US9196309B2 (en) * 2006-12-13 2015-11-24 Johnson Controls, Inc. Source content preview in a media system
US7553342B2 (en) 2006-12-20 2009-06-30 Judy Cooper, legal representative Single phase hydrous hydrocarbon-based fuel, methods for producing the same and compositions for use in such method
US20080196283A1 (en) 2007-02-20 2008-08-21 Aynsley Nicholas J Personalizable calendar assemblies and methods
CN101123527B (en) 2007-02-25 2010-10-27 华为技术有限公司 A stream media system, signaling forward device and stream media transmission method
JP4984967B2 (en) 2007-02-28 2012-07-25 富士通株式会社 Information processing control apparatus, method for distributing information through network, and program therefor
US8346230B2 (en) 2007-03-06 2013-01-01 Capitol Broadcasting Company, Inc. System and method for delivering geographically restricted content, such as over-air broadcast programming, to a recipient over a network, namely the internet
US7720936B2 (en) 2007-03-12 2010-05-18 Citrix Systems, Inc. Systems and methods of freshening and prefreshening a DNS cache
JP4405523B2 (en) * 2007-03-20 2010-01-27 株式会社東芝 CONTENT DISTRIBUTION SYSTEM, SERVER DEVICE AND RECEPTION DEVICE USED IN THE CONTENT DISTRIBUTION SYSTEM
US8019830B2 (en) 2007-04-16 2011-09-13 Mark Thompson Methods and apparatus for acquiring file segments
US9628746B2 (en) * 2007-08-22 2017-04-18 Time Warner Cable Enterprises Llc Apparatus and method for remote wireless control of digital video recorders and the like
US20090094248A1 (en) * 2007-10-03 2009-04-09 Concert Technology Corporation System and method of prioritizing the downloading of media items in a media item recommendation network
KR20090056848A (en) 2007-11-29 2009-06-03 엘지전자 주식회사 Broadcast receiver and method for receiving adaptive broadcast signal
US8997161B2 (en) 2008-01-02 2015-03-31 Sonic Ip, Inc. Application enhancement tracks
KR20090079838A (en) 2008-01-17 2009-07-22 엘지전자 주식회사 An iptv receiving system and a method for processing data thereof
US8190683B2 (en) * 2008-02-29 2012-05-29 Microsoft Corporation Synchronizing multiple user remote content playback
US8156243B2 (en) 2008-03-31 2012-04-10 Amazon Technologies, Inc. Request routing
US8537835B2 (en) * 2008-06-20 2013-09-17 Alcatel Lucent Methods and apparatus for self-organized caching in a content delivery network
CN101378494B (en) 2008-10-07 2011-04-20 中兴通讯股份有限公司 System and method for implementing internet television medium interaction
US20100088405A1 (en) * 2008-10-08 2010-04-08 Microsoft Corporation Determining Network Delay and CDN Deployment
US7818445B2 (en) * 2008-10-15 2010-10-19 Patentvc Ltd. Methods and devices for obtaining a broadcast-like streaming content
US20100149301A1 (en) 2008-12-15 2010-06-17 Microsoft Corporation Video Conferencing Subscription Using Multiple Bit Rate Streams
US20100172626A1 (en) * 2009-01-07 2010-07-08 Microsoft Corporation Trick Mode Based Advertisement Portion Selection
US20100199036A1 (en) 2009-02-02 2010-08-05 Atrato, Inc. Systems and methods for block-level management of tiered storage
US8307390B2 (en) * 2009-02-26 2012-11-06 Comcast Cable Communications, Llc Re-addressable alternate content
US9277266B2 (en) * 2009-03-18 2016-03-01 Time Warner Cable Enterprises Llc Apparatus and methods for network video recording
US9769504B2 (en) * 2009-03-31 2017-09-19 Comcast Cable Communications, Llc Dynamic distribution of media content assets for a content delivery network
US8843975B2 (en) 2009-04-10 2014-09-23 At&T Intellectual Property I, L.P. Method and apparatus for presenting dynamic media content
US8782267B2 (en) * 2009-05-29 2014-07-15 Comcast Cable Communications, Llc Methods, systems, devices, and computer-readable media for delivering additional content using a multicast streaming
US20110123173A1 (en) * 2009-11-24 2011-05-26 Verizon Patent And Licensing Inc. Trick play advertising systems and methods
US8539535B2 (en) 2009-11-30 2013-09-17 Time Warner Cable Enterprises Llc Methods and apparatus for supporting VOD requests in a system with hierarchical content stores
US9247312B2 (en) * 2011-01-05 2016-01-26 Sonic Ip, Inc. Systems and methods for encoding source media in matroska container files for adaptive bitrate streaming using hypertext transfer protocol
US8984144B2 (en) 2011-03-02 2015-03-17 Comcast Cable Communications, Llc Delivery of content

Patent Citations (98)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5542072A (en) * 1992-12-31 1996-07-30 Sony Corporation Database system and method for accessing the same
US5839068A (en) * 1995-02-21 1998-11-17 Hughes Electronics Corporation Method of delivering service voice announcements in a satellite telephony communication system
US6438596B1 (en) * 1995-09-04 2002-08-20 Kabushiki Kaisha Toshiba Video on demand system that presents users with a selection list of proposed videos for which server and network resources are available to immediately serve the selected video
US6449730B2 (en) * 1995-10-24 2002-09-10 Seachange Technology, Inc. Loosely coupled mass storage computer cluster
US6378130B1 (en) * 1997-10-20 2002-04-23 Time Warner Entertainment Company Media server interconnect architecture
US20030149988A1 (en) * 1998-07-14 2003-08-07 United Video Properties, Inc. Client server based interactive television program guide system with remote server recording
US20050028208A1 (en) * 1998-07-17 2005-02-03 United Video Properties, Inc. Interactive television program guide with remote access
US20050262542A1 (en) * 1998-08-26 2005-11-24 United Video Properties, Inc. Television chat system
US20020152364A1 (en) * 1998-10-30 2002-10-17 Kasenna, Inc. Media server system and process having device independent near-online storage support
US6272598B1 (en) * 1999-03-22 2001-08-07 Hewlett-Packard Company Web cache performance by applying different replacement policies to the web cache
US20020061012A1 (en) * 1999-04-13 2002-05-23 Thi James C. Cable modem with voice processing capability
US6473858B1 (en) * 1999-04-16 2002-10-29 Digeo, Inc. Method and apparatus for broadcasting data with access control
US6774926B1 (en) * 1999-09-03 2004-08-10 United Video Properties, Inc. Personal television channel system
US20020007491A1 (en) * 2000-01-13 2002-01-17 Schiller Jay B. Method and apparatus for identifying a signal route for delivery of video-on-demand to a subscriber terminal
US20020016970A1 (en) * 2000-06-14 2002-02-07 Shinji Negishi Data conversion apparatus and method, data distribution apparatus and method, and data distribution system
US20080298773A1 (en) * 2000-11-17 2008-12-04 Masahiro Honjo Method and apparatus for recording/reproduction
US20020154892A1 (en) * 2001-02-13 2002-10-24 Hoshen-Eliav System for distributing video and content on demand
US20020131428A1 (en) * 2001-03-13 2002-09-19 Vivian Pecus Large edge node for simultaneous video on demand and live streaming of satellite delivered content
US7065778B1 (en) * 2001-05-25 2006-06-20 Enreach Technologies, Inc. Method and system for providing media from remote locations to a viewer
US8166510B1 (en) * 2001-07-17 2012-04-24 Vixs Systems, Inc. Method and apparatus for distributing video on demand loading
US7080400B1 (en) * 2001-08-06 2006-07-18 Navar Murgesh S System and method for distributed storage and presentation of multimedia in a cable network environment
US20030118243A1 (en) * 2001-09-18 2003-06-26 Ugur Sezer Largest magnitude indices selection for (run, level) encoding of a block coded picture
US7860948B2 (en) * 2001-09-26 2010-12-28 Telefonaktiebolaget L M Ericsson (Publ) Hierarchical caching in telecommunication networks
US20030097663A1 (en) * 2001-11-19 2003-05-22 Matti Puputti Method and apparatus for dynamic provisioning of IP-based services in a DVB network
US20080071859A1 (en) * 2002-02-14 2008-03-20 Level 3 Communications, Llc Popularity-based selective replication in content delivery network
US7764863B1 (en) * 2002-03-06 2010-07-27 Bigband Networks Inc. System and method for providing trick modes
US20030217113A1 (en) * 2002-04-08 2003-11-20 Microsoft Corporation Caching techniques for streaming media
US20040246376A1 (en) * 2002-04-12 2004-12-09 Shunichi Sekiguchi Video content transmission device and method, video content storage device, video content reproduction device and method, meta data generation device, and video content management method
US20040244058A1 (en) * 2002-05-03 2004-12-02 Carlucci John B. Programming content processing and management system and method
US7822862B2 (en) * 2002-06-07 2010-10-26 Hewlett-Packard Development Company, L.P. Method of satisfying a demand on a network for a network resource
US20050275758A1 (en) * 2002-06-21 2005-12-15 Alcatel Recording and playback system
US20080270610A1 (en) * 2002-07-24 2008-10-30 Kasenna, Inc. System and metehod for highly scalable real-time and time-based data delivery using server clusters
US20040093618A1 (en) * 2002-11-07 2004-05-13 Baldwin James Armand Trick mode support for VOD with long intra-frame intervals
US20040103437A1 (en) * 2002-11-26 2004-05-27 Concurrent Computer Corporation, A Delaware Corporation Video on demand management system
US20040103120A1 (en) * 2002-11-27 2004-05-27 Ascent Media Group, Inc. Video-on-demand (VOD) management system and methods
US20040107436A1 (en) * 2002-11-29 2004-06-03 Fujitsu Limited Digital broadcast signal distribution system and subscriber terminal
US20040110468A1 (en) * 2002-12-10 2004-06-10 Perlman Stephen G. Wireless network with presentation and media layers for broadcast satellite and cable services
US20040117850A1 (en) * 2002-12-11 2004-06-17 Jeyhan Karaoguz Media exchange network having media processing systems and personal computers with common user interfaces
US7454424B2 (en) * 2003-01-16 2008-11-18 Hewlett-Packard Development Company, L.P. System and method for efficiently replicating a file
US7404201B2 (en) * 2003-02-14 2008-07-22 Hitachi, Ltd. Data distribution server
US20060277581A1 (en) * 2003-03-10 2006-12-07 Avraham Eliyahu Local entity and a method for providing media streams
US20040187160A1 (en) * 2003-03-17 2004-09-23 Qwest Communications International Inc. Methods and systems for providing video on demand
US7143170B2 (en) * 2003-04-30 2006-11-28 Akamai Technologies, Inc. Automatic migration of data via a distributed computer network
US20060146040A1 (en) * 2003-06-30 2006-07-06 Koninklijke Philips Electronics N.V. Trick play using crt scan modes
US20090083806A1 (en) * 2003-10-10 2009-03-26 Microsoft Corporation Media organization for distributed sending of media data
US20070140647A1 (en) * 2003-12-19 2007-06-21 Yoshiaki Kusunoki Video data processing method and video data processing apparatus
US20050188055A1 (en) * 2003-12-31 2005-08-25 Saletore Vikram A. Distributed and dynamic content replication for server cluster acceleration
US20050267948A1 (en) * 2004-06-01 2005-12-01 Mckinley Brittain Method and system for resource management in a video on-demand server
US20060005224A1 (en) * 2004-06-30 2006-01-05 John Dunning Technique for cooperative distribution of video content
US20060020995A1 (en) * 2004-07-20 2006-01-26 Comcast Cable Communications, Llc Fast channel change in digital media systems
US20060085553A1 (en) * 2004-10-05 2006-04-20 Jon Rachwalski Method and system for broadcasting multimedia data
US20060085816A1 (en) * 2004-10-18 2006-04-20 Funk James M Method and apparatus to control playback in a download-and-view video on demand system
US20060218607A1 (en) * 2005-03-09 2006-09-28 Vvond, Inc. System and method for trick play of highly compressed video data
US7350041B1 (en) * 2005-08-26 2008-03-25 Emc Corporation Methods and apparatus for managing the storage of content
US20070143457A1 (en) * 2005-12-16 2007-06-21 Weidong Mao Method of using tokens and policy descriptors for dynamic on demand session management
US20080155614A1 (en) * 2005-12-22 2008-06-26 Robin Ross Cooper Multi-source bridge content distribution system and method
US20070157281A1 (en) * 2005-12-23 2007-07-05 United Video Properties, Inc. Interactive media guidance system having multiple devices
US7962942B1 (en) * 2006-02-28 2011-06-14 Rovi Guides, Inc. Systems and methods for enhanced trick-play functions
US20070276926A1 (en) * 2006-05-24 2007-11-29 Lajoie Michael L Secondary content insertion apparatus and methods
US7761900B2 (en) * 2006-08-02 2010-07-20 Clarendon Foundation, Inc. Distribution of content and advertisement
US20080124052A1 (en) * 2006-08-31 2008-05-29 Opentv, Inc. Systems and methods to modify playout or playback
US20100146139A1 (en) * 2006-09-29 2010-06-10 Avinity Systems B.V. Method for streaming parallel user sessions, system and computer software
US20080148327A1 (en) * 2006-12-18 2008-06-19 General Instrument Corporation Method and Apparatus for Providing Adaptive Trick Play Control of Streaming Digital Video
US20080187283A1 (en) * 2006-12-29 2008-08-07 Broadband Royalty Corporation Source optimized dynamic trickplay
US7886069B2 (en) * 2007-01-05 2011-02-08 Divx, Llc Video distribution system including progressive playback
US20080168133A1 (en) * 2007-01-05 2008-07-10 Roland Osborne Video distribution system including progressive playback
US20080209491A1 (en) * 2007-02-28 2008-08-28 Hasek Charles A Personal content server apparatus and methods
US20080253406A1 (en) * 2007-04-16 2008-10-16 Time Warner Cable Inc. Transport stream encapsulated trick modes
US7941823B2 (en) * 2007-04-16 2011-05-10 Time Warner Cable Inc. Transport stream encapsulated trick modes
US20080307479A1 (en) * 2007-06-11 2008-12-11 Alcatel Lucent Bandwidth-Efficient Deployment of Video-On-Demand Assets in an IPTV Network
US7802286B2 (en) * 2007-07-24 2010-09-21 Time Warner Cable Inc. Methods and apparatus for format selection for network optimization
US20090031390A1 (en) * 2007-07-26 2009-01-29 Broadcom Corporation Method and apparatus for synchronized transmission and reception of audiovisual data and index data in internet protocol television applications for implementing remote network record with instant personal video recorder support
US20090049186A1 (en) * 2007-08-16 2009-02-19 Sony Corporation, A Japanese Corporation Method to facilitate trick-modes for streaming video
US20100246670A1 (en) * 2007-08-29 2010-09-30 Akira Takemoto Method for generating video data for trick play
US20110099332A1 (en) * 2007-08-30 2011-04-28 Alcatel-Lucent Usa Inc. Method and system of optimal cache allocation in iptv networks
US20090083813A1 (en) * 2007-09-26 2009-03-26 Verivue, Inc. Video Delivery Module
US20090113068A1 (en) * 2007-10-31 2009-04-30 Hitachi, Ltd. Content delivery system, cache server, and cache control server
US20090119322A1 (en) * 2007-11-07 2009-05-07 Mills Brendon W System and method for managing content
US20090136204A1 (en) * 2007-11-26 2009-05-28 Yueh-Hua Chen System and method for remote live pause
US20100312861A1 (en) * 2007-11-30 2010-12-09 Johan Kolhi Method, network, and node for distributing electronic content in a content distribution network
US20090158326A1 (en) * 2007-12-18 2009-06-18 Hunt Neil D Trick Play of Streaming Media
US20090161765A1 (en) * 2007-12-21 2009-06-25 General Instrument Corporation Enabling Trick Plays during VBR Playback of a CBR Transmitted Media File
US20090249419A1 (en) * 2008-03-25 2009-10-01 Kahn Brian E Method and System of Queued Management of Multimedia Storage
US20090271818A1 (en) * 2008-04-28 2009-10-29 General Instrument Corporation Method And Apparatus For Delivering Emergency Alert System (EAS) Messages Over A Switched Digital Video (SDV) System
US20090292526A1 (en) * 2008-05-20 2009-11-26 Aol Llc Monitoring conversations to identify topics of interest
US20090307329A1 (en) * 2008-06-06 2009-12-10 Chris Olston Adaptive file placement in a distributed file system
US20090310933A1 (en) * 2008-06-17 2009-12-17 Microsoft Corporation Concurrently Displaying Multiple Trick Streams for Video
US20100003008A1 (en) * 2008-07-01 2010-01-07 Cisco Technology, Inc. Dynamically Creating Trick Files To Hide Latency In Streaming Networks
US20100058405A1 (en) * 2008-08-29 2010-03-04 At&T Corp. Systems and Methods for Distributing Video on Demand
US20100082349A1 (en) * 2008-09-29 2010-04-01 Apple Inc. Systems and methods for selective text to speech synthesis
US20100094969A1 (en) * 2008-10-15 2010-04-15 Patentvc Ltd. Reduction of Peak-to-Average Traffic Ratio in Distributed Streaming Systems
US20100115575A1 (en) * 2008-11-03 2010-05-06 At&T Intellectual Property I, L.P. System and method for recording and distributing media content
US20100122282A1 (en) * 2008-11-10 2010-05-13 Time Warner Cable Inc. System and method for enhanced advertising in a video content network
US7991883B1 (en) * 2008-12-15 2011-08-02 Adobe Systems Incorporated Server communication in a multi-tier server architecture
US20100202509A1 (en) * 2009-02-10 2010-08-12 Cisco Technology, Inc. Near real time delivery of variable bit rate media streams
US20100218208A1 (en) * 2009-02-26 2010-08-26 Comcast Cable Communications, Llc Method and Apparatus for Generating Alternative Commercials
US20100251305A1 (en) * 2009-03-30 2010-09-30 Dave Kimble Recommendation engine apparatus and methods
US20100251304A1 (en) * 2009-03-30 2010-09-30 Donoghue Patrick J Personal media channel apparatus and methods

Cited By (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9769504B2 (en) 2009-03-31 2017-09-19 Comcast Cable Communications, Llc Dynamic distribution of media content assets for a content delivery network
US20100250773A1 (en) * 2009-03-31 2010-09-30 Comcast Cable Communications, Llc Dynamic generation of media content assets for a content delivery network
US20100250772A1 (en) * 2009-03-31 2010-09-30 Comcast Cable Communications, Llc Dynamic distribution of media content assets for a content delivery network
US11356711B2 (en) 2009-03-31 2022-06-07 Comcast Cable Communications, Llc Dynamic distribution of media content assets for a content delivery network
US10701406B2 (en) 2009-03-31 2020-06-30 Comcast Cable Communications, Llc Dynamic distribution of media content assets for a content delivery network
US20160007053A1 (en) * 2009-03-31 2016-01-07 Comcast Cable Communications, Llc Dynamic Generation of Media Content Assets for a Content Delivery Network
US9729901B2 (en) * 2009-03-31 2017-08-08 Comcast Cable Communications, Llc Dynamic generation of media content assets for a content delivery network
US9055085B2 (en) * 2009-03-31 2015-06-09 Comcast Cable Communications, Llc Dynamic generation of media content assets for a content delivery network
US20110191439A1 (en) * 2010-01-29 2011-08-04 Clarendon Foundation, Inc. Media content ingestion
US9438935B2 (en) * 2010-11-23 2016-09-06 Verizon Patent And Licensing Inc. Hybrid video selection, delivery, and caching
EP2728891A3 (en) * 2010-12-08 2014-09-03 Ericsson Television Inc. Systems and methods for distributed authentication of video services
US20150180968A1 (en) * 2011-03-02 2015-06-25 Comcast Cable Communications, Llc Delivery of content
US8984144B2 (en) * 2011-03-02 2015-03-17 Comcast Cable Communications, Llc Delivery of content
US10033804B2 (en) * 2011-03-02 2018-07-24 Comcast Cable Communications, Llc Delivery of content
US20120226770A1 (en) * 2011-03-02 2012-09-06 Comcast Cable Communications, Llc Delivery of Content
US9253051B2 (en) * 2012-02-23 2016-02-02 Ericsson Ab System and method for delivering content in a content delivery network
US9438487B2 (en) 2012-02-23 2016-09-06 Ericsson Ab Bandwith policy management in a self-corrected content delivery network
US9800683B2 (en) 2012-02-23 2017-10-24 Ericsson Ab Bandwidth policy management in a self-corrected content delivery network
US20150012593A1 (en) * 2012-02-23 2015-01-08 Ericsson Television Inc. System and method for delivering content in a content delivery network
US20140095457A1 (en) * 2012-10-02 2014-04-03 Nextbit Systems Inc. Regulating data storage based on popularity
AU2013331512B2 (en) * 2012-10-17 2018-08-30 Netflix, Inc. Partitioning streaming media files on multiple content distribution networks
US9699519B2 (en) * 2012-10-17 2017-07-04 Netflix, Inc. Partitioning streaming media files on multiple content distribution networks
CN104737149A (en) * 2012-10-17 2015-06-24 奈飞公司 Partitioning streaming media files on multiple content distribution networks
US20140108671A1 (en) * 2012-10-17 2014-04-17 Netflix, Inc Partitioning streaming media files on multiple content distribution networks
WO2015172071A1 (en) * 2014-05-08 2015-11-12 Tank Design, Inc. Systems and methods for location-dependent electronic communications
US10715837B2 (en) * 2015-03-13 2020-07-14 At&T Intellectual Property I, L.P. Determination of a service office of a media content distribution system to record a media content item with a network recorder
US20160269688A1 (en) * 2015-03-13 2016-09-15 At&T Intellectual Property I, L.P. Determination of a service office of a media content distribution system to record a media content item with a network recorder
US9883221B1 (en) 2015-03-25 2018-01-30 Concurrent Computer Corporation System and method for optimizing real-time video-on-demand recording in a content delivery network
US20230118793A1 (en) * 2021-10-15 2023-04-20 Netflix, Inc. Dynamic content steering based on server and client device capabilities
US11722707B2 (en) * 2021-10-15 2023-08-08 Netflix, Inc Dynamic content steering based on server and client device capabilities

Also Published As

Publication number Publication date
US9055085B2 (en) 2015-06-09
US20180184132A1 (en) 2018-06-28
US20100250772A1 (en) 2010-09-30
US20200280745A1 (en) 2020-09-03
US11356711B2 (en) 2022-06-07
US20160007053A1 (en) 2016-01-07
US10701406B2 (en) 2020-06-30
US9769504B2 (en) 2017-09-19
US9729901B2 (en) 2017-08-08
US20100250773A1 (en) 2010-09-30
US20200280744A1 (en) 2020-09-03

Similar Documents

Publication Publication Date Title
US11356711B2 (en) Dynamic distribution of media content assets for a content delivery network
US11800171B2 (en) Apparatus and methods for recording a media stream
US7860950B2 (en) Metadata enabled push-pull model for efficient low-latency video-content distribution over a network
US11477521B2 (en) Media presentation description patches for video streaming
JP4436137B2 (en) Distributed storage network architecture using user equipment
US9462339B2 (en) Systems and methods for distributing video on demand
US9621928B2 (en) Streaming playback and dynamic ad insertion
US9503765B2 (en) Averting ad skipping in adaptive bit rate systems
US8543660B2 (en) Systems and methods for bridging and managing media content associated with separate media content networks
US20090158362A1 (en) Method and apparatus for provisioning media assets at edge locations for distribution to subscribers in a hierarchical on-demand media delivery system
Verhoeyen et al. Content storage architectures for boosted IPTV service
US11811838B1 (en) Generation of unique presentation of media content
Pan et al. CS237 Project Interactive Movie Streaming Service

Legal Events

Date Code Title Description
AS Assignment

Owner name: COMCAST CABLE COMMUNICATIONS, LLC, PENNSYLVANIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:MAO, WEIDONG;REEL/FRAME:024408/0405

Effective date: 20100519

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION