Stretching is the name of the game. I like the idea of TiVo, but to qualify as prior art, we need a publication. Simply find a product user manual (non-patent literature). Also, TiVo has many patents that also may disclose the ideas we're looking for.

The TiVo certainly downloads data when it records, where download is the transferring of data (audio and video) from one computer to another. I'd have to look at an early TiVO manual to see how well it meets the channel depth limitation. Further, the pre-defined channel is a tad tricky, but the TiVO box somehow knows what a season of content looks like. Is it pre-defined? Maybe. Maybe even the consistent name of the show from the guide information gives us pre-defined.

So independent claim 1 could probably be knocked out, but dependent claim 3 and its children would be novel limitations over our imagined TiVo art.

So that no one is confused, the key limitations probably are in bold. I have not searched this patent, nor have I looked at the prosecution history. I further am not a registered patent attorney or agent. User takes all risk. Void where prohibited. Batteries not included?

It depends. If the difference is insignificant (e.g., inventor claims a blue button and the prior art indicates a red button, where the color of the button is arbitrary to the invention at hand), then no secondary art needs to be found to teach the insignificant feature. I'm guessing, however, that pretty simple refers to the ease of implementation. Remember that hindsight may not be relied upon. It is easy to add file sizes and track length to an RSS feed, but that has nothing to do with obviousness. To present a case for obviousness (if the bold limitations in my GP post are the ones missing), an ordinary person skilled in the art at the time the invention was made would have needed to combine the channel depth (file size and track length) concept with the podcasting idea. If some reference A about podcasting teaches all the limitations of the claim except for the channel depth, and reference B teaches channel depth in a similar application, and motivation for adding the channel depth can be found, then, and only then, is it an obvious limitation.

I'm kinda feeling lazy right now, but with a fair amount of patent experience under my belt, I'd say the key limitations of '213 Carhart et al. are in bold below:

A method for providing episodic media, the method comprising: providing a user with access to a channel dedicated to episodic media, wherein the episodic media provided over the channel is pre-defined into one or more episodes by a remote publisher of the episodic media; receiving a subscription request to the channel dedicated to the episodic media from the user; automatically downloading updated episodic media associated with the channel dedicated to the episodic media to a computing device associated with the user in accordance with the subscription request upon availability of the updated episodic media, the automatic download occurring without further user interaction; and providing the user with: an indication of a maximum available channel depth, the channel depth indicating a size of episodic media yet to be downloaded from the channel and size of episodic media already downloaded from the channel, the channel depth being specified in playtime or storage resources, and the ability to modify the channel depth by deleting selected episodic media content, thereby overriding the previously configured channel depth.

Finding the old podcast applications and checking for that particular feature takes a bit of work. If anyone happens to have an old version of AmphetaDesk or Radio UserLand, perhaps they include a feature that would read on indicating channel depth. Remember, the prior art needs either to disclose each and every limitation of the claimed invention, or be combined with additional prior art that fills in the missing pieces, along with a motivating rational for combining the art.

The root hubs aren't really discrete hubs like you might plug into a port. They don't supply power, just data. The power, VBUS, is supplied through the motherboard (from your main 5.0 V rail) and has no bearing on the hub, except an over-current limiter signal going back to the root hub. An external, self-powered hub would be limited to the 500 mA as you say, sharing its current among the available ports (and itself).

Your phone may also actually draw more than 500 mA when it is plugged into the charger.

I'm really not sure by what you mean when you say "the 500mA is shared by the hub." There is no host-side current limiting, except to prevent short circuits (e.g., Polyfuse). The device is responsible for limiting its own current draw (such as by not turning on its battery charging circuitry). In this case, your phone is behaving itself and not charging until the software driver says it can. You can look at your phone in Windows Device manager and determine how many units (1 unit = 100 mA) the phone has negotiated to draw.

All the built-in USB ports in modern machines (even laptops) can source the full 500 mA. You'll probably find the limitation in the driver.

You certainly can pull 500 mA from a port without the device asking politely, but it won't be compliant with the spec. From the USB 2.0 spec, 7.2.1, "Devices must also ensure that the maximum operating current drawn by a device is one unit load (100 mA), until configured."

The 5.0 V rail, VBUS, does not monitor the sourced current, making sure that no devices are drawing more than what they've politely asked for. The current limiting is done to protect against a direct short, often limiting a single port to 1 A (or more for ganged ports higher)