Re: The patent process [Was Re: Sharing the Family PC is Patent-Pending]

[Alun]

Stefaan A Eeckels <tengo@DELETEMEecc.lu> wrote in 
20040511185341.6bfef2e6.tengo@DELETEMEecc.lu:">news:20040511185341.6bfef2e6.tengo@DELETEMEecc.lu:

> On 11 May 2004 15:26:09 GMT
> Alun <elektros@yahoo.com> wrote:
> 
>> Stefaan A Eeckels <tengo@DELETEMEecc.lu> wrote in 
>> 20040511094627.3cc3ae13.tengo@DELETEMEecc.lu:">news:20040511094627.3cc3ae13.tengo@DELETEMEecc.lu: 
>> 
>> > The problems with software patents are:
>> > 
>> > 1. There is no need to construct a prototype and
>> >    perfect the device - most software patents concern
>> >    rather trivial ideas, that take little time to code
>> >    and don't require code, as the language of the
>> >    patent is about as far from a computer language as
>> >    possible. This reduces the value of the "disclosure" to zero.
>> 
>> I would have no problem with the idea of requiring source code, but the
>> law would have to be changed. Present legal standards don't require it. 
> 
> And they should. The current terminology evolved from
> the original target of patents, mechanical devices. 
> 

UK patent No 1, issued in 1617, was for a method of map making. Hundreds of 
years later the first US patent was a chemical patent.

>> > 2. The patent examiners aren't software professionals, and the patent
>> > verbiage makes it very difficult 
>> >    for software professionals to understand the purported
>> >    invention. As a result, almost anything can be  patented.
>> 
>> I don't think the conclusions follow from the premises in that. I think 
>> most of us who are patent professionals agree that the reason that bad 
>> software patents issue is that the examiners mostly look at existing 
>> patents for prior art. Since software wasn't always patentable, it is a 
>> given that most really basic ideas won't be found in their search, and
>> so they are then compelled to allow the patent. 
> 
> Well, if they were software professionals, they'd know that
> the field didn't materialise out of thin air when the patent
> legislation was broadened to include software. 

It wasn't so much legislation as a succession of court decisions that 
gradually broadened the scope of software patents. I think they do know 
that the field didn't materialise from thin air. The trouble is that the 
standard modus operandi of the USPTO is to look at US patents for prior 
art, and increasingly to use only keywords to do it. 

Ironically, keywords work extremely badly for computer art, as the 
terminology has undergone many changes. For example, they may know that a 
control in Window$ is a widget in Unix, but do they know that the same 
thing used to be called a wimp? (or, more accurately it is a subset of what 
was called a wimp). Similar changes occurred throughout computer art, and 
the only way to be sure of finding earlier incarnations of the same idea in 
the patent art is to search the old fashioned way, by classification, a 
skill that is fast dissappearing amongst examiners. 

They should also be looking in non-patent art for every software invention, 
as that is the only way that you can find previously unpatentable art. 
There is even a free database that was created specifically for that 
purpose. Go to <www.spi.org> to take a look at it. Unfortunately, I 
seriously doubt that there are very many software patent examiners that do 
this. I don't personally think it's because they don't know. I think it's 
because they don't want to take the time to do it. (The reasons for which 
being an entire discussion in itself).

> In any case,
> the description of a software patent is so far removed from
> the reality of devising and writing software that it's 
> useless 
> a) for determining prior art
> b) for disclosure (i.e. enabling the use of the so-called
>    invention by others).
>    
>> > 3. We're no longer dealing with individual inventors or
>> >    small companies with limited resources, but with huge
>> >    corporations that can afford frivolous litigation as a means of
>> >    crushing emerging competition. 
>> 
>> Right. One of the things that ought to be done to combat that is to
>> remove the presumption of validity of issued patents, and the FTC have
>> recommended that. 
> 
> Excellent move. Let's hope it gets accepted.
> 
>> > 4. As said above, the value of the disclosure is not 
>> >    related to the advantages granted by the patent. Software
>> >    patents should require the submission of working code, i.e.
>> >    a complete, working system clearly demonstrating the 
>> >    invention. The archaic and ridiculous language in which
>> >    patents are cast should be abolished, as it offers too
>> >    much power to patent attorneys, and makes it impossible
>> >    for skilled programmers to understand the claims.
>> >
>> 
>> I don't see how a plain language requirement would work. Patents are 
>> written from scratch, and those of us who write them use certain terms
>> and certain ways of writing things for legal precision, not to confuse
>> others, beleive it or not. 
> 
> But the languages that can be used to describe a software
> invention is source code, and, for example, modelling 
> conventions such as UML. They are -when it comes to software-
> far more precise than the crufty patentese (which evolved
> from describing mechanical devices, and got burdened by
> generations and generations of lawyers intent on hitting
> each other on the head rather than describing an invention).
> It might be precise for _you_, but it is gobbledygook for
> even the most clue-up CS major. We can no longer write code
> without having to ask a patent professional (who doesn't
> read source code, usually) if what we're writing might be
> patented. And even then, these people (who're lawyers) tend
> to answer in "maybe"s, "possible"s, and "we should test it
> in court"s. 
>

To be exact, writing a patent application involves being vague by exactly 
the right amount. Patents differ from copyright, for example, in that they 
can protect rather more than just one example of source code. If done 
right, they should protect the inventor against a competitor who has the 
same idea and implements it with different code.

Given that a patent can protect something broader than specific code, this 
means that the claims won't be limited to that code (which would 
unnecessarily reduce the scope) and therefore the written description and 
best mode requirements can be met by something that does correspond to what 
is claimed, which will tend to be a flowchart, reflecting an algorithmn, 
not the actual code. 

There may be some concerns that including the source code might limit the 
interpretation of the claims. It shouldn't if done right, but it is by no 
means necessary to include it. It's also a farly easy legal argument to say 
that a competetent programmer, given an algorithmn in the form of a flow 
chart, could code it in any language with which they are familiar.

Given all the above, the only way to ensure that source code is put in is 
to actually make it mandatory.
 
>> > The patent system should not merely have been extended to
>> > software, but revamped to take into account the specifics
>> > of software. A naive idea, obviously, as it doesn't suit the
>> > interests of those who leech off the system (government, patent
>> > professionals, litigation departments of large corporates).
>> > 
>> 
>> It would suit me just fine to have special rules for software, but we 
>> don't, so I have to work with what we have. 
> 
> I accept that - but where the drawings of the old patents
> made some sense to the mechanical engineers of yonder,
> they hinder understanding of the software patents by software
> engineers. As a result, they are counterproductive when it
> comes to promoting the discovery of inventions in software, and
> benefit solely the administrators of the system (who, as I 
> indicated by using the derogatory term "leeches" (NOM), live off
> the system without being productive). It should not be up
> to programmers to study patentese, but up to patent professionals
> to acquire the required working knowledge of the field they
> purport to "serve".
> 
> Take care,
> 

To become a patent attorney or patent agent you must pass the patent bar, 
for which you must be able to show technical prerequisites. Many of those 
who work in software art do have CS degrees. I don't, but I am an EE, and 
have some very rudimentary ability to code in a couple of languages. I 
don't think there is really a lack of working knowledge of the technology. 
It's just that we have to draft something that works as a legal document, 
and doesn't inadvertently limit itself by being too specific.

Alun Palmer, US Patent Agent, Reg. No. 47,838