decoration decoration
Stories

GROKLAW
When you want to know more...
decoration
For layout only
Home
Archives
Site Map
Search
About Groklaw
Awards
Legal Research
Timelines
ApplevSamsung
ApplevSamsung p.2
ArchiveExplorer
Autozone
Bilski
Cases
Cast: Lawyers
Comes v. MS
Contracts/Documents
Courts
DRM
Gordon v MS
GPL
Grokdoc
HTML How To
IPI v RH
IV v. Google
Legal Docs
Lodsys
MS Litigations
MSvB&N
News Picks
Novell v. MS
Novell-MS Deal
ODF/OOXML
OOXML Appeals
OraclevGoogle
Patents
ProjectMonterey
Psystar
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v IBM
SCO v Novell
SCO:Soup2Nuts
SCOsource
Sean Daly
Software Patents
Switch to Linux
Transcripts
Unix Books

Gear

Groklaw Gear

Click here to send an email to the editor of this weblog.


You won't find me on Facebook


Donate

Donate Paypal


No Legal Advice

The information on Groklaw is not intended to constitute legal advice. While Mark is a lawyer and he has asked other lawyers and law students to contribute articles, all of these articles are offered to help educate, not to provide specific legal advice. They are not your lawyers.

Here's Groklaw's comments policy.


What's New

STORIES
No new stories

COMMENTS last 48 hrs
No new comments


Sponsors

Hosting:
hosted by ibiblio

On servers donated to ibiblio by AMD.

Webmaster
A Proposed Response to the USPTO's Topic 1 Question on Functional Language ~pj | 202 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
A Proposed Response to the USPTO's Topic 1 Question on Functional Language ~pj
Authored by: Anonymous on Saturday, February 02 2013 @ 04:45 AM EST

Please explain how this twisting works in practice. I just don't see the point.

Many programmers are forbidden by their employers upon advice from counsel from reading patents for this very reason.

This is not an argument about the programmer being productive. This is an argument that the costs/benefits analysis doesn't work out for the programmer because even if he is more productive he is still not productive enough to overcome the costs side of the analysis. The liability aspect cannot be dismissed because it is part of the over all analysis.

This is an argument that the USPTO should do their homework and check whether patent law works in practice according to theory. This is not an argument that case law must be overturned, although the analysis may eventually lead to this conclusion.

Please remember, the issue this response raises is whether patent law actually promote innovation when it comes to software. It is not whether case law is correct. We are not arguing in front of a court. We are giving the USPTO feed-back on how things play out in real life as opposed to how they should play out in theory.

Using the word "twisting" might be a mistake from me. Let me try to restate the same thoughts with other words.

The thing I am after is that patent lawyers/judges start with the assumption "reading patents improve productivity unless proven otherwise". We can argue about how true this is in the real world, but they would not be patent lawyers if they did not have this belief.

Arguments about costs/benefits is tricky to state since the lawyer with an assumption about patents on software being a good thing will view the costs/benefits argument to mean "many companies prevent their employee from benefiting from reading patents because they know the increased productivity will be insignificant to the treble damage caused by the companies deliberate stealing of inventions from the patent holder." The cost/benefits argument is not conclusive to a lawyer unless you can make them realize the actual value in software patents is zero. The software programmer knows this, but our argument can not use this as an assumption because it is not shared by the one we are trying to convince.

The problem with lawyers reasoning is thus the assumption about there being value in patents themselves. That is why I think the treble damages argument is counter productive to our cause.

The true problem with software patents is that programming is math/language, but if we speak about about the practical reasons why patents without full disclosure is useless then the true answer is that the problem is not that there is no value in the formal language without disclosure of sourcecode, but that the computer science field have massive and better information that include both the formal language and enough disclosure. The difference between programming and other fields is that since programming is math and nothing else it is possible for the computer scientist to cover it all, where you with other fields always end in pesky details about some aspect not being abstract but a real thing that has aspects not covered by the math/model.

The argument about FLOSS is likewise inconclusive. It is true that FLOSS offer superior disclosure, but the lawyer will go with the fiction that software patents is needed because not every software is FLOSS or can be expected to be FLOSS. If the argument is changed more to that the field of computer science already contain every value there is in formal language specifications and disclosure of working programming code is the only way to actually add useful information to one skilled in the art then the arguments get much more useful.

I think an argument to make in final part is that skilled in the art when you consider computer programming mean that you know all the math needed so that formal language specification is trivial in each and every case. The only difficulty is if the domain expert insist on demands that are contradictive.

Being skilled in the art does not mean that you have the skills to implement every problem you can state with formal language, the field of computer programming is too wide for anyone to master all areas. This is why FLOSS that insist complete disclosure even of things that is directly applied from the computer science books is such a superior development model. A group of programmers from different backgrounds write better code together than any single company can ever succeed with.

Maybe it might be good to add an argument about disassembling of source code meaning there is no trade secrets in computer programming. This is cince if you can run the code you are by definition able to disassembling it to learn how it works. Patents in general is in theory a balance between being giving a monopoly and revealing your trade secret. If there is no trade secret there is nothing to balance the benefit. This especially hold true if you don't have to do code disclosure to prove that you really know how implement your formal language specification.

[ Reply to This | Parent | # ]

Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )