Re: overloaded function handles

[Robert T. Short]

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.

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

constructing, using a function name, a function data structure;

do we derive a data structure from a function name?

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?

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? 

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. 

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

Disclaimer:  I am not a member of any U.S. patent bar and so this discussion does not comprise legal advice.

Bob

Judd Storrs wrote:

Ok. Let me try again. I'm sorry for these long emails, but I feel like what I'm trying to say isn't being understood. The way I see it the reality is that octave can either infringe on Matlab's patent, not implement overloaded function handles or find some way to work around the claims. We all know about the patent so infringing at this point is willful infringement which triples damages.

I'm trying to work around the claims because I would like to be able to use overloaded function handles. I think I see a hole in the patent that relates to this statement in the Detailed Description:

"ii. Path and scope are not considered when applying a function handle. The work of initial function lookup is performed when the function handle is constructed. This does not need to be done each time the function handle is applied. Indeed it cannot be done when applying the handle, because scope at the point of application is not the same as the scope at the point the function handle was constructed."

What I am saying is that "it cannot be done when applying the handle" is false in practice for the specific case of overloaded functions in the Matlab language if the path does not change between creation and use of the handle.

I don't see how full compatibility can be achieved without infringing the patent, so I'm trying to propose a compromise. What I'm trying for is a loss of strange corners of compatibility in exchange for compatibility with what I suspect are the overwhelming number of cases. Of course, it would be possible to write code that behaves differently in Matlab and octave by exploiting the differences, but I'm unsure how likely it is that such code would be encountered in the wild?

My questions are whether the discrepancy in implementation (i.e. overloaded functions created in context2 instead of context1) makes any real world difference to actual useful code? And whether anyone else agrees that it avoids the claims of the patent.


--judd




Shifting path lookup to the first (and *only* the first use) instead of at the time of creation will not significantly impact performance. i.e. the following analogous codes:

# Creation -- in the style of Matlab
handle = create_new_handle() ;

handle = populate_function_list__danger_slow(handle, context1) ;

# Evaluation -- in the style of Matlab
apply_overloaded_handle(handle,context2,args) ;

IMHO this implementation infringes because it is exactly what is claimed--the function list is created at the same time in the same scope that the handle is created. What I am suggesting is that instead

# Creation -- not in the style of Matlab
handle = create_new_handle_with_empty_function_list() ;

# Evaluation -- not in the style of Matlab with cacheing
if handle_has_empty_function_list(handle)
    handle = populate_function_list_danger_slow(handle, context2) ;
end
apply_overloaded_handle(handle,context2,args) ;

Since the handle will have an empty list only the first time it is used, the slow cache creation only happens once in both cases. The "if" test at each use should be negligable compared to the path search esp. in a complied language like C++. I'm NOT suggesting that we do this:

# Creation -- not in the style of Matlab
handle = create_new_handle() ;

# Evaluation -- not in the style of Matlab but very slow
handle = populate_function_list_danger_slow(handle, context2) ;
apply_overloaded_handle(handle,context2,args) ;