Re: overloaded function handles

[Jaroslav Hajek]

On Thu, Jul 30, 2009 at 12:13 AM, Robert T.
Short<address@hidden> wrote:
> Well, I understand what you are trying to say.  In fact I thought it was
> quite clear.  And I agree that now that we have had this discussion it
> really is important (at least in the U.S.) to be careful that we have not
> infringed the patent.

>From what follows it seems to me that I have indeed infringed the
patent; moreover, I don't really see any reasonable implementation
that would avoid the infringement.

> Judd, the problem with your argument is that the CLAIMS don't include the
> quotes you have below.  The invention is defined by the claims, not the
> patent body.  The patent body provides scope and a dictionary, but does not
> define the invention.  If the claims refer to an technique or term that is
> not clearly defined by standard practice or is intended to be used
> differently from standard practice, the body is used to interpret the
> claim.  So, breaking claim 1 down:
>
> 1. A method comprising: at a first point in a program in a computer
> programming language having dynamic types and overloaded functions,
>
> octave is a computer language having dynamic types and overloaded functions
>

Yes.

> constructing, using a function name, a function data structure;
>
> do we derive a data structure from a function name?
>

Yes.

> the function data structure comprising information leading to a set of
> functions visible at the first point;
>
> Is the data structure comprised of information leading to a set of functions
> visible at the first point?
>

Yes. It is comprised of a function value (octave_value) of the
non-overloaded function visible at the first point, and possibly class
overloads. Note that "leading to" is very general; even if the
overload list was omitted, this would still hold; because (as we
agreed with Judd), the overload list can be constructed from the name
anytime, in any scope.

> at a second point, applying the function data structure to an argument list,
> the applying comprising selecting a function using the function data
> structure and calling the selected function.
>
> At the second point in the program, do we apply the function data structure
> to an argument list, that is do we call the selected function using an
> argument list?
>

Yes. Note that "using the data structure" is again very broad; indeed,
if the data structure only stored the name and the original
non-overloaded lookup result, infringement would apparently still
occur.

> The wording of this last claim element is awkward and may leave a hole.
> Furthermore, it seems that any object-oriented language would infringe this
> claim.
>
>
>
> If our implementation satisfies all of these conditions, we infringe claim
> 1.  We need to do the same for all claims.  If we infringe any claim, we
> infringe the patent (but if we don't satisfy ALL the conditions in a claim,
> we don't infringe the claim).  I haven't looked at the implementation, so
> can't fill this in, but I have done this for a number of patents over the
> years and will when I have time.
>

Yes, apparently we infringe claim 1. I expect there's a number of
secondary claims referring to this and adding something simpler, like
"program using technique from claim 1", isn't it?

> As for prior art, it, too, must satisfy all of the conditions of every
> infringed claim to be considered prior art.
>

I'm afraid I can't think of a prior art; then. Dynamic typing rules
out the C++ example I provided.

Sorry, but apparently the patent is broad enough to cover all
reasonable implementations; despite the fact that it is completely
obvious.

The only actually clever thing (lookup built-in classes in advance,
user classes on demand) that is vaguely hinted in Matlab's docs is not
included in the patent at all. Maybe it's intentional to include
incredibly broad claims and detailed rubbish in description, while
leaving out actually useful implementation hints.

I'm not sure what to do now. Maybe a compile-time flag disabling the
possibly infringing feature would help? (I doubt it, though).
I don't know the US laws. In CZ, for instance, usage of a patented
invention for non-business purposes does not constitute an
infringement. If a similar clause applies in the US, many users would
be safe just because of that.

Maybe it would be sufficient if Octave displayed a message at startup
that certain features may be subject to patent claims, and that users
should be aware of it. After all, I think nobody can actually
guarantee that Octave infringes no patents even now (for instance, as
I said, I think symbol_table::fcn_info is at least pretty close to
infringing the same patent).

If this is considered too much of a danger by US users, then I think
we should just fork a patent-free branch for the US, and omit this
feature and other possibly patented future features (such as JIT
acceleration).

regards

-- 
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz