Slashdot Mirror
Microsoft FAT Patent Rejected
dkh2 writes "It's being reported other places as well but, there's a very nice story over at Groklaw about efforts by the Public Patent Foundation (PubPat) to get Microsoft's patent on FAT restricted or revoked. Bearing in mind that Microsoft still has right of appeal, The USPTO has rejected Microsofts FAT patent." Our earlier story reported on efforts to overturn this patent.
i think i should remind everyone, this patent is not on the FAT filesystem itself, but the VFAT extension for long file names. (which, if you know how it works, is nothing innovative)
Marge, get me your address book, 4 beers, and my conversation hat.
...such as the following:
U.S. Patent #5,579,517 - Common name space for long and short filenames
U.S. Patent #5,745,902 - Method and system for accessing a file using file names having different file name formats
U.S. Patent #5,758,352 - Common name space for long and short filenames
U.S. Patent #6,286,013 - Method and system for providing a common name space for long and short file names in an operating system
http://tinyurl.com/4ny52
Of course. I think you'll find this article most enlightening. My favorite quote is:
SPEs want these new employees to gain experience rejecting patent applications, and there is considerable pressure on these new hires to do so.
Javascript + Nintendo DSi = DSiCade
FAT itself was never patented. This patent was covering Microsoft's scheme for packing long filenames into the old FAT system in such a way that a short filename (microso~1.txt et al) is persistently perserved for old DOS apps.
Microsoft felt that their innovation of a particular data structure (the same kind of elementary data structure that sophomore CS majors put together all the time) ought to be sufficient to allow them to control who gets to read and write from flash media, and etc., which adopted the format simply because that was the only thing that Windows could be relied upon to understand.
The loss of this patent strikes no blows against the freedom to innovate, believe me.
- jon
Ganymede, a GPL'ed metadirectory for UNIX
[...] They are effectively ruling that Microsoft cannot hold a patent on software they created. [...]
The FAT filesystem itself is not "software", it is a specification. You only talk about "software" when you think of an implementation of FAT, like those found in Windows and the Linux kernel.
Score: i, Imaginary
The patent was for aspects of the long filenames introduced with Win95. They were used in the "VFAT" filesystem and its successors.
If file system compatibility really helped THAT much, then BeOS would have owned Linux and Be would be a viable contender today. BeOS' support for Fat32 and NTFS, especially in how easy it was for users to mount them from the desktop, was well above that of the Linux desktops of BeOS' day. When you wanted to mount a drive, a right click on the desktop showed the Fat32 and NTFS partitions as plainly as a BFS partition so the whole process was the same to John Q. Not only that, but BeOS back then also automatically recognized new partitions, something Linux did not and still doesn't seem to do well.
What keeps people loyal to Microsoft in the U.S. is the popularity of its products combined with the variety of games and home software for Windows. Office and Windows have a symbiotic relationship, you take down one, the other goes down eventually, but Windows is more important to Microsoft because the home market provides a solid foundation for Office. Installing a game on Windows is easy for the average home user, but not on Linux.
Game developers don't want to waste their time getting around that. Until a very comprehensive, attractive way to install home software is availible, Linux and other OSS projects will be left behind. The best way for Linux developers to get around this is probably to make a concerted effort to emulate Apple's framework system so that all of the dependencies one needs to have in place are part of the Linux game's ".app directory." Either that or program the games in a combination of C# and C and pray that Mono doesn't die on users.
Maybe it's just my perspective, but interoperability with things like FAT only do so much for the average user. In the long run, it's a lot more complicated than that. If interoperability were the key, then BeOS and MacOS X would have eaten Windows alive a long time ago.
Click here or a puppy gets stomped!
The patent was rejected based on prior art.
From the patent office rejection statement:
"...patent may not be obtained though the invention is not identically disclosed or described as set forth in section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains."
Even for this case alone, these guys deserve our support.
Because it covers only one method of long filename to short filename conversion.
The scheme patented covered one possible way to convert long filenames into valid dos names by truncating the name and adding ~nn. Windows does this by counting the number of short names, and using this count as the nn value. E.g.
ALongFilename1.txt will have short name ALONGF~1.TXT
ALongFilename2.txt will have short name ALONGF~2.TXT
This is bad because you need to make multiple scans thought the directory to generate the short filenames. There is another patent for a data structure to speed this process up.
You don't have to use this short filename generation method - VxWorks dos FS 2.0 uses a hex hash of the long filename for instance. Thus you'd get this
ALongFilename1.txt will have short name 37f38765.TXT
ALongFilename2 will have short name (more random gibberish).
The idea here is that if you never use Dos, the ugliness of the short filenames doesn't really matter because you only see the long ones.
You could also use the position in the directory for the last two numbers - there are endless possibilities. Provided you link the long filename and short filename correctly - there is a checksum byte in the long filename which links back to the short one, Windows will still be able to see both versions of the filename.
Of course for many applications like digital cameras, 8.3 is still OK.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
Take away all of IBM's bogus patents and it will still hold one of the biggest patent portfolios on the planet. That cannot be said of Microsoft.
A Pirate and a Puritan look the same on a balance sheet.
U.S. Patent #5,579,517
U.S. Patent #5,745,902
U.S. Patent #5,758,352
U.S. Patent #6,286,013
If Mr. Ravicher is correct and 70% of patents are revoked in re-examination, then at least one of these will survive.
> The answer lies in the patent lawyers who draw up the papers. What they'll do, is that they'll draw up revision after revision of the idea until the patent office is confused enough to grant it.
:-(
I can vouchsafe for this. I have written several disclosures, some of which later made it into patent applications. The applications that the lawyers came up with, based on my disclosures, rendered the original idea unrecognizable - even to me!
The final documents were so vague and open to interpretation, that they could apply to just about anything. It's not surprising that so much crap makes it
It's not too hard to connect the dots and see the relationship between OSRM's business model (which benefits from reduced patent risk for Linux) and PUBPAT's agenda, which is to rid the world of bogus patents.
Since this is Slashdot, I don't expect many people will recant their negative comments about OSRM, but I hope most people recognize this as the type of work that OSRM/PUBPAT can do that will have some real positive benefits for Linux, whether you buy OSRM's insurance or not.