PUBPAT Challenges Microsoft's FAT Patent 396
An anonymous reader writes "The Public Patent Foundation filed a formal request with the United States Patent and Trademark Office today to revoke Microsoft Corporation's patent on the FAT File System, touted by Microsoft as being 'the ubiquitous format used for interchange of media between computers, and, since the advent of inexpensive, removable flash memory, also between digital devices.' In its filing, PUBPAT submitted previously unseen prior art showing the patent, which issued in November 1996 and is not otherwise due to expire until 2013, was obvious and, as such, should have never been granted."
Re:About time... (Score:5, Informative)
Donate! (Score:5, Informative)
Re:Erghh (Score:5, Informative)
Re:Erghh (Score:4, Informative)
Maybe for PC OSes, but have you used a CF or SD card in a digital camera? Or a memory stick? or any other small portable data container? They all use FAT32 or some related FS. The inneficeincies of teh format don't really apply to the media like that.
About time (Score:5, Informative)
I don't see how this patent could possibly be held valid...well...wait a minute...this is the US Patent Office we're talking about here. We should be afraid.
Re:Sadly... (Score:5, Informative)
Re:Sadly... (Score:3, Informative)
Second, If it wasn't a bogus patent being weilded for compeitive advantage, no one would have requested a re-examination.
It's actually the long file names patent (Score:5, Informative)
5,579,517
which covers the "long file names" stuff Windows 95 introduced, and they site two patents:
5,307,494 to Yasumatsu et al., and
5,367,671 to Feigenbaum et al.
as new prior art.
Re:About time... (Score:5, Informative)
Re:About time (Score:5, Informative)
Don't think so...
From 'Beneath Apple DOS', the major structural elements are..
VTOC - Volume Table of Contents
The Catalog - Kind of obvious
The Track/Sector List - Also kind of obvious
Did anyone bother to read these patents? (Score:5, Informative)
Re:About time... (Score:5, Informative)
Patent is on storing long filenames (Score:5, Informative)
Basically the issue is this... in FAT there are a fixed number of bytes to each file entry in the directory. It is only enough for 8+3 character filename. They could not just expand on this data structure because it would not be backward compatible. What they realized is that if you created a filename with the system, hidden and some other attributes set, the old versions of dos would never display the filename. So what they do to store a long filename is create multiple file entries each storing a few bytes of the long filename plus some additional data to piece it together. Basically in a old version of dos, these extra file entries would never be displayed but in windows 95 or newer, it would read and maintain both the short filename entry and the long filename entries.
Re:4DOS? (Score:3, Informative)
Re:4DOS? (Score:3, Informative)
Patents don't cover a concept, they cover a method.
Re:Let's See More of That Idea! (Score:3, Informative)
It seems to me that what you're suggesting is roughly equivalent to sentancing amputation to a known, non-repentant jay-walker - just because you know he's non-repentant. The law against jay-walking never described such a penalty, and it's not fair to make one up now. The anti-trust laws never described the penalty you suggest, and it would be equally unfair to impose on M$.
Re:I think that's the whole point (Score:4, Informative)
Unlike copyright where MPAA, RIAA and other SIGs have purchased legislative insurance, there are not ( to my knowledge) any criminal penalties for patent infringement.
Re:About time... (Score:5, Informative)
Their specific implementation however might not be challengable, seeing as how they DID invent it. There's a chance however since IIRC patent law gives you only 1 year after public introduction to patent said invention or you lose the right to patent it. The problem then becomes a game of dates and when it was "public" (do wide spread betas count? It WAS indevelopment for 4 years), and when did they submit the patent.
Re:About time... (Score:5, Informative)
No, it was not a hardware limitation, just as the Cobol Y2k problem was not a hardware limitation. Just a stupid design.
Re:wow, what's the big deal (Score:5, Informative)
a) Using a lookup table (to convert betwen long and short)
b) Using a hashing algorithm (to create short from long).
Its pretty obvious that these are entirely novel solutions to a unique problem, and are nothing to do with the use of hashing algorithms (eg during WWII) or lookup tables (eg civilisations prior to the ancient greeks)
The truth is, these absolutely must be novel, because ...[need more coffee]
Re:Because you need to solve a goddamn problem (Score:1, Informative)
That's Schick. They make the "Quattro". Gillette makes the "Mach 3".
Re:About time... (Score:1, Informative)
Someone has already replied to this saying people wouldn't bother trying to patent an obvious idea. There is a sense though, in which I don't think the idea is obvious, which is this: if I had been looking for a way to extend the FAT file system with long filenames, I probably would not have seriously considered storing this information in file entries, because it is both inelegant and ineffecient. (But given that the information about long filenames is to be stored in file entries -- and the only reason I can think of for doing this is to avoid the effort involved in doing the job properly -- then I do think the method used in VFAT is obvious.)
This leads me to something else that has also been pointed out elsewhere, but not stressed enough, I think: This patent is for a way of doing something which has already been done better before (several times in fact).
OS/2 had EAs (extended attributes) for the FAT filesystem in a hidden file. There was a Macintosh utility (PC Exchange?) which accessed the FAT filesystem, and put Macintosh file attributes in a hidden file. (And if we look beyond the FAT filesystem, there's the RockRidge extensions for ISO CD-ROMs, and probably many others I haven't thought of.)
Surely this is an important point which warrents inclusion in the request to revoke the patent. The patent does not actually achieve anything new. I recognise that some patents are on methods of achieving something that can be achieved by another means, but surely the idea being patented should at least have some kind of advantage over other methods at least in some respect or situation.
I can't see that VFAT has any real advantage over previously existing methods. In fact, it seems quite the opposite. I expect that Microsoft could have used OS/2's EA system with a better result. (Well, unless there's a patent on it.)
All said though, I don't think this is quite as absurd as Microsoft's patent on the "Start" button (I think I had an old microwave-oven with prior art).
--
James G
Re:About time... (Score:4, Informative)
Was it a public beta or was it not? If you publicly disclose that you have a black box that turns a fish into chicken (and with the way DNA research is going, don't laugh at it) publicly, it is your responsibility to patent it.
Just because nobody may not know the workings of the black box does not make it any less your responsibility to patent it. Because unless the patent examiner grants you the patent and hence the monopoly on it you don't have exclusive rights to it.
So, if you publish that you have a machine (or let the public use it, like in a beta) that turns a fish into chickens, you have a year to file tha patent on it. After that year, your exclusive rights to the secret box that turns fish into chickens evaporates. Anybody can use the idea and make a box that does the same thing.
But that was not what is at argument here. What is being challenged here is that the FAT file system is not really a "novel" or "unique" idea in the first place, but rather obvious for those who are familiar with the technology.
The three qualifications for a patent are usefulness, novelty, and it has to be nonobviuos [intellectual.com]
As the article states, and why this will be important in the future, the patent office granted a patent to something that was obvious.
The problem is not patents themselves (and I would argue that software patents are not entirely bad if held to the original standards that they were supposed to be under), but that the patent examiner will slap a patent on anything that walks through the door.
For one reason or another the patent office is broken (not enough money), with the attitude that rather than themselves having to put a critical eye torward something that may be obvious, they decide to not do this and let a judge later sort it out.
Which is wrong, and just another example why our government is broken in more ways than one.
Admittedly, it costs a lot of money to hire an examiner that is familiar with often arcane (but important) technologies. But it does not let the patent office off the hook.
What we have is people who are getting a software patent equivalent to a patent on breathing air.
The business method patents (this kind of patent is worse than software, as it has no technology behind it) come to mind, like the "ecommerce" one.
Some would argue that software patents should never have been granted because it is a "slippery slope". I think they are right. The original software patents were granted to machines that controlled the vulcanization of rubber (novel and nonobvious) and another that read data off seisometers.
We have slid from that all the way down to the "one click" patent to buy something.
Anyway, this is an important fight that needs to be won.
Re:About time... (Score:3, Informative)
The challenge by PUBPAT has a long breakdown of how each and every claim in the Microsoft patent is claimed by the prior art patents. So, the prior art claimed is not just some other previous implementation, but laid out clearly in two previous patents. It would seem to be a slam dunk if you read the details of the request for reexamination.
Re:About time... (Score:4, Informative)
Re:About time... (Score:3, Informative)
"All fees available to the Director under section 31 of the Trademark Act of 1946 shall be used only for the processing of trademark registrations and for other activities, services and materials relating to trademarks and to cover a proportionate share of the administrative costs of the Patent and Trademark Office."
It may be doing a lousy job of it, but it ain't no IRS.
Re:About time... (Score:3, Informative)
No it was incompetence. Apple DOS (even before ProDOS) had long file name support. That was wayyy back in like 79-80.
Re:About time... (Score:3, Informative)
Not actually true. FAT first appears in the Stand-alone Disk BASIC written by Marc McDonald for MicroSoft back about 1977. When Tim Patterson kludged together QDOS in 1980, he used FAT, but he didn't invent it, it had already been in use for around 3 years.
Re:About time... (Score:3, Informative)
Well, actually, fixed file name lengths make your record lengths fixed, which makes it MUCH faster to parse through the data (does anyone who runs a major database waht to back me up here?). There was a day before fast hard drives and back when processor speed was measured in single digit MHz. People used to BOOT from a floppy disk on computers without a fixed disk. Do you REALLY want long file names and, hence, a larger directory structures on your floppy-based computer?! The 8.3 convention was probably intended to make sure that parsing large directories didn't take up a significant portion of the CPU time (go type "dir" on A:\ and tell me if it responds fast enough for you), and also to make it easier for applications that required access to files could more easily store those filenames.
It's especially useful for small apps that need to TSR (terminate and stay resident). Often, large chunks of these were written in assembly language! Do you really want to implement "copy or compare data from this pointer to a pointer until you get a 0x00" in assembly just to copy or compare a filename?
For the programmer types, we're talking about the difference between a pointer to a fixed-length string and a pointer to a pointer to a variable length string (since you couldn't fit variable length strings in a fixed-length directory entry). Pointer operations are always slow, but they used to be even slower on older processors.
Also, the original MSDOS didn't have the nice up/down arrow to repeat previous commands feature in 4DOS (did 4DOS also have tab-key completion?), so typing long filenames would be tedious (wow, that was back before GUIs! Anyone remember Norton Utilities?).
Re:About time... (Score:4, Informative)
No.
"FAT" systems store the allocation table as a singly linked list on disc. Two copies, in case one gets mangled (but they are adjacent, which is not good). The directory is a list of names, and starting indexes into the allocation table. This makes random access bad, because you have to keep traversing the singly linked list to find blocks. (DOS of early vintage).
CP/M also uses an allocation table, but it is not stored on disk. Instead, a file is broken into "extents". Each extent has a directory entry, and a fixed number of pointers to disk clusters. A single file will have more than one directory entry, if it contains multiple extents.
CP/M built the allocation map for the disc when the disc is "mounted" (used the first time). It does this by reading the directory, and marking blocks that are in use by files.
With FAT, you can have "cross linked" files. The singly linked lists representing the data blocks point into each other. With CP/M you can have multiple directory entries refer to the same data blocks as well. CP/M allows "sparse" files, which FAT doesn't. CP/M has better random access (two levels of index), although many programs pre-built access lists for DOS to improve random file performance (I did that for one application).
CP/M limited file names to emulate PDP-10, FAT limited file names to emulate CP/M -- it's a push.
And, finally, the patent is NOT on FAT, it is on the long file name extensions introduced with Windows 95.
A "FAT" system was in place with Microsoft Disc Basic (AFAIR), Zilog also used a singly linked list block map in their Z80 development platform. I am sure that there is plenty more "prior art" for FAT.
The idea of stored a hash long name into a fixed length directory in multiple pieces, using keys and checksums -- that is what is being contested.
Ratboy
What about ProDOS? (Score:2, Informative)
ZZ
Re:About time... (Score:3, Informative)
I remember AT&T UNIX versions 6 and 7 had 14-character filenames.
Longer filenames didn't appear until BSD UNIX (around 1980).
This was done so that the filename and (16-bit) i-number could fit into 16 bytes.
(Note that this limited the number of files on a filesystem to 65536.)
I remember using an OS on a PDP-11 that squeezed 6+3 filenames into six bytes (upper-case + digits + some punctuation) back in the 1970s.
Storage was very, very expensive back then.
People did what they could to conserve space, including using short file names and two-digit years.
Their design decisions were in no way "stupid".