octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: development snapshot


From: Jaroslav Hajek
Subject: Re: development snapshot
Date: Tue, 8 Sep 2009 09:56:41 +0200

On Mon, Sep 7, 2009 at 8:58 PM, Judd Storrs<address@hidden> wrote:
> One thing that I don't think has been satisfactorily resolved in our
> discussions is whether statements that certain things are "impossible" in
> the supporting text affect the scope of the claims? Maybe SFLC can help
> clairify that.
>
> If octave's implementation fundamentally relies on "doing the impossible" as
> described in the supporting text can it possibly infringe?
>
> --judd
>
>
> For me the problem is that if you restrict your reading to the claims alone
> it is unclear what "at the first point" means and you could possibly read it
> as meaning
>
> (1) At any time between handle creation and handle evaluation, or
> (2) Specifically at the time/scope that the handle is created
>
> If you then read the supporting text it seems that (2) is what was meant. I
> don't really understand what influence the supporting text has over the
> claims (if any). It seem reasonable to me that the supporting text is meant
> to clarify the claims, but IANAL.
>
> According to the supporting text it is "impossible" to correctly resolve the
> handle unless the data structure is created at the same time and/or in the
> same scope that the handle was created. To me this indicates that reading
> (2) of the claims is correct.
>
> Under reading (1) you get the massively expansive claims that could cover
> closures, possibly most of symbolic computation, among other things (all of
> which have prior art). I just don't think the USPTO could possibly have
> granted the patent under such a broad reading of the claims.
>

I also think that (2) was meant; however, I don't think it really
matters that much. The source of the incredible broadness of the
patent is that for "information leading to a set of functions visible
at the first point", storing name and scope is sufficient. Any
implementation must store the name, and any implementation must either
store the scope or extract any local-scope function in advance and
store that (which is what Octave does now).
Both of these are plain logical consequences of the mere idea of
having an overloaded function handle that can export local-scope
functions. It's just one of those patents that are obvious. The same
thing was achievable with anonymous functions before, like @(x)
myfunc(x).

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]