Slashdot Mirror
Patent Issued For Podcasting
pickens writes "The EFF is reaching out for help after a company called Volomedia got the Patent Office to grant them exclusive rights to 'a method for providing episodic media' that could threaten the community of podcasters and millions of podcast listeners. 'It's a ridiculously broad patent, covering something that many folks have been doing for many years,' writes Rebecca Jeschke. 'Worse, it could create a whole new layer of ongoing costs for podcasters and their listeners.' To bust this patent, EFF is looking for additional 'prior art' — evidence that the podcasting methods described in the patent were already in use (PDF) before November 19, 2003. 'In particular, we're looking for written descriptions of methods that allow a user to download pre-programmed episodic media like audio files or video files from a remote publisher, with the download occurring after the user subscribes to the episodes, and with the user continuing to automatically receive new episodes.'"
I wonder if it counts since it is:
Episodic content............. Check
Web Posted................... Check
Already Up in 1993.......... Check
Just my 1 cent of useless info...
Mortality.net Radio was posting episodes back in February 2002. The kicker is how it applies to the patent. It satisfies Claim 1A, but none of the others like subscription, auto-downloading, or showing if there is space remaining for the download (except how that is already covered in operating systems and/or web browsers).
From The Door Into Summer by Robert A. Heinlein (1956):
There wasn't anything really new in it; it was just the way that I put it together. The "spark of genius" required by our laws lay in getting a good patent lawyer.
TiVo meets all those conditions.
Ascalante: Your bride is over 3,000 years old.
Kull: She told me she was 19!
It seems to me that this is describing a subset of push technology, such as PointCast back in the day, and even those "channels" you used to be able to subscribe to in Windows 95. PointCast predates this patent app by a number of years.
There are two kinds of people: 1) those who start arrays with one and 1) those who start them with zero.
I would like someone who is informed about the patent process to clarify for me, and by extension the /. community, an aspect of the patent process that I do not understand and seems to be a point of confusion among readers here:
If a patent is (wrongly) awarded for a technology that has been covered by prior art, even if the prior art has not previously been patented, what is the legal status of the patent and the prior art? Can the patent be a threat to prior art (could previously existing podcasting/RSS technology be threatened by legal challenges)? Would a challenge by the patent holder risk invalidating the patent when the defendant produced evidence of prior art? In the event of a legal battle where the patent was found to be invalid due to prior art, who would be responsible for legal costs?
So if this is the future...where's my jet pack?
Streaming is irrelevant. The patent is about downloading and managing subscriptions to audio files. It covers fetching new files when they're updated and making room on local storage by deleting older files.
Come to think of it, the best prior art for this is Usenet. Audio newsgroups contained audio files that were subscribed to by the user and news server software would make room for new files by deleting the old.
Yep, I think that'd about do it.
Also, the RSS standards history can probably point to some earlier implementations of client-side file management if you follow it down the rabbit hole far enough.
IMAP.
1. Email INBOX is a channel where-in publishers of emails can provide episodic media
2. IMAP clients "subscribe" to a channel (server + folder)
3. IMAP clients automatically download updated episodic media from the channel without further interaction by the user
4. IMAP can be configured to give stats about "channel metadata" and get rid of old media (auto archive of emails over X days old, ect)
It could also apply to usenet feeds -- I'm sure alt.binaries.tv.simpsons was performing this via Netscape, tin, pine, and other clients long before.
A. Claim 1
Claim 1 covers a method for subscribing to a media channel that contains predefined
episodic media and downloading that episodic media for later use. Claim 1
contains the following steps:
Allowing access to a channel that contains pre-defined episodic media; [check]
Allowing the user to subscribe to a channel that contains the user’s desired episodic
media; [possibly, depending on client]
Automatically downloading the user’s selected episodic media whenever that media
has been updated; and [possibly, depending on client]
Showing the user the amount of space the user has left in certain channels and how
much space is needed to finish downloading the selected episodic media; if there is
not enough space left for the download, then the user may select what episodic media
to delete.[all of these are true for Netscape Communicator]
B. Claim 2
Claim 2 is dependent on claim 1, but adds the limitation that the user is
“automatically” provided with an indication that updated episodic media content is
available.
Netscape Communicator again.
C. Claim 3
Claim 3 is dependant on claim 1, but adds the additional limitation of allowing the
user to synchronize the downloaded episodic media to a portable computing device.
Not sure about this one.... When was AvantGo created for PalmOS?
D. Claims 4 and 5
Claims 4 and 5 are dependent on claim 1, but add the additional limitations that
synchronization occurs in response to either a “predetermined user setting” or a
request from the user.
All of the above.
E. Claim 6
Claim 6 is dependant on claim 1, but adds the additional limitation of making the
updated episodic media available to users over a local area network.
Not sure what they mean by this... limited to the LAN, or it bridges the firewall?
Either way, usenet handles this with local caches.
F. Claim 7
Claim 7 is dependent on claim 1, but adds the additional limitation that the
automatic download is “based on a priority” assigned to the channel by either the user or
the system.
They might actually have something with this one... most priority-based mechanisms I know of are post-2003.
G. Claims 8 and 9
Claim 8 is dependent on claim 3, but adds the additional limitation that the
channel is “reduced in size” during synchronization. Claim 9 is dependent on claim 1,
but adds the additional limitation that the channel is “modified in size.” For example, if
the user does not have enough available space on its personal computer or other portable
device to download the entire synchronization, the user or system may select that portion
it wishes to download up to the point where all the available space has been used up.
AvantGo or Plucker for PalmOS definitely meet this, depending on when they first appeared.