4 ms·

What would be more useful is to transform a patent to plain non-BS language. Its probably hard but it should help developers understand patents quickly(one poin

What would be more useful is to transform a patent to plain non-BS language. Its probably hard but it should help developers understand patents quickly(one point of patents is to release trade secrets to researchers). And yes I know the risk of treble damages from intentional infringement if the patent was read. Also, hopefully such a tool will prevent some folks from knee jerk reactions based on patent titles(who am I kidding :). I bet it would be very hard to make such a tool though

jarrett 12y ago
I'm not sure that patents can be represented in any simpler form. They're a sort of programming language of their own, in that they (in theory) encode precise legal claims. The patent system has a specified "language" for encoding that information. Because the information is inherently complex and nuanced, there may not be a way to encode it more simply than in the "programming language" patents currently use. To make an analogy, C is hard to read for newcomers. But has anyone designed a simpler, better language for describing direct, low-level manipulation of memory? Is it even possible to describe such operations in a simpler way than in C? That being said, any given patent isn't necessarily written well. Within the confines of the "patent programming language," one can write well or poorly. So I'm not claiming that individual patents can't be edited for clarity. Rather, I'm claiming that the fundamental way patents are written--which is admittedly intimidating--may not admit of much simplification. To revisit the above analogy, one can write bad C. One can even write deliberately obfuscated C.
- dvanduzer 12y ago
  Petar Maymounkov is doing some really interesting research in that direction: http://www.maymounkov.org/memex/abstract http://www.maymounkov.org/memex/abstract
- ntakasaki 12y ago
  It's unfortunate that the patent language is mired in obtuse legalese rather than understandability by actual programmers. For example, take a Shazam-like song id algorithm. Technical blog post explaining the technology: http://laplacian.wordpress.com/2009/01/10/how-shazam-works/ http://laplacian.wordpress.com/2009/01/10/how-shazam-works/ Patent covering such an algo(is it the same? I can't even tell!): http://www.google.com/patents/US6941275?dq=.+6,941,275 http://www.google.com/patents/US6941275?dq=.+6,941,275 From http://en.wikipedia.org/wiki/History_of_patent_law http://en.wikipedia.org/wiki/History_of_patent_law The word patent even means 'in the open'. When was the last time someone linked to a software patent to share knowledge or enlightenment?
  - icegreentea 12y ago
    That's because the patent you linked isn't for a detection algorithm, it's for Shazam's entire business model - namely, a way for a customer to on the fly transmit a segment of recorded music, have the music identified (the claims are agnostic to the method of detection), have the identified match fedback to the user, and also providing a method for the user to also purchase the identified track. I mean, this is actually a bad patent to pick on, because in the scheme of things, it's actually really clear. Just read the claims. If you want to look at what an algorithmic patent looks like, take a look at http://www.audiblemagic.com/pdf/US5918223.pdf http://www.audiblemagic.com/pdf/US5918223.pdf this is a Patent cited by the Shazam patent as an example of a music matching algorithm. The bulk of the patent is basically a mix of block diagrams, pseudo-code, and background into the art. It's certainly not phrased like normal papers, but it's hardly 'mired'. It gets trickier when you get to the claims (which is actually the only parts that are binding), but if you read and understood the preferred embodiment (which I believe any reasonable literate and patient programmer can), it's nowhere as bad, as long as you understand that claims are nearly always structured from broadest to narrowest, with successive claims typically carving out specific 'implementations' of prior, broader claims.
  - deleted 12y ago
    [deleted]
zw123456 12y ago
I work for a company that pays a reward for patent submissions so I have done a fair number of them, and what has amazed me since I started doing them is that I prepare a submission that by most estimations if a readable, understandable explanation of the invention and I usually include some diagrams. The company evaluates it and they deem it patentable, they then pay special outside council, firms that specialize in such things, and they proceed to turn it into incomprehensible legaleeze babble. They also take my nice diagrams and turn them into those patent stick diagrams. It is too bad that my nice understandable synopsis could not be included. But that is the process, I think reversing the process seems almost impossible.
- Angostura 12y ago
  > It is too bad that my nice understandable synopsis could not be included. I suspect the issue here may be the same as the one that besets people who want to - for example - include a nice human readable version of a EULA alongside the legal version. It introduces the opportunity for conflicts between the two version. Which is the actual legally binding version? Your nice understandable synopsis should be used by the PR department for the press release that goes out explaining the newly awarded patent (if the PR department does such things).
- belorn 12y ago
  If you take a easy to read and understandable explanation to a patent office, the people who work there will more likely find prior art. The firms that specialize in patent applications are paid to increase the chance that a patent is granted, so its natural that clear and understandable language is the first to go.
