Subject: Re: Fwd: IPR Notification on RFC 2462 and 2464

From: Greg Daley <[email-masked]>
Date: Sun, 06 Nov 2005 20:10:05 -0800

Hi James, 

I understand the point you're making, and you're
correct, that situations like these often don't get
completely cleared up unless one of the parties
charges to court.

What we have here, though, is a patent to claim IPR, 
not necessarily an actual IPR.  While there may not
be anything stopping a patent holder from claiming
the IPR and associated royalties, it's in almost 
everyone's best interest to make it widely known that
there is an example of prior art which is well
described and well known to the community (the more
complete a description, the better).  

Regarding OSS and proprietary implementations,
I guess people have to look at the basis of the patent,
and the cost of either removing the code (is MUST in
node-requirements?) or paying royalties.

Greg

----- Original Message -----
From: James Kempf <[email-masked]>
Date: Friday, November 4, 2005 3:34 pm
Subject: Re: Fwd: IPR Notification on RFC 2462 and 2464
> Greg,
> 
> I'm glad you've been following up on this, but there is a key 
> point missing I think. US Patent Law is based on litigation,
> not regulation. The US Patent Office typically only conducts
> a cursory examination of prior art, and unless the patent
> application is contested before approval, the Patent Office
> rarely denies a patent unless its incorporation of prior art is 
> egregious. I don't know what the case is with other countries.
> 
> Disputes about the validity of patents in the US are routinely 
> handled through litigation. After the patent is granted, a patent
> holder typically claims infringement in a letter to parties it
> believes are using the IPR, attempts to extract royalties (or
> not if the intent is to force the parties out of the market
> completely to eliminate competition), then takes the case 
> to court if the parties refuse to pay. Thereafter comes the long 
> and expensive process of litigating the patent. Most patent
> litigation cases are decided for the patent holder these days,
> though there are occasional exceptions.
> 
> The upshot of this is that, as far as the law is concerned, it 
> doesn't really matter what the facts are with respect to prior
> art. If there is a patent on some basic technology in IPv6 and
> the IETF or some other organization thinks that the patent was
> invalidly granted, then until the IETF or some other party is
> willing to go to court to contest the patent, the patent holder
> is free to claim that IPR, ask for royalties, and take whoever
> has implemented it and is selling it without a license to 
> court.  The IETF could of course politely request one of the
> royalty-free IPR releases it routinely asks for in cases such
> as this, but I am told that some of the Open Source IPv6 stacks
> refuse to incorporate *any* IPRed software, even if such
> releases are granted. It will be interesting to see 
> what they do with this particular case, since the techology is 
> pretty deeply embedded into IPv6. In addition, the legal status
> of those IPR releases is somewhat questionable. Suppose, for
> example, a company holding IPR granted such a release and the
> technology was widely implemented such as in this case, then
> the company holding the IPR was taken over by another company 
> whose business model was charging for IPR. Suppose that company 
> then cancelled the the IPR release and started trying to extract 
> royalties. What would happen? Fortunately, I don't think we have
> to worry about such a scenerio in this case, because the company
> in question is pretty large and in no danger of being taken over.
> 
>                     jak
> 
> ----- Original Message ----- 
> From: "Greg Daley" <[email-masked]>
> To: "Margaret Wasserman" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Thursday, November 03, 2005 5:14 PM
> Subject: Re: Fwd: IPR Notification on RFC 2462 and 2464
> 
> 
> > Hi,
> >
> > Sorry to follow myself up, but I have further information
> > which may be relevant to establishment of prior art for
> > IPv6 Stateless Address Autoconf.
> >
> > The previous e-mails' description of existing published
> > documents may only describe 102(a) prior art, (As
> > described by PUBPAT's own information on prior art).
> >
> > As such, it is susceptible to a prior unpublished
> > invention date by the patent holders (documented
> > internally to the patent holder's Lab for example).
> >
> > There seems to be evidence though that
> > FTP software was shipping IPv6 code with SAA
> > more than 1 year before the patent was applied for
> > (August 1996 ship):
> >
> > www.connectathon.org/talks97/helen.pdf
> >
> > This would constitute 102(b) prior art if the
> > presentation's contents were true.
> >
> > In that case, there could not be applicability of this
> > patent to IPv6 Stateless Address Autoconfiguration,
> > so long as the product was available in the USA at the
> > time (as far as I can tell).
> >
> > Greg
> >
> > Greg Daley wrote:
> >> Hi Margaret,
> >>
> >> I'm not sure how this affects the IPR notification,
> >> but I've had a quick look at existing art available
> >> at the time of the patent application.
> >>
> >> There are existing specifications of IPv6 autonomous
> >> address configuration in published drafts which
> >> significantly predate the patent application (> 12 months).
> >>
> >> This I guess, it substantively the same as the current
> >> RFC2462bis, and RFC2462 (and RFC1971 - August 1996).
> >>
> >> The descriptions of Address configuration with DAD were
> >> also described in earlier published drafts:
> >>
> >> http://www.watersprings.org/pub/id/draft-ietf-addrconf-ipv6-
> auto-02.txt
> >>
> >> And a fairly complete description of how DAD works (with
> >> different message names) is contained in the earlier version:
> >>
> >> http://www.watersprings.org/pub/id/draft-ietf-addrconf-ipv6-
> auto-01.txt
> >>
> >> The latest of these two documents is dated June 5, 1995
> >> (although it may have been received in the repository later?).
> >>
> >> Since provisional patent applications have only been supported
> >> for IPR protection since June 8 1995, and the Patent application
> >> for patent number 6,101,499 is April 8, 1998 (and doesn't
> >> reference any provisional application anyway), my guess is that
> >> the existing draft publications provide a clear prior art for
> >> IPv6 autonomous addressing.
> >>
> >> Provisional applications description:
> >> http://www.uspto.gov/web/offices/pac/provapp.htm
> >>
> >> Actually, given the wealth of existing IPv6 autonomous address
> >> configuration techniques, it's amazing that there's no reference
> >> to them in the description of the patent, made at application 
time.
> >>
> >> Clearly, I'm not able to provide legal advice about this
> >> situation, but the above information may be able to help someone
> >> who is.
> >>
> >> Greg Daley.
> >>
> >>
> >> Margaret Wasserman wrote:
> >>
> >>>
> >>> FYI --
> >>>
> >>> The official disclosure will probably be posted by the 
> secretariat 
> >>> shortly, but in the meantime I thought that the IPv6 WG should 
> be aware 
> >>> of this incoming IPR notification.
> >>>
> >>> Margaret
> >>>
> >>>> Date: Mon, 24 Oct 2005 12:01:49 -0400
> >>>> From: Dan Ravicher <[email-masked]>
> >>>> X-Accept-Language: en-us, en
> >>>> To: Margaret Wasserman <[email-masked]>,
> >>>>         Mark Townsley <[email-masked]>,
> >>>>         Robert Hinden <[email-masked]>,
> >>>>         Brian Haberman <[email-masked]>
> >>>> Subject: Fwd: IPR Notification
> >>>> X-Spam: [F=0.0001020200; B=0.500(0); S=0.010(2005092001); 
> >>>> MH=0.500(2005102404); R=0.010(s3/n722); SC=none; spf=0.500]
> >>>>
> >>>> Dear Ms. Wasserman and Messrs. Townsley, Hinden and Haberman:
> >>>>
> >>>> The Public Patent Foundation ("PUBPAT") formally notified 
> IETF today of 
> >>>> the existence of intellectual property rights that may relate 
> to 
> >>>> technology described in IETF documents.  Specifically, U.S. 
> Patent No. 
> >>>> 6,101,499 ("the '499 patent") owned by Microsoft Corporation 
> may relate 
> >>>> to RFC 2462 - IPv6 Stateless Address Autoconfiguration and 
> RFC 2464 - 
> >>>> Transmission of IPv6 Packets over Ethernet Networks 
> (collectively 
> >>>> referred to as "IPv6").  A copy of the formal notification 
> appears 
> >>>> below.
> >>>>
> >>>> As stated in the notification, although others have disclosed 
> the '499 
> >>>> patent with respect to IPv4, its claims may also relate to 
> IPv6. For 
> >>>> example, claims 1 and 30 could relate to the technology 
> described in 
> >>>> RFC 2462.  However, other than identifying this potential 
> relationship, 
> >>>> PUBPAT takes no position regarding the validity or scope of 
> the '499 
> >>>> patent.
> >>>>
> >>>> If PUBPAT can provide any further information or be of any 
> other 
> >>>> assistance to IETF in its review of this matter, including 
> perhaps 
> >>>> raising this issue with the entire IPv6 Working Group, should 
> that be 
> >>>> desirable, please do not hesitate to contact me.
> >>>>
> >>>> Sincerely,
> >>>>
> >>>> Daniel B. Ravicher
> >>>> Executive Director
> >>>> Public Patent Foundation
> >>>> 1375 Broadway, Suite 600
> >>>> New York, NY 10018
> >>>> (212) 796-0571 direct
> >>>> (212) 796-0570 main
> >>>> (212) 591-6038 fax
> >>>> [email-masked]
> >>>> www.pubpat.org
> >>>>
> >>>>
> >>>>
> >>>> -------- Original Message --------
> >>>> Subject: IPR Notification
> >>>> Date: Mon, 24 Oct 2005 11:53:54 -0400
> >>>> From: Dan Ravicher <[email-masked]>
> >>>> To: [email-masked]
> >>>>
> >>>> Dear IETF:
> >>>>
> >>>> Pursuant to IETF RFC 3979 Section 6.1.3, the Public Patent 
> Foundation>>>> ("PUBPAT") hereby notifies IETF of the existence of 
> intellectual>>>> property rights that may relate to technology 
> described in IETF
> >>>> documents.  Specifically, U.S. Patent No. 6,101,499 ("the 
> '499 patent")
> >>>> owned by Microsoft Corporation may relate to RFC 2462 - IPv6 
> Stateless>>>> Address Autoconfiguration and RFC 2464 - 
> Transmission of IPv6 Packets
> >>>> over Ethernet Networks (collectively referred to as "IPv6").
> >>>>
> >>>> Although IETF was previously notified of the '499 patent with 
> respect 
> >>>> to
> >>>> IPv4 related documents (see
> >>>> http://www.ietf.org/ietf/IPR/MICROSOFT-499.txt and
> >>>> 
> https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=554), 
> >>>> the
> >>>> '499 patent's claims, including for example claims 1 and 30, 
> could>>>> possibly be read as also relating to IPv6.  However, 
> other than
> >>>> identifying this potential relationship, PUBPAT takes no 
position
> >>>> regarding the validity or scope of the '499 patent.
> >>>>
> >>>> If we can provide any further information or be of any other 
> assistance>>>> to IETF in its review of this matter, please do not 
> hesitate to contact 
> >>>> me.
> >>>>
> >>>> Sincerely,
> >>>>
> >>>> Daniel B. Ravicher
> >>>> Executive Director
> >>>> Public Patent Foundation
> >>>> 1375 Broadway, Suite 600
> >>>> New York, NY 10018
> >>>> (212) 796-0571 direct
> >>>> (212) 796-0570 main
> >>>> (212) 591-6038 fax
> >>>> [email-masked]
> >>>> www.pubpat.org
> >>>>
> >>>
> >>> ---------------------------------------------------------------
> -----
> >>> IETF IPv6 working group mailing list
> >>> [email-masked]
> >>> Administrative Requests: 
> https://www1.ietf.org/mailman/listinfo/ipv6>>> --------------------
> ------------------------------------------------
> >>
> >>
> >> ----------------------------------------------------------------
> ----
> >> IETF IPv6 working group mailing list
> >> [email-masked]
> >> Administrative Requests: 
> https://www1.ietf.org/mailman/listinfo/ipv6>> ---------------------
> -----------------------------------------------
> >>
> >
> > -----------------------------------------------------------------
> ---
> > IETF IPv6 working group mailing list
> > [email-masked]
> > Administrative Requests: 
https://www1.ietf.org/mailman/listinfo/ipv6
> > -----------------------------------------------------------------
> --- 
> 
> 
> 
> -------------------------------------------------------------------
> -
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> -------------------------------------------------------------------
> -
> 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Mark Smith <[email-masked]>
Date: Mon, 7 Nov 2005 18:52:19 +1030

Hi Greg,

On Sun, 06 Nov 2005 20:10:05 -0800

> complete a description, the better).  

It seems that the Appletalk Address Resolution Protocol method of
selecting a node address is very similar, and could possibly serve as
prior art for this patent.

Christian stated that this patent applies to picking addresses within a
narrow number space. The Appletalk number space is only 16 bits for the
network address and 8 bits for the node address, which I'd think is
smaller than zeroconf address space (169.254/16) I'm guessing this
patent suggests a solution for.

>From "Inside Appletalk", Copyright 1990, Page 2-8 (page 83 of the PDF if
you have it, it used to be available at http://developer.apple.com/macos/opentransport/docs/dev/Inside_AppleTalk.pdf),

"Dynamic protocol address assignment"

. . .

When a protocol stack asks AARP to pick a unique protocol address,
AARP first chooses a tentative protocol address for the node. It starts
either by choosing an address value from some nonvolatile memory or by
generating a random number. If a mapping for that address value already
exists in the corresponding AMT, then AARP knows that another node on
the network is using this protocol address. It then picks a new random
value for the protocol address until it identifies an address that is
not in that AMT.

Having picked a suitable tentative protocol address, AARP must then make
sure that this address is not being used by any other node on the data
link. It does so by using the data link to broadcast a number of AARP
Probe packets, which contain the tentative protocol address. When a
node' AARP receives a Probe packet corresponding to one of its
protocol stacks, it examines the protocol address of that stack. If the
Probe's tentative protocol address matches the receiving node's
protocol address, AARP sends back an AARP Response packet to the probing
node.

If the probing node receives an AARP Response packet, then the tentative
protocol address is already in use and the node must pick a new
tentative address and repeat the probing process. If the probing node
does not receive a Response packet after a specified amount of time,
then it retransmits the probe. If after a specified maximum number of
retries the node has still not received a response, then the node___s
AARP accepts the tentative address as the node' protocol address. AARP
returns this value to its client."

(I normally wouldn't cut-and-paste this much text, but you wanted it
widely known ... :-) )

Regards,
Mark.