Patent Grant
10687115
A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever.
The present disclosure relates generally to the field of delivery of digital content over a network, and in one exemplary aspect to a network architecture for providing a cloud-based Digital Video Recorder (DVR) and compression storage functionality, including delivery to Internet Protocol (IP)-enabled client devices.
Digital video recorders (DVRs) and personal video recorders (PVRs) are devices which record video content, in digital format, to a disk drive or other medium. The use of such devices is now ubiquitous, and they provide conveniences to TV viewers such as e.g., (i) allowing a user to record a program for later review, (ii) allowing a user to record every episode of a program for a period, and/or (iii) automatically recording programs for the user based on viewing habits and preferences. Further, the presentation of the recorded programming content can be manipulated by exercising rewind, pause, play, stop, and fast-forward functions (hereinafter referred to as “trick mode” functions) in such DVRs and PVRs.
Traditional DVRs are maintained and managed by an end user; e.g., subscriber of a cable or satellite network. While having utility, such premises recording devices have several disabilities, including the need for the user to possess the physical “box”, the need to maintain the recording or storage device powered up at all times when recording may be required, as well as the finite storage volume limitations of the device (the latter which can effectively limit the user's selection for content).
Such disabilities have made providing virtual ownership of content delivery and virtual storage, i.e., storage in the “cloud”, more appealing over time. One such cloud-based approach is the so-called “nPVR” or network PVR. An nPVR is a form of a PVR which can store content on a remote network device instead of a local storage medium such as a DVR. The nPVR allows the user to perform the analogous DVR functions through use of a network entity or process, rather than a local DVR at the user premises, thereby ostensibly relieving the user of the burdens of ownership and maintenance of a DVR unit, and providing greater digital data storage capacity.
Moreover, physically secure storage of content at the content distribution network as opposed to the premises may also provide certain assurances regarding physical security and unauthorized reproduction.
Numerous nPVR architectures exist. See, e.g., co-owned U.S. patent application Ser. No. 10/302,550, filed Nov. 22, 2002, issued as U.S. Pat. No. 7,073,189 on Jul. 4, 2006, and entitled “Program Guide and Reservation System for Network Based Digital Information and Entertainment Storage and Delivery System”, incorporated by reference herein in its entirety, which discloses one exemplary network architecture and functionalities for implementing nPVR service. Generally, nPVR systems employ Video on-demand (VOD) or similar architecture of a content distribution network (CDN) to provide content storage and retrieval.
Similarly, so called “start-over” is a feature offered to some network users which allows the user to jump to the beginning of a program in progress without any preplanning or in-home recording devices (e.g., DVR). Start-over is enabled by a software upgrade to the existing video on-demand (VOD) platform, and to the installed base of digital set-top boxes. In other words, the start-over feature utilizes an nPVR system to maintain content which users may request, and delivers content in a manner similar to VOD. The typical start-over system instantaneously captures live television programming for immediate, on-demand viewing. Start-over functionality is the result of MSO-initiated nPVR storage of broadcast programs in real time. In other words, the MSO determines which programs will be start-over enabled, and stores this content as it is broadcast to an nPVR which is accessible by the various client devices utilizing a mechanism similar to VOD (discussed below).
When tuning to a start-over enabled show in progress, customers are alerted to the feature through an on-screen prompt. By pressing appropriate remote control buttons, the program is restarted from the beginning. Under one type of approach, start-over enabled programs may only be restarted within the shows' original telecast window (i.e., during the time window set for broadcasting the program), and may not be restarted after the show has finished broadcast. Thus, the start-over feature generally functions as an nPVR for predefined content (i.e., content on a start-over enabled channel) during a predefined period (i.e., the broadcast window). Co-owned, U.S. patent application Ser. No. 10/913,064, filed Aug. 6, 2004, and entitled “Technique for Delivering Programming Content Based on a Modified Network Personal Video Recorder Service”, incorporated herein by reference in its entirety, discloses exemplary network architecture and functionalities for implementing start-over service within a content-based (e.g., cable) network.
As noted above, start-over services generally employ a VOD or similar architecture to provide content storage and retrieval. A typical prior art VOD architecture useful for prior art nPVR and start-over functionality is shown in
As illustrated, audio/video content is received by the MSO. The MSO sends the content to a staging processor 102 adapted to “stage” content for transmission over the network. The staging processor 102 is an entity adapted to prepare content for segmenting and/or for transmission to a VOD server 105 for streaming to one or more users.
Content is prepared for transmission and/or segmenting by processing through various staging processes, or software applications adapted to run on the digital processor associated with the staging processor 102. The processes effected by the staging processor 102 include, inter alia, at least one segmenting process 104. The segmenting process 104 divides the content video feed on valid GOP boundaries, or I-frames.
Segmenting the video feed at the segmenting process 104 results in content which is segmented based on a schedule. The segmented content is then examined by a business management process (BMS) 107. The management process 107, inter alia, creates a data file regarding the segmented content. The data file gives metadata regarding the content and “points” to the segmented portions of the content on the disk.
Once the management process 107 has created a data file for the content, it is sent to a VOD server 105. As described in greater detail subsequently herein, the VOD server 105 stores the content and/or data on hard disks; the VOD server 105 streams the content from these disks as well. The VOD server 105 is also sent a playlist of advertisements.
The VOD server 105, therefore, will receive the segmented content as well as a file indicating where the various portions of the content are and in what order they should be arranged; the VOD server also receives advertisements for insertion into the segmented content.
When a CPE 106 requests the content from the VOD server 105 via the network 101, the VOD server 105 utilizes the data file (not shown) created by the management process 107 to find the start 124 and end 126 points of the content segments 122, and the start 134 and end 136 points for the advertisement segments 132. The first content segment 122a is delivered to the user, and at its end point 126a, the VOD server 105 sends the first advertisement segment 132a. At the end point 136a of the first advertisement segment 132a, the VOD server 105 sends the second content segment 122b. At the end point 126b of the second content segment 122b, the second advertisement segment 132b is sent. This pattern continues until the last of the content segments 122n and/or the last of the advertisement segments 132x have been presented to the user. The user will receive a seamless content-plus-advertisement stream 140 comprised of the various segments 122a, 132a, 122b, 132b . . . 122n, 132x sent. It is recognized that the first segment sent to the user may comprise either the first advertisement or the first content segment, still utilizing the pattern outlined above.
In nPVR and start-over enabled systems, MSOs ingest a large quantities of content to the VOD servers for storage and streaming, so as to offer the nPVR or start-over features on a variety of channels and/or for a variety of programs. Doing so quickly becomes exceedingly expensive. As the number of users or subscribers of services such as nPVR and start-over within a content delivery network grows, so does the required network-side digital data storage and processing capacity. To enable each given subscriber or household to record even a relatively limited number of hours of programming requires many terabytes (TB) of storage, which can be quite expensive to both initially procure and maintain.
Further, given that start-over capabilities are made available on a channel-by-channel basis, a large portion of the content stored and available for streaming from the VOD server is often never requested, such as during times when there are fewer viewers (e.g., between 12 midnight and 6 am). Thus, in the present systems, even when content is not requested, it must still be sent to the VOD server as discussed above.
Additionally, as described in greater detail below, most content is received by the network operator (e.g., cable or satellite network MSO) in an encoding format (such as MPEG-2) that is not optimized in terms of storage or downstream bandwidth delivery requirements. Hence, maintenance of both the storage and delivery infrastructure necessary to keep pace with literally millions of users wanting to record several hours of programming per day via their nPVR or start-over service or equivalent becomes unduly burdensome and at some point, cost-inefficient.
To further complicate matters, each user may have differing use profiles or recording/playback requirements; e.g., one user may record a number of shows early in a given day, and watch at least a portion of the recorded content later that same day (e.g., after arriving home from work) or the following weekend, and never access that particular content again (instead opting to repeat the foregoing pattern the next day). However, another user may routinely “squirrel away” programming of interest, such as e.g., an old Sci-Fi movie buff who stores broadcast old movies for one or more later “movie marathons”. Any number of different recording and usage patterns exist within the general subscriber population, thereby making a one-size-fits-all type solution to digital data storage and management untenable.
Mobility and Platform Heterogeneity
Another facet of current content delivery requirements relates to mobility; while prior content delivery paradigms (including nPVR and start-over) were largely centered on delivery to a fixed point or premises (i.e., a set-top box or satellite receiver in the user's home, to which one or more rendering devices such as televisions were connected) via purely a managed content distribution infrastructure, consumers currently demand the availability of digital content at any number of different locations, and via any number of different heterogeneous rendering platforms. For instance, a user may wish to cause recording of a given digital content element or program via a mobile user device such as a smartphone while away from their premises, and subsequently watch the recorded program via another modality (e.g., one with a larger screen, such as a wireless-enabled tablet, PC or Smart TV) at their premises. Or, while traveling, the user may wish to access previously recorded content on their tablet via e.g., a hotel's Wi-Fi or other broadband service.
Most any current personal electronic device or other rendering platform contains any number of video “players” (i.e., application software) which can render digitally encoded content received over, e.g., an Internet Protocol (IP) transport. Many so-called “cord cutters” are opting for delivery of digital content entirely via such transports; i.e., Internet-based content delivery services, whether free or for pay, such as Netflix, Hulu, and the like.
However, such Internet-based delivery paradigms can suffer several disabilities, including for example unreliable content delivery and rendering due to, inter alia, lack of Quality-of-Service (QoS) requirements associated with a typical broadband service provider. Moreover, availability of certain types of content (e.g., live sporting events, certain first-run movies, etc.) may be limited in such contexts. Hence, while the “cord cutting” model is on its face somewhat appealing, it is not optimized in many regards.
Video Encoding and Compression
Encoding utilizes one or more forms of video compression in order to economize on storage space and transmission bandwidth. Without such video compression, digital video content can require extremely large amounts of data storage capacity, making it difficult or even impossible for the digital video content to be efficiently stored, transmitted, or viewed.
Consequently, video coding standards have been developed to standardize the various video coding methods so that the compressed digital video content is rendered in formats that a majority of video decoders can recognize. For example, the Motion Picture Experts Group (MPEG) and International Telecommunication Union (ITU-T) have developed video coding standards that are in wide use. Examples of these standards include the MPEG-1, MPEG-2, MPEG-4, ITU-T H.261, and ITU-T H.263 standards. The MPEG-4 Advanced Video Coding (AVC) standard (also known as MPEG-4, Part 10) is a newer standard jointly developed by the International Organization for Standardization (ISO) and ITU-T. The MPEG-4 AVC standard is published as ITU-T H.264 and ISO/IEC 14496-10. For purposes of clarity, MPEG-4 AVC is referred to herein as H.264.
As noted above, content often arrives from content sources at a content distribution network (CDN) in a digitally encoded format, such as MPEG-2. The MPEG-2 standard is ubiquitous and specifies, inter alia, methodologies for video and audio data compression and encoding. Specifically, in accordance with the MPEG-2 standard, video data is compressed based on a sequence of GOPs, made up of three types of picture frames: coded picture frames (“I-frames”), forward predictive frames (“P-frames”) and bilinear frames (“B-frames”). Each GOP may, for example, begin with an I-frame which is obtained by spatially compressing a complete picture using discrete cosine transform (DCT). As a result, if an error or a channel switch occurs, it is possible to resume correct decoding at the next I-frame. The GOP may represent additional frames by providing a much smaller block of digital data that indicates how small portions of the I-frame, referred to as macroblocks, move over time.
MPEG-2 achieves its compression by assuming that only small portions of an image change over time, making the representation of these additional frames compact. Although GOPs have no relationship between themselves, the frames within a GOP have a specific relationship which builds off the initial I-frame.
In a traditional content delivery scheme (e.g., for a cable network), the compressed video and audio data are carried by continuous elementary streams, respectively, which are broken into access units or packets, resulting in packetized elementary streams (PESs). These packets are identified by headers that contain time stamps for synchronizing, and are used to form MPEG-2 transport streams, which utilize MPEG-2 encoded video content as their payload.
However, despite its ubiquity, MPEG-2 has salient limitations, especially relating to transmission bandwidth and storage. The more recently developed H.264 video coding standard is able to compress video much more efficiently than earlier video coding standards, including MPEG-2. H.264 is also known as MPEG-4 Part 10 and Advanced Video Coding (AVC). H.264 exhibits a combination of new techniques and increased degrees of freedom in using existing techniques. Among the new techniques defined in H.264 are 4×4 discrete cosine transform (DCT), multi-frame prediction, context adaptive variable length coding (CAVLC), SI/SP frames, and context-adaptive binary arithmetic coding (CABAC). The increased degrees of freedom come about by allowing multiple reference frames for prediction and greater macroblock flexibility. These features add to the coding efficiency (at the cost of increased encoding and decoding complexity in terms of logic, memory, and number of operations). Notably, the same content encoded within H.264 can be transmitted with only roughly half (50%) of the requisite bandwidth of a corresponding MPEG-2 encoding, thereby providing great economies in terms of CDN infrastructure and content storage.
Digital encoding also advantageously lends itself to transcoding of content. As used herein, the term “transcoding” refers generally to the process of changing content from one encoding to another. This may be accomplished for example by decoding the encoded content, and then re-encoding this into the target format. Transcoding can also accomplish the encoding of content to a lower bitrate without changing video formats, a process that is known as transrating.
Transcoding is used in many areas of content adaptation; however, it is commonly employed in the area of mobile devices such as smartphones, tablets, and the like. In such mobile applications, transcoding is essential due to the diversity of mobile devices. This diversity effectively requires an intermediate state of content adaptation, so as to ensure that the source content will adequately present or “render” on the target mobile device.
It should be noted that there is a price to pay for such transcoding; however, compression artifacts are typically cumulative, and therefore transcoding between “lossy” codecs (which include both MPEG-2 and H.264/AVC) causes a progressive loss of quality with each successive iteration. It is therefore desirable to minimize the number of transcodes of content; e.g., obtain a copy of the content in a lossless format, and then encode directly from the lossless source file to the “target” lossy format(s) required, thereby causing the minimum degradation, or only transcode once if possible. Transmission of lossless format data over a CDN (especially to wireless-enabled mobile devices) is simply untenable under present technology due to bandwidth limitations.
Delivery of encoded content may also utilize a technology known as “adaptive bitrate streaming”. Adaptive bitrate (ABR) streaming is a technique to distribute program content over a large distributed network in an efficient manner based on, inter alia, available streaming capacity. In one implementation, multiple bitrates of a particular piece of content are available to stream to a viewer, and the selection of the bitrate is based on current network conditions. This means that when there is greater bandwidth availability, a larger bitrate version of the content may be selected. If available bandwidth narrows, a lower bitrate (i.e., smaller) version of the content may be selected to provide a seamless user experience. Typical ABR streaming solutions include e.g., DASH (dynamic adaptive streaming over HTTP), Microsoft Smooth Streaming, and Adobe HTTP Dynamic Streaming, which are further particularly adapted for HTTP-based environments such as Internet delivery. ABR streaming protocols are typically codec-agnostic (e.g., may use content encoded in e.g., H.264, MPEG-2, or others), and are notably distinguishable from such underlying encoding.
Based on the foregoing, there is a salient need for improved apparatus and methods of recording and delivering digitally rendered content to a large number of users associated with a content delivery network. Such improved apparatus and methods would ideally allow the users a great degree of freedom in the recording and delivery of content available over the network, including: (i) the types of devices which could receive the content (including without being tied to a set-top box); (ii) the ability to receive the content at various physical locations via various transport modalities; and (iii) the ability to easily cause recording and retrieval of content. Likewise, such improved apparatus and methods would enable the network operator to store large volumes of data in “the cloud” in a space- and cost-efficient manner, and also deliver respective content to many different individual network users simultaneously in a bandwidth-efficient manner, while preserving suitable rendering quality and temporal aspects (i.e., avoiding “stutters” or other non-linearities in service commonly associated with e.g., Internet-based delivery models).
The present disclosure addresses the foregoing needs by providing, inter alia, methods and apparatus for efficient network or “cloud” storage of digital content and delivery to users.
In one aspect of the disclosure, a method of managing content within a content delivery network for at least one of a plurality of users of the network is disclosed. In one embodiment, the method includes: receiving at an entity of the network a request to record content from a client device associated with the at least one of the plurality of users of the network; based at least in part on the request, causing at least a first portion of the content to be stored on a first storage device of the network, the at least first portion of the content stored at a storage location specifically associated with the at least one user; and causing at least a second portion of the content to be stored at a storage location not specific to the at least one user.
In one variant, the method further includes: subsequent to the causing the at least first and second portions to be stored, receiving a request from the at least one user to access the content; and based at least on the request to access the content, assembling the content from both the storage location specifically associated with the at least one user and the storage location not specific to the at least one user.
In one implementation, the assembling the content comprises assembling the content from both: (i) the storage location specifically associated with the at least one user, and the storage location not specific to the at least one user; and (ii) a storage location associated with a different one of the plurality of users.
In another aspect, a method of operating a content delivery network having a plurality of users is disclosed. In one embodiment, the method includes: receiving at least one content element from a content source; receiving a plurality of requests from respective ones of the plurality of users to record the at least one content element; based at least on the plurality of requests, recording respective ones of first versions of the at least one content element, each of the respective ones of the versions accessible only by the respective one of the plurality of users; and after expiration of a period of time, storing respective second versions of the at least one content element, the second versions being compressed with respect to the first versions thereof, and at least a portion of each of the second versions accessible by one or more users other than the respective user associated with the respective second version.
In a further aspect, a content delivery network architecture configured to service a plurality of users is disclosed. In one embodiment, the architecture includes: a first storage repository configured to store ingested content elements obtained from a content source; a second storage repository in data communication with the first storage repository and configured to provide storage of at least first portions of each of the ingested content elements, respective ones of the at least first portions being uniquely associated with respective ones of the plurality of users; and a third storage repository in data communication with at least the first data storage repository and configured to provide storage of at least second portions of each of the ingested content elements, the at least second portions not being uniquely associated with any of the users.
In one variant, the architecture achieves storage compression at least through configuration to, in response to a content element access request from a respective ones of the users, utilize both a respective unique first portion of the content element from the first storage repository and a second portion of the content element from the second data repository to service the request.
In another aspect, a content delivery network apparatus configured to service content requests from a plurality of users is disclosed. In one embodiment, the apparatus includes: at least one data interface for data communication; processing apparatus in data communication with the at least one interface; storage apparatus in data communication with the processing apparatus and comprising at least one computer program. In one variant, the at least one program is configured to, when executed on the processing apparatus: store within a first storage repository in data communication with the interface, the content element in its entirety, the first repository configured to store ingested content elements obtained from a content source and comprising a plurality of storage locations uniquely associated with respective ones of a plurality of the users; thereafter, upon expiry of a prescribed period of time after receipt of a recording request relating to a content element, the request originated by one of the plurality of users, access the first storage repository to retrieve the content element, the retrieved content element comprising a plurality of segments; utilize an allocation algorithm to allocate the plurality of segments of the content element into at least first and second portions each having some of the plurality of segments, the at least first portion being uniquely associated with the user, and the at least second portion being unassociated with any of the plurality of users; store the at least first portion within a second storage repository in data communication with the interface, the first repository comprising a plurality of storage locations uniquely associated with respective ones of a plurality of the users; and store the at least second portion within a second storage repository in data communication with the interface.
In yet another aspect, a method of managing content within a content delivery network for at least one of a plurality of users of the network is disclosed. In one embodiment, the method includes: receiving at an entity of the network a request to record content from a client device associated with the at least one of the plurality of users of the network; and based at least in part on the request: causing a first portion of the content to be stored on a first storage device of the network, the first portion of the content stored at a storage location specifically associated with the at least one user, the first storage device located at a first portion of the network; and causing at least one representation of a second portion of the content to be stored on a second storage device of the network, the at least one representation comprising a complement of the first portion and being stored at a storage location not specific to the at least one user, the second storage device located at a second portion of the network different from the first and providing reduced content transport cost as compared to the first portion of the network.
In another embodiment, the method includes: receiving at an entity of the network a request to access recorded content, the request initiated from a client device associated with the at least one of the plurality of users; and based at least in part on the request: causing a first portion of the content to be accessed from a first storage device of the network, the first portion of the content stored at a storage location specifically associated with the at least one user; delivering the accessed first portion of the content to the client device via a first transport; causing at least one representation of a second portion of the content to be accessed from a second storage device, the second portion stored at a storage location not specific to the at least one user; and delivering the accessed second portion of the content to the client device via a second transport distinct from the first.
In yet another embodiment, the method includes: receiving at an entity of the network a request to record content from a client device associated with the at least one of the plurality of users of the network; and based at least in part on the request: causing a first portion of the content to be stored on a first storage device of the network, the first portion of the content stored at a storage location specifically associated with the at least one user; and causing multiple representations of a second portion of the content to be stored at a storage location not specific to the at least one user, the second portion being a complement to the first portion. In one variant of the method, the storage of the first portion and the multiple representations of the second portion enables creation of a plurality of content-identical yet physically unique versions of the content.
In another aspect of the disclosure, a server apparatus for processing and delivering recorded content is described. In one embodiment, the server apparatus includes: a first interface configured to communicate with a network; a storage apparatus; and a processor apparatus configured to execute at least one computer program, the at least one computer program comprising a plurality of instructions.
In a further aspect, a non-transitory computer readable apparatus is disclosed. In one embodiment, the apparatus includes a storage medium having one or more computer programs disposed thereon.
In yet another aspect, a client device is disclosed. In one embodiment, the client device comprises a wireless-enabled mobile device capable of rendering video and audio content thereon according to a prescribed encoding and protection format (e.g., MPEG-4/AVC, and DRM), and further includes an application computer program configured to enable access to cloud-based content via a network interface to a network server managing streaming of the cloud-based content.
These and other aspects shall become apparent when considered in light of the disclosure provided herein.
All figures © Copyright 2016 Time Warner Cable Enterprises LLC. All rights reserved.
Reference is now made to the drawings wherein like numerals refer to like parts throughout.
As used herein, the term “application” refers generally and without limitation to a unit of executable software that implements a certain functionality or theme. The themes of applications vary broadly across any number of disciplines and functions (such as on-demand content management, e-commerce transactions, brokerage transactions, home entertainment, calculator, etc.), and one application may have more than one theme. The unit of executable software generally runs in a predetermined environment; for example, the unit could include a downloadable Java Xlet™ that runs within the JavaTV™ environment.
As used herein, the term “client device” includes, but is not limited to, set-top boxes (e.g., DSTBs), gateways, modems, personal computers (PCs), and minicomputers, whether desktop, laptop, or otherwise, and mobile devices such as handheld computers, PDAs, personal media devices (PMDs), tablets, “phablets”, smartphones, Smart TVs, USB-based devices, Internet-based content streaming devices, and vehicle infotainment or navigation systems.
As used herein, the term “codec” refers to a video, audio, or other data coding and/or decoding algorithm, process or apparatus including, without limitation, those of the MPEG (e.g., MPEG-1, MPEG-2, MPEG-4, AVC/H.264, etc.), Real (RealVideo, etc.), AC-3 (audio), DiVX, XViD/ViDX, Windows Media Video (e.g., WMV 7, 8, 9, 10, or 11), ATI Video codec, or VC-1 (SMPTE standard 421M) families.
As used herein, the term “computer program” or “software” is meant to include any sequence of human or machine cognizable steps which perform a function. Such program may be rendered in virtually any programming language or environment including, for example, C/C++, Fortran, COBOL, PASCAL, assembly language, markup languages (e.g., HTML, SGML, XML, VoXML), and the like, as well as object-oriented environments such as the Common Object Request Broker Architecture (CORBA), Java™ (including J2ME, Java Beans, etc.) and the like.
The term “Customer Premises Equipment (CPE)” refers without limitation to any type of electronic equipment located within a customer's or subscriber's premises and connected to or in communication with a network.
As used herein, the term “database” refers generally to one or more tangible or virtual data storage locations, which may or may not be physically co-located with each other or other system components.
As used herein, the term “display” means any type of device adapted to display information, including without limitation CRTs, LCDs, TFTs, plasma displays, LEDs (e.g., OLEDs), incandescent and fluorescent devices, or combinations/integrations thereof. Display devices may also include less dynamic devices such as, for example, printers, e-ink devices, and the like.
As used herein, the term “DOCSIS” refers to any of the existing or planned variants of the Data Over Cable Services Interface Specification, including for example DOCSIS versions 1.0, 1.1, 2.0, 3.0 and 3.1.
As used herein, the term “digital video recorder” refers generally to any type of recording mechanism and/or software environment, located in the headend, the user premises or anywhere else, whereby content sent over a network can be recorded and selectively recalled. Such recorder may be dedicated in nature, or part of a non-dedicated or multi-function system.
As used herein, the term “headend” refers generally to a networked system controlled by an operator (e.g., an MSO) that distributes programming to MSO clientele using client devices. Such programming may include literally any information source/receiver including, inter alia, free-to-air TV channels, pay TV channels, interactive TV, and the Internet.
As used herein, the terms “Internet” and “internet” are used interchangeably to refer to inter-networks including, without limitation, the Internet.
As used herein, the term “memory” includes any type of integrated circuit or other storage device adapted for storing digital data including, without limitation, ROM, PROM, EEPROM, DRAM, SDRAM, DDR/2 SDRAM, EDO/FPMS, RLDRAM, SRAM, “flash” memory (e.g., NAND/NOR), and PSRAM.
As used herein, the terms “microprocessor” and “digital processor” are meant generally to include all types of digital processing devices including, without limitation, digital signal processors (DSPs), reduced instruction set computers (RISC), general-purpose (CISC) processors, microprocessors, gate arrays (e.g., FPGAs), PLDs, reconfigurable computer fabrics (RCFs), array processors, secure microprocessors, and application-specific integrated circuits (ASICs). Such digital processors may be contained on a single unitary IC die, or distributed across multiple components.
As used herein, the terms “MSO” or “multiple systems operator” refer to a cable, satellite, or terrestrial network provider having infrastructure required to deliver services including programming and data over those mediums.
As used herein, the terms “network” and “bearer network” refer generally to any type of telecommunications or data network including, without limitation, hybrid fiber coax (HFC) networks, satellite networks, telco networks, and data networks (including MANs, WANs, LANs, WLANs, internets, and intranets). Such networks or portions thereof may utilize any one or more different topologies (e.g., ring, bus, star, loop, etc.), transmission media (e.g., wired/RF cable, RF wireless, millimeter wave, optical, etc.) and/or communications or networking protocols (e.g., SONET, DOCSIS, IEEE Std. 802.3, ATM, X.25, Frame Relay, 3GPP, 3GPP2, WAP, SIP, UDP, FTP, RTP/RTCP, H.323, etc.).
As used herein, the term “network interface” refers to any signal or data interface with a component or network including, without limitation, those of the FireWire (e.g., FW400, FW800, etc.), USB (e.g., USB2), Ethernet (e.g., 10/100, 10/100/1000 (Gigabit Ethernet), 10-Gig-E, etc.), MoCA, Coaxsys (e.g., TVnet™), radio frequency tuner (e.g., in-band or 00B, cable modem, etc.), Wi-Fi, LTE/LTE-A, or WiMAX (802.16).
As used herein, the term “QAM” refers to modulation schemes used for sending signals over cable networks. Such modulation scheme might use any constellation level (e.g. QPSK, 16-QAM, 64-QAM, 256-QAM, etc.) depending on details of a cable network. A QAM may also refer to a physical channel modulated according to the schemes.
As used herein, the term “server” refers to any computerized component, system or entity regardless of form which is adapted to provide data, files, applications, content, or other services to one or more other devices or entities on a computer network.
As used herein, the term “storage” refers to without limitation computer hard drives, DVR device, memory, RAID devices or arrays, optical media (e.g., CD-ROMs, Laserdiscs, Blu-Ray, etc.), solid-state storage devices (SSSDs), or any other devices or media capable of storing content or other information, whether local, virtual or cloud-based.
As used herein, the term “wireless” means any wireless signal, data, communication, or other interface including without limitation Wi-Fi (e.g., IEEE Std. 802.11a/bg/n/v/ac, or Wi-Fi Direct), Bluetooth, 3G (3GPP/3GPP2), HSDPA/HSUPA. TDMA, CDMA (e.g., IS-95A, WCDMA, etc.), FHSS, DSSS, GSM, PAN/802.15, WiMAX (802.16), 802.20, Zigbee®, Z-wave, narrowband/FDMA, OFDM, PCS/DCS, LTE/LTE-A, analog cellular, CDPD, satellite systems, millimeter wave or microwave systems, acoustic, and infrared (i.e., IrDA).
Overview
In one salient aspect, the present disclosure provides, inter alia, improved apparatus and methods for the storage and delivery of recorded content stored at a network storage location (i.e., in the “cloud”) and delivered over a network (hereinafter referred to as “cloud DVR” or “cDVR”). The storage and delivery of cDVR content in the present disclosure includes, inter alia, both storage and delivery of user-initiated cDVR events (i.e., instances wherein a user requests to have content recorded to a cloud-based digital video recorder), as well as real-time MSO-initiated cDVR events (i.e., instances wherein the MSO determines which content will be recorded, in real time, to a cloud-based digital video recorder). The improved apparatus and methods disclosed herein advantageously provide a high degree of platform heterogeneity and mobility (i.e., delivery of content to various different types of user client devices, and at differing physical locations), while also providing significant economies to the network operator or service provider in terms of efficient data storage and transmission.
Moreover, the ability to cache or preposition portions of a given content element in various locations throughout the content distribution network (including for use with other portions of the same content element which are not stored within the content distribution network) is provided.
In one embodiment, the improved apparatus of the present disclosure comprises one or more entities adapted to accomplish various content processing operations; e.g., a cDVR server adapted to utilize a compression storage system that significantly reduces virtual storage requirements. In one implementation, content assets are compressed in the aforementioned compression storage system after a threshold time duration is reached (e.g., 72 hours after receipt of an initial recording request from a user). The aforementioned compression storage system and/or cDVR server utilizes a randomized sequence allocation/assignment with numeric complements adapted to create a large number of unique combinations of the stored content elements, and stream them to the client device(s) of network users or households via a unique path. The improved apparatus of the invention advantageously obviates excessive (and often unused) content storage, and facilitates pre-streaming processing within the cDVR system.
Moreover, various implementations of the disclosure utilize two distinct types of compression; i.e., “virtual” spatial or storage compression, and encoding (“lossy”) compression; advanced adaptive bitrate (ABR) streaming techniques are also optionally employed to further enhance storage and delivery efficiency and flexibility.
In another embodiment, the apparatus of the invention also comprises one or more content databases adapted to facilitate cDVR content access across one or more regions of a broadcast network. In one variant, the content databases comprise a unique private storage and a cached shared library, each of which are used together to create significant network efficiencies and combinational uniqueness. The content databases can each be disposed within and/or outside the content distribution network; e.g., one at the core of the network, and one at one or more edge caches, etc.
The improved methods and apparatus of the invention provide other significant benefits including: (i) reduced costs associated with storage and streaming of content (i.e., instead of having to store large quantities of content at, e.g., a VOD server, the cDVR server will compress and store content until requested); (ii) enablement of pre-streaming processing steps to ensure quality of content streamed to users (e.g., transcoding/transrating, and selective secondary content insertion or modification); and (iii) significant improvements in reliability and delivered video quality.
Moreover, the ability to create a large number of “physically unique” versions of a given content element may be used to address or satisfy copyright concerns regarding non-duplication or reproduction of content elements by users.
Detailed Description of Exemplary Embodiments
Exemplary embodiments of the apparatus and methods of the present disclosure are now described in detail. While these exemplary embodiments are described in the context of a managed network (e.g., hybrid fiber coax (HFC) cable) architecture having a multiple systems operator (MSO), digital networking capability, high-speed data (HSD) and IP delivery capability, and a plurality of client devices, the general principles and advantages of the disclosure may be extended to other types of networks and architectures that are configured to deliver digital media data (e.g., text, video, and/or audio), whether managed or unmanaged. Such other networks or architectures may be broadband, narrowband, wired or wireless, or otherwise.
It will also be appreciated that while described generally in the context of a network providing service to a customer or consumer (e.g., residential) end user domain, the present disclosure may be readily adapted to other types of environments including, e.g., commercial/enterprise and government/military applications. Myriad other applications are possible.
In addition, while the disclosure refers at numerous points to one or more Internet Protocol Television (IPTV) embodiments, the principles of the disclosure are contemplated in other applications, such as video services (e.g., network DVR, second screen applications, cloud-based digital navigators, OnDemand or over-the-top (OTT) content (e.g., Netflix®, Hulu®, virtual MSO services, etc.)), visual/social media applications or communications (e.g., Skype®, Facetime®, etc), or cloud computing/storage/streaming services. All such embodiments are considered within the scope of the present disclosure.
Also, while certain aspects are described primarily in the context of the well-known Internet Protocol (described in, inter alia, RFC 791 and 2460), it will be appreciated that the present disclosure may utilize other types of protocols (and in fact bearer networks to include other internets and intranets) to implement the described functionality.
Other features and advantages of the present disclosure will immediately be recognized by persons of ordinary skill in the art with reference to the attached drawings and detailed description of exemplary embodiments as given below.
Cloud Digital Video Recording Architecture—
Referring now to
As shown in
The requesting client device 204a-c may include home gateway devices and/or media client devices. In one embodiment, the media client device is a portable device such as a wireless-enabled tablet computer or smartphone. Alternatively, the client device may include a Smart TV or the like. The present disclosure also contemplates a household or person using two or more client devices and therefore may have access to two or more independent communications paths to the content server (e.g., cDVR server 218). For example, a user may have access to a Smart TV 204a connected to a router and cable modem 203, and a tablet 204c connected to the cable modem via a wireless communications network such as a wireless LAN (e.g., Wi-Fi), as well as a smartphone 204b interfacing with a wireless service provider (WSP) network such as via an LTE or LTE-A interface, the WSP network in data communication with the Internet 206 (or directly to the distribution network 202, not shown).
In one variant, the user IP-enabled client devices 204a-c may also include an MSO-authored application program (“app”) 211 operative thereon to interface with the MSO cDVR server (or other entity of the MSO network) so as to facilitate various user functions such as program guides, browsing, recording, and even playback/rendering. The user may also make use of a streaming player device if desired, such as a Roku or similar, to receive OTT (over-the-top) streaming of content from the MSO and/or other streaming sources such as e.g., Hulu.
As shown, the architecture of
The received content is presented to various network entities. Specifically, at least one mechanism is established for providing content directly to the user in accordance with a schedule (not shown); such mechanism is well known in the art and thus will not be discussed in further detail herein.
Content which is recorded, either by a user-initiated or an MSO-initiated cDVR request, is initially input into a first storage entity 210. In one embodiment, the content is provided to storage 210 as an uncompressed individual asset (e.g., copy). An uncompressed individual asset may be stored for each client or household 204a-c that requests a recording. In a further embodiment, the uncompressed individual content assets may be pre-processed, thereby comprising a plurality of segments. As users have the ability to select a different start and end time for each asset requested to be recorded, not all segments will necessarily be recorded for all users.
In one embodiment, storage 210 may employ one or more “rolling buffers” which constantly record one or more incoming audio or video programs. In accordance with this embodiment, the rolling buffer has a prescribed depth; once the buffer has been filled, the oldest data stored therein is overwritten. The depth of the buffer may be selected e.g., as a function of the number of overlapping payload data segments that are to be kept in anticipation of an expected an amount of skew in the system. In another embodiment, the storage entity 210 may additionally comprise a “fan-out” or filtering mechanism which facilitates the selective storage of content from the initial storage 210. For example, if a rolling buffer is set for five hours, when the maximum duration has been reached, content at the beginning of the buffer may be deleted in order to save new content; however, this logic is only applied in cases where at least one user has specifically requested recordation of a particular content element. So, for example all of 100 channels may be at least transiently stored in the rolling buffer for a prescribed period, yet maybe only 25 of those 100 channels are “persistently” recorded in respective unique folders associated with respective requesting users based on the existence of requests from those users to record. This mechanism advantageously reduces required storage space, since only those program elements in which one or more users has expressed interest in recording are in fact recorded (for any duration beyond the depth of the rolling buffer). The “fan-out” process is a subset of the process of storing recorded content. For example, in the event that N distinct users initiate a recording of a particular video program, the “fan-out” process optimizes the allocation of the N recordings across the multitude of hard-drives within the storage system of the cDVR server 218.
In some embodiments, the uncompressed assets delivered from the distribution network 202 during e.g., a live broadcast may only be kept until the user changes the data source (e.g., television channel), or another event occurs, such as the user turning off their client device 204.
Furthermore, the storage entity 210 may comprise a plurality of private storage locations (e.g., private folders) unique to each household or client 204a-c such that all assets requested to be recorded by each household or client 204a-c may be stored in one or more of the private locations. Such folders may even be sub-partitioned by e.g., particular users and/or client devices associated with the account if desired.
The network architecture 200 of
In addition to segmentation, DRM management, and ad insertion, the packager 216 may also transcode/transrate/transcrypt content before sending it through the DN 202 (and possibly the internetwork 206) to the client(s) or household. However, while the transcoding/transrating/transcrypting functionalities are shown as being integrated into a single apparatus (i.e., packager 216), in another embodiment, the functionalities may be integrated into separate apparatus, such as a transcoder module, transrater module, and/or transcrypter module (not shown). Thus, each of the cDVR server 218, encoder, encryptor, and packaging processes may be housed in separate server apparatuses, may comprise different processes running on a single server apparatus, or may comprise any number of distributed applications with functionality across any number of apparatus. Each server apparatus may include memory and storage, one or more processors, and interfaces to connect to other components/networks, as will be appreciated by those of ordinary skill in the art given the present disclosure.
In one exemplary embodiment, the packager 216 acts as a transcoding entity and encodes the uncompressed individual copy of content from the storage entity 210 into at least one encoding format (e.g., transcodes content from one encoding format such as MPEG-2 to at least one other format such as MPEG-4 AVC/H.264), whether after retrieval from initial storage in the storage entity 201 or prior to such storage. Transcoding prior to storage may be used to save storage space (e.g., going from MPEG-2 to MPEG-4 AVC is roughly half), yet also reduces flexibility in that if a subsequent format (other than MPEG-4 AVC in the example) is required by the client due to e.g., configuration or player limitations, a second transcode operation will be required, which consumes processing and may further reduce quality of the content as previously discussed (i.e., due to “lossiness”).
In one particular implementation, the packager 216 streams the retrieved content via adaptive bitrate (ABR) streaming. “Adaptive bitrate (ABR) streaming” refers to streaming multimedia over computer networks such that content thereof may be encoded into multiple bitrates. Depending on client capacity and available bandwidth, several encoded content segments of varying bit rates may be sent to a client device. Non-limiting examples of ABR streaming include, without limitation, MPEG-Dynamic Adaptive Streaming over HTTP (DASH), Adobe® Dynamic Streaming for flash, Apple® HTTP Adaptive Streaming, Microsoft® Smooth Streaming, QuavStreams® Adaptive Streaming over HTTP, and upLynk®. As noted above, ABR is typically agnostic to the underlying codec, and hence can be used as an “overlay” of sorts to the transcoding referenced above (e.g., ABR may be applied to the MPEG-4 AVC-encoded content during/after its transcoding from MPEG-2 to AVC). In one implementation, multiple bit rate streams are output by the packager 216, e.g., and the stream that best utilizes the viewer's device and current bandwidth constraints (the latter which may be provided to the packager from another network process or source) is used to provide an optimal playback experience. The optimization occurs via a process or application running at the packager 216 (including optionally negotiation with the target client as to its particular capabilities).
In another variant, the content is encoded into a plurality of heterogeneous encodings that correspond to a respective plurality of one or more device types, codecs, resolutions, file formats, audio encodings, bit rates, etc. The content may be encoded in a variety of formats (both audio and video), bit rates, resolutions, which are each playable on a variety of devices, so as to enable a wide variety of user devices to play a certain piece of content. Accordingly, a network operator selects to have the packager 216 encode the content into multiple formats for use on the variety of players.
Parameters used by the packager 216 to encode the content may include: (i) whether the output streams should be encoded into separate video and audio only tracks, or video tracks with audio included, (ii) an appropriate key frame period, (iii) a frame rate, (iv) segmentation duration, (v) video resolutions, (vi) video bitrate, (vii) audio bit rate (where necessary), (viii) audio sample rate, (ix) a number of audio channels, (x) aspect ratio, (xi) video codec, (xii) specific device profiles, (xiii) audio volume, (xiv) file type and extension, and (xv) standard specific encoding profiles. Standard specific encoding profiles are associated with various codecs such as e.g., H.264, which includes different standard encoding profiles for baseline, main, and high encoding. This might be useful for example in a case where the delivery channel to the target device (e.g., a laptop, handheld, etc.) is bandwidth-constrained, since the H.264 encoding will typically require a lower bitrate for the same content. Similarly, if the target device has only an H.264 codec, the content must be transcoded. Any multitude of reasons may exist for transcoding content before delivery. Additionally, the packager 216 may utilize information used for cutting out other resolutions/aspect ratios from a higher resolution/different aspect ratio file. For example, the packager 216 may center-punch a standard definition (SD) image or video from a high definition (HD) source. Similarly, an HD image or video may be center punched from a 4K, 8K, 16K source.
Output streams may be separate files (for example MPEG 4 transport stream (.ts) files) delivered according to a manifest, or in a further embodiment of the present disclosure, all of the streams (i.e., streams 212) may be presented in a single “super” file. Having a single comprehensive file comprising multiple streams may lower the number of files the MSO network infrastructure must manage.
The packager 216 may encode output streams with audio tracks (e.g., AC3 audio). Different encoding formats and bit rates may be selected based on the requirements of the stream, end user (client) equipment, and the protocols and formats used by the CDN 202.
The packager 216 may also transrate the content (optionally independent of whether or not transcoding is performed, or alternatively as part of the transcoding function) in order to adjust the bitrate. Transrating may include for example changing or altering content from one bitrate, GOP size, resolution, etc. to a different bitrate, GOP size, resolution, etc.
Additionally (or alternatively), the packager 216 may provide transcryption functionality; e.g., the encoded output streams are translated between one encryption domain to another by the packager 216 via an encryption algorithm (e.g., AES, DES, public key encryption, etc.). For example, transcryption may be used to move between encryption formats used by different content protection or conditional access (CA) systems (e.g., from an MSO's indigenous DRM scheme to another scheme such as Windows Media DRM (“WMDRM”) or Digital Transmission Content Protection (“DTCP”) on a subscriber PC), or provide a transitory encryption for the digital content while it is being transferred between different systems and/or components. In this fashion, content or other data within the MSO security or CA environment can “jump the fence” to DRM or other security environments that may be more widely deployed on IP-based devices for example. This is particularly useful for the IP-based delivery targets such as those described with respect to the figures presented herein.
Referring now to
The “compression” applied in the process of
In terms of the virtual compression scheme, some of the segments of the content asset are designated as “shared” segments 224 via a segmentation process (described in further detail below). The shared segments may be sent to a shared library or database 214. In one variant, the shared library 214 may comprise a DN cache, such as an edge cache disposed at or proximate an edge of the DN 202 (as opposed to a core portion of the MSO network). In some embodiments, the cached shared library 214 may selectively cache (and de-cache video content in the network so as to reduce content transformation requirements and also cache storage requirements using the methods and apparatuses described in co-owned U.S. patent application Ser. No. 11/904,375 filed on Sep. 26, 2007, issued as U.S. Pat. No. 8,561,116 on Oct. 15, 2013 and entitled “METHODS AND APPARATUS FOR CONTENT CACHING IN A VIDEO NETWORK”, which is incorporated by reference herein in its entirety.
Furthermore, the shared library 214 may reside on the DN 202 or outside of the CDN 202, as illustrated in the architecture of
Additionally, while described in the context of cloud-based storage entities, it will be recognized that the private storage 210, archival storage 212, and shared library 214 may each be extended to other virtual storage systems as well, whether within the MSO network or otherwise, including being maintained by third parties. For instance, the MSO may get “a better deal” from a mass cloud storage provider due to e.g., economies of scale, than if the MSO procures and maintains its own infrastructure.
Methods—
Referring now to
In the first step (step 302) of the method 300, a request may be received to record an asset. Prior to the request, the desired content may be made available for recording via a selected communication channel. This may be in response to a user request for the content instigated from a client 204a-c, or may be as a result of action taken at the head-end or other network node (including a third party content server), such as where the delivery of content is conducted according to a predetermined schedule.
At step 304, an uncompressed individual asset or content element is recorded or transferred onto the storage entity 210 and stored in a user- or device-specific storage location. This recording or transfer may take place during the receiving process; e.g., where the received data is stored and then immediately recorded onto the storage 210 in a continuous fashion. In some embodiments, clients or households 204a-c have the ability to select different start and end times for the recording and thus, not all segments of the asset may be recorded for all users.
At step 306, the predetermined one or more criteria (e.g., time since recordation, such as N=72 hours) is/are evaluated; when the criterion/criteria is/are met, the presence of the recorded uncompressed content element is optionally verified (step 310), and retrieved content element is then compressed per step 312.
In one embodiment, the threshold criteria (e.g., period of time such as N=72 hours) is determined by a network entity. The threshold period of time may be pre-determined and constant across all users/households (i.e., macro-based threshold time duration, such as a time period when most devices or households are known via anecdotal or other data to request playback of at least a portion of content subsequent to requesting a recording of that content), applied to only subsets thereof, or even individualized to the particular household or client 204a-c (e.g., a micro-based threshold time duration, such as based on a user's prior historical recording activity).
In one variant, if the determined threshold time period has not been reached, per step 306, the uncompressed asset remains in storage 210 until either a request for playback is received, the threshold time period is reached, or the asset is purged from the system.
It is contemplated that the aforementioned compression and segmentation may occur concurrently, or the compression may occur before the segmentation. It is further appreciated that the compression and/or segmenting processes may comprise one or more software applications run on a processor, or on a separate headend or non-headend entity, or on the digital processor of any of the aforementioned headend entities.
Upon receipt of a user request for access to the recoded content element (step 314), the (virtually) compressed stored element is “decompressed” (i.e., the constituent unique and shared components identified) per step 316, including any requisite supporting processing to generate e.g., the manifest file associated with the content element (step 318) to enable delivery via the DN 202 to the requesting user device (step 320).
In the exemplary embodiment, the packager 216 generates a manifest file associated with the recorded content per step 318. Specifically, the manifest file is a data structure comprising a listing of addresses for each of the media segments of a stream of data, and includes information about the media segments such as bitrates, closed captioning, audio, etc. Different ABR models may use different manifest files. For example, with HTTP Smooth Streaming (HSS), each of the components (closed captioning, audio, etc.) are in separate files with addresses for each in the manifest file. With HTTP Live Streaming (HLS), audio is embedded in the segments and thus are not separately listed in the manifest file.
In another embodiment, the manifest file includes metadata, and a listing of media segment entries. Metadata refers to information used by a client device to interpret or otherwise manage the media segments (metadata is also colloquially referred to as “data regarding data” or “data relating to data”). Common examples of metadata include e.g., version information, protocol, file formats, supported codecs, resolution, encryption, temporal information (transmission time, time of presentation, time stamps, etc.), geographic information (restricted locations, locations for presentation, etc.), content type indicia, synchronization information, control data, etc. Stated differently, the metadata describes the media segments and can be used as a reference file when assessing or otherwise making use of the media segments.
In one implementation, the list of media segment entries in the manifest file comprises a list of network addresses (which may be remote or local) where the corresponding segments of media content may be accessed and/or downloaded. For instance, each of the media segment entries may be listed by a Uniform Resource Locator (URL). In some embodiments, the entries may be in computing resource “path” format. Computing paths may be either absolute (i.e., the path provides the fully elaborated and unique location of the segment in a file structure) or relative (i.e., the path provides a relative location of the segment in a file structure). Additionally, in some embodiments, the entries may be in symbolic format, such that at least a portion of the entry must be further interpreted (i.e., is not human-readable). Common examples of this may include e.g., HyperText Markup Language (HTML) tags, proprietary tags, Java, Javascript, etc. Moreover, some implementations may substitute or intermingle any of the foregoing techniques to flexibly accommodate various operational models.
In another embodiment, the service provider or MSO is represented as a single logical entity (a single network domain) represented by a characteristic URL (e.g., www.timewarnercable.com). In other embodiments, the service provider may be a conglomeration of multiple logical entities. Multiple logical entities may be useful to further distribute services over various network resources or enable additional features provided by partnered corporations or providers. Multiple logical entities, for example, may provide local content for a particular service group or geographic area. Furthermore, having content providing entities closer to end users may offer lower latency and may add network redundancy. Common examples of network resources include e.g., broadcast, multicast, video-on-demand, advertisement services, local services, etc. In one specific example, one exemplary stream manifest file may include entries from: www.timewarnercable.com, vod.timewarner.com (video on demand services), www.nhk.jp (3rd party content), www.adserver.com (3rd party advertisement services), etc.
In another example, the media segment listing may include a listing of URL links which is further punctuated with HTML tags or Javascript, which is configured to enable advertisement insertion and/or execution of complementary programming. For instance, the video client may substitute tailored locally stored advertisements for commercial breaks, rather than e.g., the default broadcasted commercial. In other embodiments, the video client may run a Javascript Applet that allows the subscriber to execute a command or otherwise provide feedback (e.g., to order pizza, vote on a reality show, etc.). Exemplary apparatus and methods for selection of secondary content to be inserted (e.g., via a “targeted” approach) are described in co-owned and co-pending U.S. patent application Ser. No. 11/186,452 filed on Jul. 20, 2005 and entitled “METHOD AND APPARATUS FOR BOUNDARY-BASED NETWORK OPERATION”, U.S. patent application Ser. No. 12/766,433 filed on Apr. 23, 2010 and entitled “APPARATUS AND METHODS FOR DYNAMIC SECONDARY CONTENT AND DATA INSERTION AND DELIVERY”, as well as co-owned U.S. patent application Ser. No. 12/284,757 filed on Sep. 24, 2008, issued as U.S. Pat. No. 9,071,859 on Jun. 30, 2015, and entitled “METHODS AND APPARATUS FOR USER-BASED TARGETED CONTENT DELIVERY”, each of which are incorporated herein by reference in their entirety, although other approaches may be used consistent with the present disclosure.
In the exemplary embodiment, each media segment is an encoded and encrypted subsection or segment of media content. The media segments, when decrypted, decoded, and played in the appropriate order, render the original media content. In one implementation, each media segment represents a portion of video associated with a specific resolution, codec, and time stamp. The media segments are assembled according to a time stamp sequence.
In another embodiment, non-time-based segments may be used in the manifest file. For example, playback may occur according to the context of the sequence and not because of any implied meaning of the filename, or time stamp value. The true duration of a video segment is based on its contents and its presentation time stamp (PTS), which may not be represented in the manifest file. The sequence of the next media file listed in the manifest file is simply what comes next. Specifically, any schema could be used for the transport stream files in the manifest file, including 1.ts, 2.ts, 3.ts, etc., or A.ts, B.ts, C.ts.
The encoding parameters, or a combination of any of the encoding parameters, may be utilized between the DN 202 and/or the packager 216. For example, the packager 216 may utilize the segmentation duration parameters in order to splice the content streams into segments. In another example, the packager 216 may utilize capabilities information of the end device 204a-c to create segments from the output streams that meet the specifications of the requesting device 204a-c (and put those addresses of those segments in a manifest file).
In yet another example, the packager 216 may utilize the key frame period parameter to generate a key frame manifest for implementing trick play mode operations (e.g., fast forward, rewind, pause, and/or random seek) when viewing the content. Various techniques may be used to provide trick play mode operations.
The manifest files listing all components for playback of a piece of content may be generated by the packager 216 based on the registration of a user. In an alternative embodiment, the manifest file (or a plurality of manifest files) is pre-generated for use with one particular ABR format. The manifest files are generated based on the specific device and requirements of an end user device. For example, the Microsoft® Xbox® 360 and Xbox® One video game systems require different manifest files to operate. Furthermore, different streaming standards may require different manifest files to operate. For example, the MPEG-Dynamic Adaptive Streaming over Hyper Text Transfer Protocol (DASH) protocol may be implemented differently with respect to Hyper Text Transfer Protocol (HTTP) live streaming and Windows® Media Streaming. Thus, each may require different manifest files.
Media segments and shared segments may be generated by the packager or other components within the MSO network. The segments may be of predetermined length. For example, a media segment encrypted using an AES algorithm may have a length of 64 bytes. In addition, metadata describing the segments may be generated at the packager 216, or, alternatively at other entities of the MSO network. As discussed herein, the media segments form the basis for the generation of a manifest file.
Additionally, the media segments may be encrypted by the packager 216 (such as via a DES or AES algorithm via a symmetric or asymmetric key approach) prior to transfer over the network. The media segments may then be decrypted by a client device 204a-c.
Additional services may utilize the segments and/or the service of the packager 216 to perform real-time services for a client device 204. For example, the segments may be used for advertisement insertions. Network operators may use advertisement breaks during the presentation of the content or adjacent to the time stamp of the product placement to utilize the product placement time stamp to sell or place the advertisement block. The network operator may sell or place an advertisement for the company whose product has been placed (or, e.g., to a competitor of that company). For example, if a Coke® can is used in a scene of a movie, advertisement blocks could be sold to Coca-Cola® or to Pepsi® during an advertising segment adjacent to the Coke can's appearance in the movie.
Upon receipt of the user-initiated request for playback (such as via an upstream SSP or LSCP command) (step 314), the user's individual compressed asset is uncompressed and assembled on-demand using unique information (e.g., encryption keys, supported resolutions, and digital rights information) from the unique private chunk storage entity 214 and a shared chunk storage entity 216 per step 316.
The aforementioned “virtual decompression” may be performed or assisted by other network entities as well. One such network entity may include the staging processor of the type described in co-owned U.S. patent application Ser. No. 10/860,969 filed Jun. 2, 2004, issued as U.S. Pat. No. 8,392,952 on Mar. 5, 2013 and entitled “Programming content processing and management system and method”, and U.S. patent application Ser. No. 12/406,881 filed Mar. 18, 2009, issued as U.S. Pat. No. 9,277,266 on Mar. 1, 2016 and entitled “Apparatus and methods for network video recording”, each of which are incorporated by reference herein in their entirety. Other approaches may be used with equal success as well.
Accessed unique or shared chunk data may also be pushed to a server within the DN 202 (such as via a File Transfer Protocol or FTP “push” of the type well known in the networking arts) which, in turn, provides it to the client or household 204a-c. Other technologies may be used for this purpose as well, including for example network attached storage such as CIFS (Common Internet File System), SAMBA (e.g., SAMBA 3.2), etc. It is also appreciated that in another embodiment, the (distributing) server may be adapted to pull the assembled content from the respective storage locations upon client 204a-c request.
Next, per step 324, the content is optionally transcoded to another format (e.g., “encoding compressed” such as from MPEG-2 to MPEG-4 AVC) per step 324. The segmentation or allocation algorithm is next used to segment the content element into at least two portions; i.e., the unique portion, and the complementary portion (step 326). The segmenting process generally functions to segment the content at I-frames according to a schedule. In a further embodiment, the segmentation process comprises identifying or generating various sequences of “shared” segments, i.e., numeric complements, which may be shared by multiple ones of the devices or households 204. The numeric complements may be of any sequence (e.g., even, odd, triplets (i.e., three sequential segments), Fibonacci series, etc.).
A network entity (e.g., supervisory process such as e.g., one running on the cDVR server 218) assigns each household or client device 204a-c with one or more numeric combinations or strategies of the complements (e.g., only even, or even and odd, etc.). In one embodiment, the assignment is random, but in a way that guarantees uniqueness for each stream delivered to the devices or households 204a-c. This functionality is also provided by virtue of storage of two or more physically different but content-identical versions of the shared complement (e.g., all the “odds” for a client whose allocation scheme for the unique segments was “all evens”). Each of these physically different versions of the shared complement can be uniquely combined with a given user's unique (non-shared) stored segments or portion, thereby creating a significant degree of uniqueness (albeit with essentially no content-wise diversity), so as to inter alia maintain a high degree of orthogonality between combinations for individual users. Thus, the number of complements 224 stored for each household or device 204a-c creates the uniqueness for each stream delivered to the devices or households 204a-c. The more numeric complements that are used, the more uniqueness (and orthogonality) can be created.
Next, per step 328, the unique portion 220 (i.e., a plurality of segments or chunks of video and/or audio data selected based on the particular scheme chosen for the user or their request) are stored in the relevant unique storage portion of the archival storage device 212, while the common or shared complementary portion is stored in shared storage 214 (step 330).
Lastly, the allocation algorithm or scheme used to segment the content element, (e.g., even-numbered segments, odd-numbered segments, triplets, Fibonacci, etc.) is stored (in association with user- or client-specific data for identification) so as to permit a subsequent software process (e.g., the packager when assembling the manifest file, or even the client player application) to identify the scheme used so it can obtain a proper shared complement.
Exemplary Bearer Network Architecture—
Referring now to
As is well known, in addition to “broadcast” or linear content (e.g., video programming), cable network systems also deliver high-speed data services using the Internet protocol (IP). One exemplary delivery paradigm comprises delivering video transported to user clients (or IP-based STBs) over the aforementioned DOCSIS channels comprising MPEG (or other video codec such as H.264 or AVC) over an IP transport (e.g., OSI network layer) over MPEG. That is, the higher layer MPEG-4 AVC/H.264 or other encoded content is encapsulated using an IP network protocol, which then utilizes an MPEG packetization of the type well known in the art for delivery over the RF QAM-modulated channels of the cable bearer medium. In this fashion, a parallel delivery mode to the normal broadcast delivery exists; i.e., delivery of video content both over traditional downstream QAMs to the tuner of the user's STB or other receiver device for viewing on the television, and also as packetized IP data over the DOCSIS QAMs to the user's PC, tablet, or other IP-enabled device via the user's cable modem. Delivery in such packetized modes may be unicast, multicast, or broadcast. Delivery of the IP-encapsulated data may also occur over the non-DOCSIS QAMs.
The illustrated network 1000 generally comprises a local headend 1001 in communication with at least one hub 1003 via an optical ring 1007. The distribution hub 1003 is able to provide content to various user devices, client devices 1022, and gateway devices 1020, via a network 1005.
Various content sources 1002 are used to provide content to a content server 1004, as described previously herein.
A central media server located in the headend 1001 may be used as an installed backup to the hub media servers as (i) the primary source for lower demand services, and (ii) as the source of the real time, centrally encoded programs with PVR (personal video recorder) capabilities. By distributing the servers to the hub stations 1003 as shown in
The network 1000 of
Individual client devices 1022 of the implementation of
The edge switch forwards the packets receive from the CMTS to the QAM modulator, which transmits the packets on one or more physical (QAM-modulated RF) channels to the client devices. The IP packets are typically transmitted on RF channels that are different than the RF channels used for the broadcast video and audio programming, although this is not a requirement. As noted above, the client devices (e.g., DOCSIS modems) are each configured to monitor the particular assigned RF channel (such as via a port or socket ID/address, or other such mechanism) for IP packets intended for the subscriber premises/address that they serve.
In one embodiment, both IP data content and IP-packetized audio/video content is delivered to a user via one or more universal edge QAM devices 1018. According to this embodiment, all of the content is delivered on DOCSIS channels, which are received by a premises gateway 1020 and distributed to one or more client devices 1022 in communication therewith. Alternatively, the client devices 1022 may be configured to receive IP content directly without need of the gateway or other intermediary.
It is still further appreciated that the delivery of content may include delivery from an “off-net” distribution hub (not shown) to another network (not shown), not associated with the MSO. In this embodiment, a requesting device (such as client device 1022 or gateway 1020) may request content from a local headend 1001 which is transferred over both MSO-maintained (“on-net”) and “off-net” networks advantageously.
While the foregoing network architectures described herein can (and in fact do) carry packetized content (e.g., IP over MPEG for high-speed data or Internet TV, MPEG2 packet content over QAM for MPTS, etc.), they are often not optimized for such delivery. Hence, in accordance with another embodiment of the disclosure, a “packet optimized” delivery network is used for carriage of the packet content (e.g., IPTV content).
cDVR-Enabled Client Device
In one exemplary embodiment, the processor 502 may include one or more of a digital signal processor, microprocessor, field-programmable gate array, or plurality of processing components mounted on one or more substrates (e.g., printed circuit board). The processor subsystem 502 may also comprise an internal cache memory. The processor subsystem is in communication with a memory subsystem 504, the latter including memory which may for example comprise SRAM, flash, and/or SDRAM components. The memory subsystem may implement one or more of DMA-type hardware, so as to facilitate data accesses as is well known in the art. The memory subsystem of the exemplary embodiment contains computer-executable instructions which are executable by the processor subsystem.
In this and various embodiments, the processor subsystem 502 is configured to execute at least one computer program stored in memory 504 (e.g., a non-transitory computer readable storage medium). A video co-processor 510 and SE/DRM Manager 512 are also in data communication with the processor subsystem 502, and collectively the foregoing components include a plurality of computer programs/firmware configured to perform the functions described supra, e.g., decryption, manifest unpacking, decode, preview/trick-mode image display, as well as various assorted functions useful for and typical in consumer electronics including baseband management (e.g., transmit and receive functions via the baseband processor and associated TX and RX modules 514, 516. For example, in one implementation, the client comprises one or more media player “apps” (e.g., capable of decoding and rendering MPEG-4 AVC video and associated audio), such as that received and assembled from the various URLs or storage locations specified in the manifest files, correlating to the unique and shared portions of the requested content element(s).
In one implementation, the player app is integrated into an MSO-specific app which also manages, e.g., entitlements (i.e., the user's authentication and privileges under a subscription package pursuant to which the content is being delivered), scheduling of future recordings, an “EPG” or electronic program guide function, security (e.g., DRM or CA), and other MSO-provided features and functions.
In one or more embodiments, the video co-processor/manager and SE/DRM manager each include an internal cache or memory configured to hold data associated with one or more functions (e.g., decoded video frames, decryption keys, etc.). In some embodiments, application program interfaces (APIs) such as those included in an MSO-provided mobile application or those natively available on the client device 500 (e.g., as part of the decode/display computer program noted supra, or exclusively internal to the manager modules 510, 512) may also reside in the internal cache(s), or other memory 504.
In one embodiment, the radio frequency interface 508 is configured to transact one or more network address packets with other networked devices according to a network protocol, e.g., RF QAMs in an HFC network, a MoCA premises network interface, OFDM carriers in a Wi-Fi or LTE network, and so forth.
Network addressing may provide each node of a network with an address that is unique to that network; the address can be used to communicate (directly via peer-to-peer communications, or indirectly via a series of “hops”) with the corresponding device. In more complex networks, multiple layers of indirection may be used to assist in address exhaustion (e.g., one address is logically divided into another range of network addresses). Common examples of network routing protocols include for example: Internet Protocol (IP), Internetwork Packet Exchange (IPX), and OSI-based network technologies (e.g., Asynchronous Transfer Mode (ATM), Synchronous Optical Networking (SONET), Synchronous Digital Hierarchy (SDH), Frame Relay).
A radio/modem subsystem of the client device 500 comprises a TX transmit module 514 and RX receive module 516, which communicate with the RF network interface 508. The network interface 508 generally incorporates an assembly of filters, low noise amplifiers (LNAs), power amplifiers (PAs), and antenna assemblies that are configured to transmit a modulated waveform via an air interface. As shown, the radio/modem subsystem may be configured to support MIMO (multiple input, multiple output) antenna technology in which multiple antennas are used to transmit and receive signaling. With MIMO, multiple independent data streams can be transmitted in parallel using the same time-frequency resource. To distinguish the data streams sharing this same time-frequency resource, spatial division multiplexing is applied. Those of ordinary skill in the related arts will readily appreciate that SISO (single in, single out), SIMO (single in, multiple out), and MISO (multiple in, single out) antenna schemes may be substituted with equivalent success.
The client apparatus 500 of the present embodiment comprises a mobile consumer electronics device, such as, but not limited to mobile devices such as handheld computers, PDAs, personal media devices (PMDs), smartphones, tablets, and “phablets,”, and personal computers (PCs), and minicomputers, whether desktop, laptop, or otherwise. Artisans of ordinary skill will readily appreciate that consumer electronics devices may incorporate various other assorted components necessary to support typical functions of such devices, including power modules, peripherals modules, display modules (associated with, e.g., a display screen, UI, GUI), camera modules, voice codec modules, etc. Moreover, the methods and apparatus described herein may also readily be adapted to e.g., other types of client devices/CPE including e.g., Smart TVs, digital set-top boxes (DSTBs), etc.
It will be recognized that while certain aspects of the disclosure are described in terms of a specific sequence of steps of a method, these descriptions are only illustrative of the broader methods of the disclosure, and may be modified as required by the particular application. Certain steps may be rendered unnecessary or optional under certain circumstances. Additionally, certain steps or functionality may be added to the disclosed embodiments, or the order of performance of two or more steps permuted. All such variations are considered to be encompassed within the disclosure disclosed and claimed herein.
While the above detailed description has shown, described, and pointed out novel features of the disclosure as applied to various embodiments, it will be understood that various omissions, substitutions, and changes in the form and details of the device or process illustrated may be made by those skilled in the art without departing from the disclosure. This description is in no way meant to be limiting, but rather should be taken as illustrative of the general principles of the disclosure. The scope of the disclosure should be determined with reference to the claims.
It will be further appreciated that while certain steps and aspects of the various methods and apparatus described herein may be performed by a human being, the disclosed aspects and individual methods and apparatus are generally computerized/computer-implemented. Computerized apparatus and methods are necessary to fully implement these aspects for any number of reasons including, without limitation, commercial viability, practicality, and even feasibility (i.e., certain steps/processes simply cannot be performed by a human being in any viable fashion).
| Number | Name | Date | Kind |
|---|---|---|---|
| 4521881 | Stapleford et al. | Jun 1985 | A |
| 4546382 | McKenna et al. | Oct 1985 | A |
| 4602279 | Freeman | Jul 1986 | A |
| 4930120 | Baxter et al. | May 1990 | A |
| 5155591 | Wachob | Oct 1992 | A |
| 5233423 | Jernigan et al. | Aug 1993 | A |
| 5313454 | Bustini et al. | May 1994 | A |
| 5361091 | Hoarty et al. | Nov 1994 | A |
| 5600364 | Hendricks et al. | Feb 1997 | A |
| RE35651 | Bradley et al. | Nov 1997 | E |
| 5734380 | Adams et al. | Mar 1998 | A |
| 5758257 | Herz et al. | May 1998 | A |
| 5774170 | Hite et al. | Jun 1998 | A |
| 5793410 | Rao | Aug 1998 | A |
| 5815662 | Ong | Sep 1998 | A |
| 5862312 | Mann et al. | Jan 1999 | A |
| 5878324 | Borth et al. | Mar 1999 | A |
| 5886995 | Arsenault et al. | Mar 1999 | A |
| 5914945 | Abu-Amara et al. | Jun 1999 | A |
| 5926205 | Krause et al. | Jul 1999 | A |
| 5935206 | Dixon et al. | Aug 1999 | A |
| 5963844 | Dail | Oct 1999 | A |
| 6002393 | Hite et al. | Dec 1999 | A |
| 6018359 | Kermode | Jan 2000 | A |
| 6047327 | Tso et al. | Apr 2000 | A |
| 6081830 | Schindler | Jun 2000 | A |
| 6092178 | Jindal et al. | Jul 2000 | A |
| 6105134 | Pinder et al. | Aug 2000 | A |
| 6124878 | Adams et al. | Sep 2000 | A |
| 6128316 | Takeda et al. | Oct 2000 | A |
| 6134532 | Lazarus et al. | Oct 2000 | A |
| 6157377 | Shah-Nazaroff et al. | Dec 2000 | A |
| 6161142 | Wolfe et al. | Dec 2000 | A |
| 6167432 | Jiang | Dec 2000 | A |
| 6169728 | Perreault et al. | Jan 2001 | B1 |
| 6175856 | Riddle | Jan 2001 | B1 |
| 6182050 | Ballard | Jan 2001 | B1 |
| 6211869 | Loveman et al. | Apr 2001 | B1 |
| 6211901 | Imajima et al. | Apr 2001 | B1 |
| 6216129 | Eldering | Apr 2001 | B1 |
| 6216152 | Wong et al. | Apr 2001 | B1 |
| 6219710 | Gray et al. | Apr 2001 | B1 |
| 6219840 | Corrigan et al. | Apr 2001 | B1 |
| 6240243 | Chen et al. | May 2001 | B1 |
| 6240553 | Son et al. | May 2001 | B1 |
| 6252964 | Wasilewski et al. | Jun 2001 | B1 |
| 6256393 | Safadi et al. | Jul 2001 | B1 |
| 6330609 | Garofalakis et al. | Dec 2001 | B1 |
| 6337715 | Inagaki et al. | Jan 2002 | B1 |
| 6345279 | Li et al. | Feb 2002 | B1 |
| 6353626 | Sunay et al. | Mar 2002 | B1 |
| 6378130 | Adams | Apr 2002 | B1 |
| 6434141 | Oz et al. | Aug 2002 | B1 |
| 6446261 | Rosser | Sep 2002 | B1 |
| 6463508 | Wolf et al. | Oct 2002 | B1 |
| 6463585 | Hendricks et al. | Oct 2002 | B1 |
| 6487721 | Safadi | Nov 2002 | B1 |
| 6498783 | Lin | Dec 2002 | B1 |
| 6502139 | Birk et al. | Dec 2002 | B1 |
| 6516412 | Wasilewski et al. | Feb 2003 | B2 |
| 6560578 | Eldering | May 2003 | B2 |
| 6590865 | Ibaraki et al. | Jul 2003 | B1 |
| 6594699 | Sahai et al. | Jul 2003 | B1 |
| 6601237 | Ten Kate et al. | Jul 2003 | B1 |
| 6604138 | Virine et al. | Aug 2003 | B1 |
| 6615039 | Eldering | Sep 2003 | B1 |
| 6615251 | Klug et al. | Sep 2003 | B1 |
| 6651103 | Markowitz et al. | Nov 2003 | B1 |
| 6671736 | Virine et al. | Dec 2003 | B2 |
| 6687735 | Logston et al. | Feb 2004 | B1 |
| 6700624 | Yun | Mar 2004 | B2 |
| 6718551 | Swix et al. | Apr 2004 | B1 |
| 6725459 | Bacon | Apr 2004 | B2 |
| 6728269 | Godwin et al. | Apr 2004 | B1 |
| 6728840 | Shatil et al. | Apr 2004 | B1 |
| 6738978 | Hendricks et al. | May 2004 | B1 |
| 6742187 | Vogel | May 2004 | B1 |
| 6745245 | Carpenter | Jun 2004 | B1 |
| 6763391 | Ludtke | Jul 2004 | B1 |
| 6771290 | Hoyle | Aug 2004 | B1 |
| 6772435 | Thexton et al. | Aug 2004 | B1 |
| 6775843 | McDermott | Aug 2004 | B1 |
| 6799196 | Smith | Sep 2004 | B1 |
| 6839757 | Romano et al. | Jan 2005 | B1 |
| 6842783 | Boivie et al. | Jan 2005 | B1 |
| 6859839 | Zahorjan et al. | Feb 2005 | B1 |
| 6868439 | Basu et al. | Mar 2005 | B2 |
| 6891841 | Leatherbury et al. | May 2005 | B2 |
| 6898800 | Son et al. | May 2005 | B2 |
| 6917628 | McKinnin et al. | Jul 2005 | B2 |
| 6944166 | Perinpanathan et al. | Sep 2005 | B1 |
| 6948183 | Peterka | Sep 2005 | B1 |
| 6961430 | Gaske et al. | Nov 2005 | B1 |
| 6977691 | Middleton et al. | Dec 2005 | B1 |
| 6981045 | Brooks | Dec 2005 | B1 |
| 6985934 | Armstrong et al. | Jan 2006 | B1 |
| 6986156 | Rodriguez et al. | Jan 2006 | B1 |
| 7010801 | Jerding et al. | Mar 2006 | B1 |
| 7017174 | Sheedy | Mar 2006 | B1 |
| 7024461 | Janning et al. | Apr 2006 | B1 |
| 7024676 | Klopfenstein | Apr 2006 | B1 |
| 7027460 | Iyer et al. | Apr 2006 | B2 |
| 7039116 | Zhang et al. | May 2006 | B1 |
| 7039169 | Jones | May 2006 | B2 |
| 7039614 | Candelore | May 2006 | B1 |
| 7039938 | Candelore | May 2006 | B2 |
| 7047309 | Baumann et al. | May 2006 | B2 |
| 7058387 | Kumar et al. | Jun 2006 | B2 |
| 7069573 | Brooks et al. | Jun 2006 | B1 |
| 7073189 | McElhatten et al. | Jul 2006 | B2 |
| 7075945 | Arsenault et al. | Jul 2006 | B2 |
| 7085839 | Baugher et al. | Aug 2006 | B1 |
| 7086077 | Giammaressi | Aug 2006 | B2 |
| 7088910 | Potrebic et al. | Aug 2006 | B2 |
| 7089577 | Rakib et al. | Aug 2006 | B1 |
| 7093272 | Shah-Nazaroff et al. | Aug 2006 | B1 |
| 7100183 | Kunkel et al. | Aug 2006 | B2 |
| 7103906 | Katz et al. | Sep 2006 | B1 |
| 7107462 | Fransdonk | Sep 2006 | B2 |
| 7110457 | Chen et al. | Sep 2006 | B1 |
| 7127619 | Unger et al. | Oct 2006 | B2 |
| 7133837 | Barnes, Jr. | Nov 2006 | B1 |
| 7143431 | Eager et al. | Nov 2006 | B1 |
| 7146627 | Ismail et al. | Dec 2006 | B1 |
| 7152237 | Flickinger et al. | Dec 2006 | B2 |
| 7155508 | Sankuratripati et al. | Dec 2006 | B2 |
| 7174385 | Li | Feb 2007 | B2 |
| 7178161 | Fristoe et al. | Feb 2007 | B1 |
| 7181010 | Russ et al. | Feb 2007 | B2 |
| 7181760 | Wallace | Feb 2007 | B1 |
| 7191461 | Arsenault et al. | Mar 2007 | B1 |
| 7194752 | Kenyon et al. | Mar 2007 | B1 |
| 7194756 | Addington et al. | Mar 2007 | B2 |
| 7200788 | Hiraki et al. | Apr 2007 | B2 |
| 7203940 | Barmettler et al. | Apr 2007 | B2 |
| 7207055 | Hendricks et al. | Apr 2007 | B1 |
| 7216265 | Hughes et al. | May 2007 | B2 |
| 7225164 | Candelore et al. | May 2007 | B1 |
| 7225458 | Klauss et al. | May 2007 | B2 |
| 7228555 | Schlack | Jun 2007 | B2 |
| 7237250 | Kanojia et al. | Jun 2007 | B2 |
| 7246150 | Donoho et al. | Jul 2007 | B1 |
| 7246172 | Yoshiba et al. | Jul 2007 | B2 |
| 7246366 | Addington et al. | Jul 2007 | B1 |
| 7254608 | Yeager et al. | Aug 2007 | B2 |
| 7257650 | MacIesowicz | Aug 2007 | B2 |
| 7266198 | Medvinsky | Sep 2007 | B2 |
| 7266611 | Jabri et al. | Sep 2007 | B2 |
| 7266726 | Ladd et al. | Sep 2007 | B1 |
| 7283782 | Sinnarajah et al. | Oct 2007 | B2 |
| 7296074 | Jagels | Nov 2007 | B2 |
| 7299290 | Karpoff | Nov 2007 | B2 |
| 7305691 | Cristofalo | Dec 2007 | B2 |
| 7308415 | Kimbrel et al. | Dec 2007 | B2 |
| 7317728 | Acharya et al. | Jan 2008 | B2 |
| 7320134 | Tomsen et al. | Jan 2008 | B1 |
| 7325073 | Shao et al. | Jan 2008 | B2 |
| 7327692 | Ain et al. | Feb 2008 | B2 |
| 7334044 | Allen | Feb 2008 | B1 |
| 7340759 | Rodriguez | Mar 2008 | B1 |
| 7346688 | Allen et al. | Mar 2008 | B2 |
| 7346917 | Gatto et al. | Mar 2008 | B2 |
| 7352775 | Powell | Apr 2008 | B2 |
| 7355980 | Bauer et al. | Apr 2008 | B2 |
| 7363371 | Kirby et al. | Apr 2008 | B2 |
| 7370120 | Kirsch et al. | May 2008 | B2 |
| 7376386 | Phillips et al. | May 2008 | B2 |
| 7379494 | Raleigh et al. | May 2008 | B2 |
| 7403618 | Van Rijnsoever et al. | Jul 2008 | B2 |
| 7434245 | Shiga et al. | Oct 2008 | B1 |
| 7457520 | Rossetti et al. | Nov 2008 | B2 |
| 7464179 | Hodges et al. | Dec 2008 | B2 |
| 7555006 | Wolfe et al. | Jun 2009 | B2 |
| 7567565 | La Joie | Jul 2009 | B2 |
| 7577118 | Haumonte et al. | Aug 2009 | B2 |
| 7602820 | Helms et al. | Oct 2009 | B2 |
| 7617516 | Huslak et al. | Nov 2009 | B2 |
| 7630401 | Iwamura | Dec 2009 | B2 |
| 7689995 | Francis et al. | Mar 2010 | B1 |
| 7690020 | Lebar | Mar 2010 | B2 |
| 7720986 | Savoor et al. | May 2010 | B2 |
| 7721313 | Barrett | May 2010 | B2 |
| 7757251 | Gonder et al. | Jul 2010 | B2 |
| 7763360 | Paul et al. | Jul 2010 | B2 |
| 7779097 | Lamkin et al. | Aug 2010 | B2 |
| 7783316 | Mitchell | Aug 2010 | B1 |
| 7805052 | Nakamura et al. | Sep 2010 | B2 |
| 7805741 | Yeh | Sep 2010 | B2 |
| 7836178 | Bedell et al. | Nov 2010 | B1 |
| 7908626 | Williamson et al. | Mar 2011 | B2 |
| 7917008 | Lee et al. | Mar 2011 | B1 |
| 7930715 | Hendricks et al. | Apr 2011 | B2 |
| 8122479 | Britt | Feb 2012 | B2 |
| 8170065 | Hasek et al. | May 2012 | B2 |
| 8280982 | La Joie et al. | Oct 2012 | B2 |
| 8290351 | Plotnick et al. | Oct 2012 | B2 |
| 8291453 | Boortz et al. | Oct 2012 | B2 |
| 8341242 | Dillon et al. | Dec 2012 | B2 |
| 8359351 | Istvan et al. | Jan 2013 | B2 |
| 8365212 | Orlowski | Jan 2013 | B1 |
| 8392952 | Carlucci et al. | Mar 2013 | B2 |
| 8458125 | Chong, Jr. et al. | Jun 2013 | B1 |
| 8468099 | Headings et al. | Jun 2013 | B2 |
| 8516533 | Davis et al. | Aug 2013 | B2 |
| 8561116 | Hasek | Oct 2013 | B2 |
| 8634703 | Barton | Jan 2014 | B1 |
| 8726303 | Ellis, III | May 2014 | B2 |
| 8804519 | Svedberg | Aug 2014 | B2 |
| 8843973 | Morrison | Sep 2014 | B2 |
| 8997136 | Brooks et al. | Mar 2015 | B2 |
| 9071859 | Lajoie | Jun 2015 | B2 |
| 9178634 | Tidwell et al. | Nov 2015 | B2 |
| 9277266 | Riedl et al. | Mar 2016 | B2 |
| 9591069 | Thornburgh et al. | Mar 2017 | B2 |
| 20010013123 | Freeman et al. | Aug 2001 | A1 |
| 20010030785 | Pangrac et al. | Oct 2001 | A1 |
| 20010050901 | Love et al. | Dec 2001 | A1 |
| 20020004912 | Fung | Jan 2002 | A1 |
| 20020019984 | Rakib | Feb 2002 | A1 |
| 20020032754 | Logston et al. | Mar 2002 | A1 |
| 20020049902 | Rhodes | Apr 2002 | A1 |
| 20020049980 | Hoang | Apr 2002 | A1 |
| 20020053082 | Weaver et al. | May 2002 | A1 |
| 20020054589 | Ethridge et al. | May 2002 | A1 |
| 20020059577 | Lu et al. | May 2002 | A1 |
| 20020059619 | Lebar | May 2002 | A1 |
| 20020063621 | Tseng et al. | May 2002 | A1 |
| 20020087975 | Schlack | Jul 2002 | A1 |
| 20020087976 | Kaplan et al. | Jul 2002 | A1 |
| 20020095684 | St. John et al. | Jul 2002 | A1 |
| 20020100059 | Buehl et al. | Jul 2002 | A1 |
| 20020104083 | Hendricks et al. | Aug 2002 | A1 |
| 20020112240 | Bacso et al. | Aug 2002 | A1 |
| 20020120498 | Gordon et al. | Aug 2002 | A1 |
| 20020123928 | Eldering et al. | Sep 2002 | A1 |
| 20020124182 | Bacso et al. | Sep 2002 | A1 |
| 20020124249 | Shintani et al. | Sep 2002 | A1 |
| 20020129378 | Cloonan et al. | Sep 2002 | A1 |
| 20020144262 | Plotnick et al. | Oct 2002 | A1 |
| 20020144263 | Eldering et al. | Oct 2002 | A1 |
| 20020144275 | Kay et al. | Oct 2002 | A1 |
| 20020147771 | Traversat et al. | Oct 2002 | A1 |
| 20020152299 | Traversat et al. | Oct 2002 | A1 |
| 20020154655 | Gummalla et al. | Oct 2002 | A1 |
| 20020154885 | Covell et al. | Oct 2002 | A1 |
| 20020162109 | Shteyn | Oct 2002 | A1 |
| 20020163928 | Rudnick et al. | Nov 2002 | A1 |
| 20020164151 | Jasinschi et al. | Nov 2002 | A1 |
| 20020166119 | Cristofalo | Nov 2002 | A1 |
| 20020170057 | Barrett et al. | Nov 2002 | A1 |
| 20020174430 | Ellis et al. | Nov 2002 | A1 |
| 20020178447 | Plotnick et al. | Nov 2002 | A1 |
| 20020196939 | Unger et al. | Dec 2002 | A1 |
| 20030002862 | Rodriguez et al. | Jan 2003 | A1 |
| 20030004810 | Eldering | Jan 2003 | A1 |
| 20030005453 | Rodriguez et al. | Jan 2003 | A1 |
| 20030007516 | Abramov et al. | Jan 2003 | A1 |
| 20030014759 | Van Stam | Jan 2003 | A1 |
| 20030021412 | Candelore et al. | Jan 2003 | A1 |
| 20030023981 | Lemmons | Jan 2003 | A1 |
| 20030025832 | Swart et al. | Feb 2003 | A1 |
| 20030033199 | Coleman | Feb 2003 | A1 |
| 20030037331 | Lee | Feb 2003 | A1 |
| 20030046704 | Laksono et al. | Mar 2003 | A1 |
| 20030056217 | Brooks | Mar 2003 | A1 |
| 20030061619 | Giammaressi | Mar 2003 | A1 |
| 20030067554 | Klarfeld | Apr 2003 | A1 |
| 20030074565 | Wasilewski et al. | Apr 2003 | A1 |
| 20030077067 | Wu et al. | Apr 2003 | A1 |
| 20030088876 | Mao et al. | May 2003 | A1 |
| 20030093311 | Knowlson | May 2003 | A1 |
| 20030093784 | Dimitrova et al. | May 2003 | A1 |
| 20030093790 | Logan et al. | May 2003 | A1 |
| 20030093792 | Labeeb et al. | May 2003 | A1 |
| 20030095791 | Barton et al. | May 2003 | A1 |
| 20030101449 | Bentolila et al. | May 2003 | A1 |
| 20030101451 | Bentolila et al. | May 2003 | A1 |
| 20030110499 | Knudson et al. | Jun 2003 | A1 |
| 20030115612 | Mao et al. | Jun 2003 | A1 |
| 20030118014 | Iyer et al. | Jun 2003 | A1 |
| 20030135860 | Dureau | Jul 2003 | A1 |
| 20030139980 | Hamilton | Jul 2003 | A1 |
| 20030140351 | Hoarty et al. | Jul 2003 | A1 |
| 20030145323 | Hendricks et al. | Jul 2003 | A1 |
| 20030149975 | Eldering et al. | Aug 2003 | A1 |
| 20030161473 | Fransdonk | Aug 2003 | A1 |
| 20030179773 | Mocek et al. | Sep 2003 | A1 |
| 20030182261 | Patterson | Sep 2003 | A1 |
| 20030208763 | McElhatten et al. | Nov 2003 | A1 |
| 20030208783 | Hillen et al. | Nov 2003 | A1 |
| 20030214962 | Allaye-Chan et al. | Nov 2003 | A1 |
| 20030217365 | Caputo | Nov 2003 | A1 |
| 20030229681 | Levitan | Dec 2003 | A1 |
| 20030235393 | Boston et al. | Dec 2003 | A1 |
| 20030237090 | Boston et al. | Dec 2003 | A1 |
| 20040006625 | Saha et al. | Jan 2004 | A1 |
| 20040010807 | Urdang et al. | Jan 2004 | A1 |
| 20040031053 | Lim et al. | Feb 2004 | A1 |
| 20040045030 | Reynolds et al. | Mar 2004 | A1 |
| 20040078809 | Drazin | Apr 2004 | A1 |
| 20040101271 | Boston et al. | May 2004 | A1 |
| 20040103437 | Allegrezza et al. | May 2004 | A1 |
| 20040109672 | Kim et al. | Jun 2004 | A1 |
| 20040113936 | Dempski | Jun 2004 | A1 |
| 20040123313 | Koo et al. | Jun 2004 | A1 |
| 20040133907 | Rodriguez et al. | Jul 2004 | A1 |
| 20040146006 | Jackson | Jul 2004 | A1 |
| 20040158858 | Paxton et al. | Aug 2004 | A1 |
| 20040163109 | Kang et al. | Aug 2004 | A1 |
| 20040179605 | Lane | Sep 2004 | A1 |
| 20040181800 | Rakib et al. | Sep 2004 | A1 |
| 20040187150 | Gonder et al. | Sep 2004 | A1 |
| 20040187159 | Gaydos et al. | Sep 2004 | A1 |
| 20040193648 | Lai et al. | Sep 2004 | A1 |
| 20040193704 | Smith | Sep 2004 | A1 |
| 20040194134 | Gunatilake et al. | Sep 2004 | A1 |
| 20040226044 | Goode | Nov 2004 | A1 |
| 20040244058 | Carlucci et al. | Dec 2004 | A1 |
| 20040254999 | Bulleit | Dec 2004 | A1 |
| 20040255336 | Logan et al. | Dec 2004 | A1 |
| 20040261114 | Addington et al. | Dec 2004 | A1 |
| 20040261116 | McKeown et al. | Dec 2004 | A1 |
| 20040267880 | Patiejunas | Dec 2004 | A1 |
| 20040267965 | Vasudevan et al. | Dec 2004 | A1 |
| 20050010697 | Kinawi et al. | Jan 2005 | A1 |
| 20050034171 | Benya | Feb 2005 | A1 |
| 20050039205 | Riedl | Feb 2005 | A1 |
| 20050039206 | Opdycke | Feb 2005 | A1 |
| 20050041679 | Weinstein et al. | Feb 2005 | A1 |
| 20050047596 | Suzuki | Mar 2005 | A1 |
| 20050050160 | Upendran et al. | Mar 2005 | A1 |
| 20050055685 | Maynard et al. | Mar 2005 | A1 |
| 20050058115 | Levin et al. | Mar 2005 | A1 |
| 20050060742 | Riedl et al. | Mar 2005 | A1 |
| 20050060745 | Riedl et al. | Mar 2005 | A1 |
| 20050060758 | Park | Mar 2005 | A1 |
| 20050071669 | Medvinsky | Mar 2005 | A1 |
| 20050071882 | Rodriguez et al. | Mar 2005 | A1 |
| 20050076092 | Chang et al. | Apr 2005 | A1 |
| 20050086691 | Dudkiewicz et al. | Apr 2005 | A1 |
| 20050097598 | Pedlow, Jr. et al. | May 2005 | A1 |
| 20050108529 | Juneau | May 2005 | A1 |
| 20050108768 | Deshpande et al. | May 2005 | A1 |
| 20050108769 | Arnold et al. | May 2005 | A1 |
| 20050111844 | Compton et al. | May 2005 | A1 |
| 20050114141 | Grody | May 2005 | A1 |
| 20050114900 | Ladd et al. | May 2005 | A1 |
| 20050123001 | Craven et al. | Jun 2005 | A1 |
| 20050125528 | Burke, II et al. | Jun 2005 | A1 |
| 20050125832 | Jost et al. | Jun 2005 | A1 |
| 20050135476 | Gentric et al. | Jun 2005 | A1 |
| 20050152397 | Bai et al. | Jul 2005 | A1 |
| 20050168323 | Lenoir et al. | Aug 2005 | A1 |
| 20050198686 | Krause et al. | Sep 2005 | A1 |
| 20050210510 | Danker | Sep 2005 | A1 |
| 20050223409 | Rautila et al. | Oct 2005 | A1 |
| 20050276284 | Krause et al. | Dec 2005 | A1 |
| 20050283818 | Zimmermann | Dec 2005 | A1 |
| 20050289618 | Hardin | Dec 2005 | A1 |
| 20050289619 | Melby | Dec 2005 | A1 |
| 20060010075 | Wolf | Jan 2006 | A1 |
| 20060020984 | Ban et al. | Jan 2006 | A1 |
| 20060036750 | Ladd et al. | Feb 2006 | A1 |
| 20060037060 | Simms et al. | Feb 2006 | A1 |
| 20060047957 | Helms et al. | Mar 2006 | A1 |
| 20060050784 | Lappalainen et al. | Mar 2006 | A1 |
| 20060059098 | Major et al. | Mar 2006 | A1 |
| 20060059342 | Medvinsky et al. | Mar 2006 | A1 |
| 20060062059 | Smith et al. | Mar 2006 | A1 |
| 20060064728 | Son et al. | Mar 2006 | A1 |
| 20060066632 | Wong et al. | Mar 2006 | A1 |
| 20060073843 | Aerrabotu et al. | Apr 2006 | A1 |
| 20060075449 | Jagadeesan | Apr 2006 | A1 |
| 20060080408 | Istvan et al. | Apr 2006 | A1 |
| 20060084417 | Melpignano et al. | Apr 2006 | A1 |
| 20060085824 | Bruck et al. | Apr 2006 | A1 |
| 20060088063 | Hartung et al. | Apr 2006 | A1 |
| 20060117374 | Kortum et al. | Jun 2006 | A1 |
| 20060127039 | Van Stam | Jun 2006 | A1 |
| 20060130107 | Gonder et al. | Jun 2006 | A1 |
| 20060130113 | Carlucci et al. | Jun 2006 | A1 |
| 20060133398 | Choi et al. | Jun 2006 | A1 |
| 20060133644 | Wells et al. | Jun 2006 | A1 |
| 20060140584 | Ellis et al. | Jun 2006 | A1 |
| 20060171390 | La Joie | Aug 2006 | A1 |
| 20060171423 | Helms et al. | Aug 2006 | A1 |
| 20060173783 | Marples et al. | Aug 2006 | A1 |
| 20060197828 | Zeng et al. | Sep 2006 | A1 |
| 20060212906 | Cantalini | Sep 2006 | A1 |
| 20060218601 | Michel | Sep 2006 | A1 |
| 20060218604 | Riedl et al. | Sep 2006 | A1 |
| 20060248553 | Mikkelson et al. | Nov 2006 | A1 |
| 20060248555 | Eldering | Nov 2006 | A1 |
| 20060253328 | Kohli et al. | Nov 2006 | A1 |
| 20060253864 | Easty | Nov 2006 | A1 |
| 20060256376 | Hirooka | Nov 2006 | A1 |
| 20060271946 | Woundy et al. | Nov 2006 | A1 |
| 20060277569 | Smith | Dec 2006 | A1 |
| 20060291506 | Cain | Dec 2006 | A1 |
| 20060294250 | Stone et al. | Dec 2006 | A1 |
| 20070022459 | Gaebel, Jr. et al. | Jan 2007 | A1 |
| 20070033531 | Marsh | Feb 2007 | A1 |
| 20070047449 | Berger et al. | Mar 2007 | A1 |
| 20070053293 | McDonald et al. | Mar 2007 | A1 |
| 20070061818 | Williams et al. | Mar 2007 | A1 |
| 20070076728 | Rieger et al. | Apr 2007 | A1 |
| 20070078910 | Bopardikar | Apr 2007 | A1 |
| 20070089127 | Flickinger et al. | Apr 2007 | A1 |
| 20070094691 | Gazdzinski | Apr 2007 | A1 |
| 20070101157 | Faria | May 2007 | A1 |
| 20070101370 | Calderwood | May 2007 | A1 |
| 20070104456 | Craner | May 2007 | A1 |
| 20070106805 | Marples et al. | May 2007 | A1 |
| 20070113243 | Brey | May 2007 | A1 |
| 20070118852 | Calderwood | May 2007 | A1 |
| 20070121569 | Fukui et al. | May 2007 | A1 |
| 20070121678 | Brooks et al. | May 2007 | A1 |
| 20070124416 | Casey et al. | May 2007 | A1 |
| 20070124781 | Casey et al. | May 2007 | A1 |
| 20070130581 | Del Sesto et al. | Jun 2007 | A1 |
| 20070133405 | Bowra et al. | Jun 2007 | A1 |
| 20070153820 | Gould | Jul 2007 | A1 |
| 20070156539 | Yates | Jul 2007 | A1 |
| 20070157234 | Walker | Jul 2007 | A1 |
| 20070162927 | Ramaswamy et al. | Jul 2007 | A1 |
| 20070204300 | Markley et al. | Aug 2007 | A1 |
| 20070204310 | Hua et al. | Aug 2007 | A1 |
| 20070204311 | Hasek et al. | Aug 2007 | A1 |
| 20070204313 | McEnroe et al. | Aug 2007 | A1 |
| 20070204314 | Hasek et al. | Aug 2007 | A1 |
| 20070217436 | Markley et al. | Sep 2007 | A1 |
| 20070223380 | Gilbert et al. | Sep 2007 | A1 |
| 20070233857 | Cheng et al. | Oct 2007 | A1 |
| 20070241176 | Epstein et al. | Oct 2007 | A1 |
| 20070250872 | Dua | Oct 2007 | A1 |
| 20070250880 | Hainline | Oct 2007 | A1 |
| 20070271386 | Kurihara et al. | Nov 2007 | A1 |
| 20070274400 | Murai et al. | Nov 2007 | A1 |
| 20070276925 | La Joie et al. | Nov 2007 | A1 |
| 20070276926 | Lajoie et al. | Nov 2007 | A1 |
| 20080016526 | Asmussen | Jan 2008 | A1 |
| 20080022012 | Wang | Jan 2008 | A1 |
| 20080040403 | Hayashi | Feb 2008 | A1 |
| 20080052157 | Kadambi et al. | Feb 2008 | A1 |
| 20080066112 | Bailey et al. | Mar 2008 | A1 |
| 20080092181 | Britt | Apr 2008 | A1 |
| 20080098212 | Helms et al. | Apr 2008 | A1 |
| 20080098446 | Seckin et al. | Apr 2008 | A1 |
| 20080101460 | Rodriguez | May 2008 | A1 |
| 20080112405 | Cholas et al. | May 2008 | A1 |
| 20080134156 | Osminer et al. | Jun 2008 | A1 |
| 20080134165 | Anderson et al. | Jun 2008 | A1 |
| 20080134615 | Risi et al. | Jun 2008 | A1 |
| 20080141175 | Sarna et al. | Jun 2008 | A1 |
| 20080141317 | Radloff et al. | Jun 2008 | A1 |
| 20080152316 | Sylvain | Jun 2008 | A1 |
| 20080155059 | Hardin et al. | Jun 2008 | A1 |
| 20080159714 | Harrar et al. | Jul 2008 | A1 |
| 20080184297 | Ellis et al. | Jul 2008 | A1 |
| 20080192820 | Brooks et al. | Aug 2008 | A1 |
| 20080201748 | Hasek et al. | Aug 2008 | A1 |
| 20080209464 | Wright-Riley | Aug 2008 | A1 |
| 20080212947 | Nesvadba et al. | Sep 2008 | A1 |
| 20080229354 | Morris et al. | Sep 2008 | A1 |
| 20080235732 | Han et al. | Sep 2008 | A1 |
| 20080235746 | Peters et al. | Sep 2008 | A1 |
| 20080244667 | Osborne | Oct 2008 | A1 |
| 20080244682 | Sparrell et al. | Oct 2008 | A1 |
| 20080271068 | Ou et al. | Oct 2008 | A1 |
| 20080273591 | Brooks et al. | Nov 2008 | A1 |
| 20080276270 | Kotaru et al. | Nov 2008 | A1 |
| 20090010610 | Scholl et al. | Jan 2009 | A1 |
| 20090019485 | Ellis et al. | Jan 2009 | A1 |
| 20090025027 | Craner | Jan 2009 | A1 |
| 20090028182 | Brooks et al. | Jan 2009 | A1 |
| 20090037960 | Melby | Feb 2009 | A1 |
| 20090052863 | Parmar et al. | Feb 2009 | A1 |
| 20090052870 | Marsh et al. | Feb 2009 | A1 |
| 20090077614 | White et al. | Mar 2009 | A1 |
| 20090083813 | Dolce et al. | Mar 2009 | A1 |
| 20090100182 | Chaudhry | Apr 2009 | A1 |
| 20090100459 | Riedl et al. | Apr 2009 | A1 |
| 20090165053 | Thyagarajan et al. | Jun 2009 | A1 |
| 20090207866 | Cholas et al. | Aug 2009 | A1 |
| 20090210899 | Lawrence-Apfelbaum et al. | Aug 2009 | A1 |
| 20090210912 | Cholas et al. | Aug 2009 | A1 |
| 20090217326 | Hasek | Aug 2009 | A1 |
| 20090217332 | Hindle et al. | Aug 2009 | A1 |
| 20090220216 | Marsh et al. | Sep 2009 | A1 |
| 20090254600 | Lee et al. | Oct 2009 | A1 |
| 20090260042 | Chiang | Oct 2009 | A1 |
| 20090274212 | Mizutani et al. | Nov 2009 | A1 |
| 20090317065 | Fyock et al. | Dec 2009 | A1 |
| 20100061708 | Barton | Mar 2010 | A1 |
| 20100157928 | Spinar et al. | Jun 2010 | A1 |
| 20100223491 | Ladd et al. | Sep 2010 | A1 |
| 20100235432 | Trojer | Sep 2010 | A1 |
| 20100247067 | Gratton | Sep 2010 | A1 |
| 20100251289 | Agarwal et al. | Sep 2010 | A1 |
| 20110103374 | Lajoie et al. | May 2011 | A1 |
| 20110162007 | Karaoguz et al. | Jun 2011 | A1 |
| 20110264530 | Santangelo et al. | Oct 2011 | A1 |
| 20120014255 | Svedberg | Jan 2012 | A1 |
| 20120210382 | Walker et al. | Aug 2012 | A1 |
| 20120278841 | Hasek et al. | Nov 2012 | A1 |
| 20130227608 | Evans et al. | Aug 2013 | A1 |
| 20130325870 | Rouse et al. | Dec 2013 | A1 |
| 20140189749 | Gordon et al. | Jul 2014 | A1 |
| 20150271541 | Gonder et al. | Sep 2015 | A1 |
| 20150324379 | Danovitz | Nov 2015 | A1 |
| 20160191147 | Martch | Jun 2016 | A1 |
| 20160307596 | Hardin et al. | Oct 2016 | A1 |
| 20180097690 | Yocam et al. | Apr 2018 | A1 |
| 20180131975 | Badawiyeh et al. | May 2018 | A1 |
| Number | Date | Country |
|---|---|---|
| 2643806 | Jun 2013 | CA |
| 2405567 | Mar 2005 | GB |
| WO-0110125 | Feb 2001 | WO |
| WO-0176236 | Oct 2001 | WO |
| WO-0191474 | Nov 2001 | WO |
| WO-0219581 | Mar 2002 | WO |
| WO-2004008693 | Jan 2004 | WO |
| Entry |
|---|
| CableLabsel Asset Distribution Interface (ADI) Specification, Version 1 1, MD-SP-ADI1.103-040107, Jan. 7, 2004. pp. 1-26. |
| Cisco Intelligent Network Architecture for Digital Video—SCTE Cable-Tec Expo 2004 information page, Orange County Convention Center, Jun. 2004, 24 pages. |
| Deering et al., Internet Protocol, Version 6 (Ipv6) Specification, IETF RFC 2460 (Dec. 1998). |
| DOCSIS 1.0: Cable Modem to Customer Premise Equipment Interface Specification, dated Nov. 3, 2008, 64 pages. |
| DOCSIS 1.1: Operations Support System Interface Specification, dated Sep. 6, 2005, 242 pages. |
| DOCSIS 1.1: Radio Frequency Interface Specification, dated Sep. 6, 2005, 436 pages. |
| DOCSIS 2.0: Radio Frequency Interface Specification, dated Apr. 21, 2009, 499 pages. |
| DOCSIS 3.0: Cable Modem to CPE Interface Specification, dated May 9, 2017, 19 pages. |
| DOCSIS 3.0: MAC and Upper Layer Protocols Interface Specification, dated Jan. 10, 2017, 795 pages. |
| DOCSIS 3.0: Operations Support System Interface Specification, dated Jan. 10, 2017, 547 pages. |
| DOCSIS 3.0: Physical Layer Specification, dated Jan. 10, 2017, 184 pages. |
| DOCSIS 3.1: Cable Modem Operations Support System Interface Specification, dated May 9, 2017, 308 pages. |
| DOCSIS 3.1: CCAP Operations Support System Interface Specification, dated May 9, 2017, 703 pages. |
| DOCSIS 3.1: MAC and Upper Layer Protocols Interface Specification, dated May 9, 2017, 838 pages. |
| DOCSIS 3.1: Physical Layer Specification, dated May 9, 2017, 249 pages. |
| Griffith, et al.,Resource Planning and Bandwidth Allocation in Hybrid Fiber-Coax Residential Networks, National Institute of Standards and Technology (NIST), 10 pages, no date. |
| Internet Protocol DARPA Internet Program Protocol Specification, IETF RFC 791 (Sep. 1981). |
| Kanouff, Communications Technology: Next-Generation Bandwidth Management—The Evolution of the Anything-to-Anywhere Network, 8 pages, Apr. 1, 2004. |
| Motorola DOCSIS Cable Module DCM 2000 specifications, 4 pages, copyright 2001. |
| OpenVision Session Resource Manager—Open Standards-Based Solution Optimizes Network Resources by Dynamically Assigning Bandwidth in the Delivery of Digital Services article, 2 pages, (copyright 2006), (http://www.imake.com/hopenvision). |
| OpenVision Session Resource Manager features and information, 2 pages, no date, (http://www.imake.com/hopenvision). |
| SCTE 130-1 2008 Digital Program Insertion—Advertising Systems Interfaces standards. |
| SCTE 130-10 2013: Digital Program Insertion—Advertising Systems Interfaces Part 10—Stream Restriction Data Model. |
| SCTE 130-2 2008a: Digital Program Insertion—Advertising Systems Interfaces Part 2—Core Data Elements. |
| SCTE 130-2 2014 Digital Program Insertion—Advertising Systems Interfaces standards. |
| SCTE 130-3 2013: Digital Program Insertion—Advertising Systems Interfaces Part 3—Ad Management Service Interface. |
| SCTE 130-4 2009: Digital Program Insertion—Advertising Systems Interfaces Part 4—Content Information Service. |
| SCTE 130-5 2010: Digital Program Insertion—Advertising Systems Interfaces Part 5—Placement Opportunity Information Service. |
| SCTE 130-6 2010: Digital Program Insertion—Advertising Systems Interfaces Part 6—Subscriber Information Service. |
| SCTE 130-7 2009: Digital Program Insertion—Advertising Systems Interfaces Part 7—Message Transport. |
| SCTE 130-8 2010a: Digital Program Insertion Advertising Systems Interfaces Part 8—General Information Service. |
| SCTE 130-9 2014: Recommended Practices for SCTE 130 Digital Program Insertion—Advertising Systems Interfaces. |
| SCTE Standards Document ANSI/SCTE 130-1 2013 entitled “Digital Program Insertion—Advertising Systems Interfaces, Part 1—Advertising Systems Overview,” 20 pages. |
| SCTE130-3 2010: Digital Program Insertion—Advertising Systems Interfaces Part 3—Ad Management Service Interface. |
| Wikipedia, Digital Video Recorder, obtained from the Internet Nov. 11, 2014. |
| Number | Date | Country | |
|---|---|---|---|
| 20170353768 A1 | Dec 2017 | US |