- anigbrowl 12y ago
  incomprehensible legaleeze babble Is this like software engineers taking someone's simple algorithmic concept and turning it into 'incomprehensible computerese babble'?

jarrett 12y ago

I'm not sure that patents can be represented in any simpler form. They're a sort of programming language of their own, in that they (in theory) encode precise legal claims. The patent system has a specified "language" for encoding that information. Because the information is inherently complex and nuanced, there may not be a way to encode it more simply than in the "programming language" patents currently use. To make an analogy, C is hard to read for newcomers. But has anyone designed a simpler, better language for describing direct, low-level manipulation of memory? Is it even possible to describe such operations in a simpler way than in C? That being said, any given patent isn't necessarily written well. Within the confines of the "patent programming language," one can write well or poorly. So I'm not claiming that individual patents can't be edited for clarity. Rather, I'm claiming that the fundamental way patents are written--which is admittedly intimidating--may not admit of much simplification. To revisit the above analogy, one can write bad C. One can even write deliberately obfuscated C.

dvanduzer 12y ago
Petar Maymounkov is doing some really interesting research in that direction: http://www.maymounkov.org/memex/abstract http://www.maymounkov.org/memex/abstract
ntakasaki 12y ago
It's unfortunate that the patent language is mired in obtuse legalese rather than understandability by actual programmers. For example, take a Shazam-like song id algorithm. Technical blog post explaining the technology: http://laplacian.wordpress.com/2009/01/10/how-shazam-works/ http://laplacian.wordpress.com/2009/01/10/how-shazam-works/ Patent covering such an algo(is it the same? I can't even tell!): http://www.google.com/patents/US6941275?dq=.+6,941,275 http://www.google.com/patents/US6941275?dq=.+6,941,275 From http://en.wikipedia.org/wiki/History_of_patent_law http://en.wikipedia.org/wiki/History_of_patent_law The word patent even means 'in the open'. When was the last time someone linked to a software patent to share knowledge or enlightenment?
- icegreentea 12y ago
  That's because the patent you linked isn't for a detection algorithm, it's for Shazam's entire business model - namely, a way for a customer to on the fly transmit a segment of recorded music, have the music identified (the claims are agnostic to the method of detection), have the identified match fedback to the user, and also providing a method for the user to also purchase the identified track. I mean, this is actually a bad patent to pick on, because in the scheme of things, it's actually really clear. Just read the claims. If you want to look at what an algorithmic patent looks like, take a look at http://www.audiblemagic.com/pdf/US5918223.pdf http://www.audiblemagic.com/pdf/US5918223.pdf this is a Patent cited by the Shazam patent as an example of a music matching algorithm. The bulk of the patent is basically a mix of block diagrams, pseudo-code, and background into the art. It's certainly not phrased like normal papers, but it's hardly 'mired'. It gets trickier when you get to the claims (which is actually the only parts that are binding), but if you read and understood the preferred embodiment (which I believe any reasonable literate and patient programmer can), it's nowhere as bad, as long as you understand that claims are nearly always structured from broadest to narrowest, with successive claims typically carving out specific 'implementations' of prior, broader claims.
- deleted 12y ago
  [deleted]

zw123456 12y ago

I work for a company that pays a reward for patent submissions so I have done a fair number of them, and what has amazed me since I started doing them is that I prepare a submission that by most estimations if a readable, understandable explanation of the invention and I usually include some diagrams. The company evaluates it and they deem it patentable, they then pay special outside council, firms that specialize in such things, and they proceed to turn it into incomprehensible legaleeze babble. They also take my nice diagrams and turn them into those patent stick diagrams. It is too bad that my nice understandable synopsis could not be included. But that is the process, I think reversing the process seems almost impossible.

Angostura 12y ago
> It is too bad that my nice understandable synopsis could not be included. I suspect the issue here may be the same as the one that besets people who want to - for example - include a nice human readable version of a EULA alongside the legal version. It introduces the opportunity for conflicts between the two version. Which is the actual legally binding version? Your nice understandable synopsis should be used by the PR department for the press release that goes out explaining the newly awarded patent (if the PR department does such things).
belorn 12y ago
If you take a easy to read and understandable explanation to a patent office, the people who work there will more likely find prior art. The firms that specialize in patent applications are paid to increase the chance that a patent is granted, so its natural that clear and understandable language is the first to go.
anigbrowl 12y ago
incomprehensible legaleeze babble Is this like software engineers taking someone's simple algorithmic concept and turning it into 'incomprehensible computerese babble'?