Patent Claimed on System-Level Encryption
nattt writes "The Register is reporting that a Californian firm, Maz Technologies has been granted a patent for application independant file encryption, and is now going after other companies with its lawyers to press its claims. It seems that the US patent office doesn't check very well for prior art, and their laxity is causing small firms that get attacked on infringing these bad patents a lot of money to defend themselves."
Just a thought ... would it be possible for these small companies to sue the US Patent Office for costs relating to bad patents?
Now we don't have to worry about CBDTPA. Because even if the FCC tells the tech industry to adopt encryption to protect content, we can say "Sorry Disney, er, FCC...but that technology has been patented!"
Why didn't we think of this. Let's get patents on watermarking and other intrusive technologies being rammed down our throats by content providers. Then just sit on them and thumb our noses.
- JoeShmoe
.
-- I wonder which will go down in history as the bigger failure: the War on Drugs or the War on Filesharing
If they are suing already, doesn't that invalidate the patent by demonstrating prior art before the patent was applied for?
"No good deed goes unpunished"
We need more bad patents like this. The more of a problem this becomes, the more likely Congress is going to do something about it. And as long as the patents are as ridiculous as this one, and as long as they go after companies with money before they go after open source, everything's fine as far as I'm concerned.
Wouldn't it be funny if some organization in the US government has prior art on this patent? Say the NSA or FBI, perhaps the Army, Air Force or CIA? Somewhere in there somebody developed a computer system which encrypted every single communications which took place at the system level.
The nice folks over at sci.crypt seems to have listed quite a few cases of possible prior art.
Not that that makes it much better on the whole, but...
Belief is the currency of delusion.
Attack the small firms first so they cannot afford to invalidate the patent. Meanwhile when the small firms start paying royalties your patent will become more established. By the way the 25 000 in royalties is nothing compared to what the case may cost. So that company will probably pay the fee if hey cannot get an early win in court.
secret use is not prior art.
But if the above mentioned agency put their computer on sale, or used it publicly then it would be prior art.
Why not directly sue Microsoft, Sun, HP, IBM? Somewhere along the line one of these companies offered system level encryption.
Or maybe this dinky unknown company saw a way to squeeze money out of little companies who they thought couldn't afford to fight back?
This would seem to be a good example of how the patent system is being mis-used at present. Apparently this patent is very widely defined and not backed up by much 'implementation'. this would generally not be considered a very 'defendable' patent, yet the owners are trying it on with a bunch of middle level software vendors, trying to strong arm some cash from them.
w here sfs (Secure File System) exists, and this page was LAST updates in september 1996, and covers just about every possible level of eccryption in a general file system, it is also not unique.
The difficulty with this is that the patent gives the owner a degree of 'high-ground', and defending against this from the point of view of the apparent patent violator, can be VERY expensive, so often just coughing up is the cheapest option, which then lends weight to the defendability of the patent.
Certainly, being filed in 1998 makes this particular patent laughable.
for exmaple, have a look at:
http://www.cs.auckland.ac.nz/~pgut001/sfs/
We need look no further than our good friend the Clipper chip for a good example of government created prior art that is covered by this patent.
I am becoming gerund, destroyer of verbs.
I did system level encryption in 1978 on the mainframe VM/CMS system. Under the CMS component, which ran in a virtual machine, all I/O was done through an interface known as SVC 202 . This interface was used for modular execution of both external (a file) and internal functions. I wrote a program in assembly language which first ran in what was known as the "transient area". This program then allocated memory on a permanent basis, and copied part of itself there. That part was written in relocateable assembly code (was not hard to do in S/370 assembler). It then substituted the SVC interrupt vector with its own, and intercepted all SVC instruction traps. The intercept handler was now in control and the program did a graceful exit, but without deallocating the memory. This was similar to the DOS TSR (Terminate and Stay Resident) feature. The intercept handler checked for SVC traps being code 202. If not, it passed them on to the original SVC handler in CMS. If it was 202, then it checked for the request name for reading and writing. If that matched, it then checked to see if it was a file to be encrypted (writing) or decrypted (reading). CMS had disk letter/number combinations added to each file, and I allowed the program to be told to use either a letter (specific disk) or number (file mode) to be matched to indicate that the file was encrypted. It them modified the buffer appropriately before (writing) or after (reading) the system function completed. The net effect was the ability to have selected files, or a whole disk, encrypted. All native CMS programs, and some OS/VS/MVS emulated programs, would successfully do I/O through this encryption system. I was able to edit a Fortran program, save it, and compile it with the Fortran G compiler, and subsequently run it. I placed a call to my encryption facility in a script called "PROFILE EXEC A1" which made it run every time I logged in. It prompted me for the key, which was a string that was hashed to construct the encryption vector for the algorithm I used (which is probably terribly insecure today).
I was a student at Ohio University at the time. A group of us were "hackers" (and at times did a little cracking, too). All the disk space was partition-like slices on big (in the physical sense, about the size of a small washing machine) hard drives shared with a lot of other people. The computer center administrators could easily spy on any user's disk space. So this was used as a means to keep nosey people out. About 3 months after I started regularly using this, I was summoned to the office of the Director of Academic Affairs at the computer center. I was told by Dr. Craig Farrar that he was aware that I was encrypting my files, and that this was against computer center and university policy. He gave me a copy of the policy. He was at least an honest man, and also told me it was a brand new policy adopted specifically because I was encrypting my files. He then told me I had 2 days to unencrypt all files before the disk space would be entirely erased. I simply backed up most of them to a private tape, removed it, and unencrypted a few remaining files and deleted the rest. I never used the program again.
When the PC came out with DOS, and I learned of TSR, I thought about that program, and thought I'd like to do the same thing again. I didn't at that time because I didn't make the committment to learn x86 assembly, and didn't have a suitable C compiler at the time. So a DOS version, unfortunately, never actually happened. However, I did see among some shareware on a BBS, around 1989, a description of a program that did exactly that. Unfortunately for that program, at that time I was doing the Amiga thing. Hopefully someone can track down that program.
When I moved to Texas in 1993, I left all my old mainframe tapes (about 120 of them by then) behind. I had gotten hooked on Linux and swore to never use a mainframe again, so I had them discarded. Now I wish I had them back, because I could now run them on Linux using emulators ... after I figured out how to get stuff off those old tapes.
now we need to go OSS in diesel cars
Also check out this article on patent strategies of japanese companies. I do not claim to be a scholar here and freely concede that mmy posts are not scholarly works. That said, they do derive from the cumulative impact of articles I have read in a variety of sources over the years. I invite you to do some more research yourself to dispute my view - indeed, a quick google search reveals plenty of B-school theses fawning over the Japanese tendency towards cross-licensing to the extent that it permits more than one company to extract monopoly rents from a market, though I would dispute (again, admittedly without my own body of scholarly work) the assumption that this is a good thing from a macroeconomic perspective. If anything, I think this would reinforce my point, but since nobody (that I've found) has directly studied the impact of cross-licensing on companies excluded from the "club," as it were, I cannot provide you with an online reference directly supporting my proposition wrt stifling of innovation.
-Isaac
I am not a lawyer, and this is not legal advice. For Entertainment Purposes Only.