Potential patent issues

[Nick Sabalausky]

"Don" <nospam at nospam.com> wrote in message 
news:ihcrve$1t5l$1 at digitalmars.com...
> spir wrote:
>> On 01/21/2011 03:51 PM, Don wrote:
>>> Don wrote:
>>>> BlazingWhitester wrote:
>>>>> I spotted some patents that can theaten current DMD implementation.
>>>>> Wanted to clarify things.
>>>>>
>>>>> http://www.freepatentsonline.com/6185728.pdf - this patent describes
>>>>> method pointers implementation (delegates)
>>>>
>>>> This was obviously a patent aimed at protecting Delphi from VB. It's
>>>> all about the RAD designer: visual connections between GUI elements
>>>> and events has a 1:1 correspondence with code; delegates are used to
>>>> achieve this.
>>>>
>>>> D delegates can store a data pointer to a nested function, or to an
>>>> object. This is rather more general (not an object-oriented feature),
>>>> and doesn't provide a 1:1 correspondence to visuals.
>>>> I presume they were only able to satisfy the requirements for novelty
>>>> and non-obviousness, because of the RAD usage. In fact, there doesn't
>>>> seem to be any suggestion that delegates would be used for anything 
>>>> else.
>>>> The more general idea of storing a data pointer and a function pointer
>>>> together is simple and obvious, and surely has prior art.
>>>
>>> D's delegate scheme is essentially the same as described by Richard
>>> Hickey, "C++ report" (Feb 1995).
>>>
>>> See also a discussion on comp.std.c++, Feb 1996, titled "Generic Object
>>> Callbacks". Ian Willmott states:
>>> "I suggest that a new data type needs to be added to the language. We
>>> could call it "pointer-to-bound-member-function".
>>> ...
>>> Conceptually, it is a two-element structure consisting of
>>> pointer into data space, identifying an object, and a pointer into
>>> code space, identifying a member function on that object. The static
>>> type of such a variable is the signature (return type and arguments)
>>> of the member functions it is compatible with, just as the type of a
>>> regular function pointer is the signature of the functions it can
>>> reference. The only operations defined for this type are assignment,
>>> equality, and callthrough. Static typechecking is done at the point
>>> where a value of this type is created, and where a call is made
>>> through it. "
>>>
>>> Borland's patent dates from Feb 6, 2001. They were SIX YEARS too late.
>>> <g>
>>
>> IIUC, the structure you describe is /exactly/ the same, both concretely 
>> and semantically as Oberon-2 "type-bound procedures" (read: virtual 
>> methods). Oberon-2 was created in 1991, IIRC. This makes 10 years ;-)
>> Unlike you, I don't consider D's delegate to follow the same scheme. 
>> Sure, it's a pair of pointers, one of which point to a routine (to use a 
>> neutral word). But in the case of D the second one does not point to to a 
>> type/object, but to the definition scope (environment). This is very 
>> different, isn't it?
>> Thus I would consider D to not even be concerned by the patent. If you 
>> use a 3-integer struct to store a color, do you have to pay royalties to 
>> the owner of a patent about a 3-integer struct used to store a position? 
>> Indeed, lawyers...
>
> Yeah. I think we can be certain that that patent has zero risk for D.
> On the positive side -- I think that the rise of public source 
> repositories (with complete histories) means that public disclosure has 
> become much more common (factor of 1000 or more) than the days when these 
> junk patents were issued.
>
> Imagine you're a patent examiner, who has to work out if a particular code 
> idea has been previously published. How can you be confident that it 
> doesn't already exist in the billions of lines of open source code on the 
> web? And how much would you charge someone who asked you to check them 
> all?
>

I've been under the impression that, as a rule, the USPTO doesn't check for 
prior art and deliberately leaves "invalid due to prior art" up to the 
courts.