Re: [Rmt] Posting of IPR Disclosure related to QUALCOMM Incorporated's Statement about IPR related to RFC 5170
Vincent Roca <vincent.roca@inrialpes.fr> Sun, 08 November 2009 16:30 UTC
Return-Path: <vincent.roca@inrialpes.fr>
X-Original-To: rmt@core3.amsl.com
Delivered-To: rmt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF6953A67C2 for <rmt@core3.amsl.com>; Sun, 8 Nov 2009 08:30:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level:
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5+o7gi-5PGam for <rmt@core3.amsl.com>; Sun, 8 Nov 2009 08:30:05 -0800 (PST)
Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by core3.amsl.com (Postfix) with ESMTP id EB4843A6948 for <rmt@ietf.org>; Sun, 8 Nov 2009 08:30:04 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.44,704,1249250400"; d="scan'208";a="39737375"
Received: from host-144-134.meeting.ietf.org ([133.93.144.134]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Nov 2009 17:30:27 +0100
Message-ID: <4AF6F220.7070705@inrialpes.fr>
Date: Sun, 08 Nov 2009 17:30:24 +0100
From: Vincent Roca <vincent.roca@inrialpes.fr>
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: "Luby, Michael" <luby@qualcomm.com>
References: <C71BE810.8A1B%luby@qualcomm.com>
In-Reply-To: <C71BE810.8A1B%luby@qualcomm.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: "rmt@ietf.org" <rmt@ietf.org>
Subject: Re: [Rmt] Posting of IPR Disclosure related to QUALCOMM Incorporated's Statement about IPR related to RFC 5170
X-BeenThere: rmt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Reliable Multicast Transport <rmt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rmt>, <mailto:rmt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rmt>
List-Post: <mailto:rmt@ietf.org>
List-Help: <mailto:rmt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rmt>, <mailto:rmt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Nov 2009 16:30:06 -0000
Excellent. Let's talk and clarify a few points, this is what I'm asking since the begining. I just don't want to be obliged to interpret (erroneously?) vague sentences or even lack of answers from your side. Regards, Vincent Luby, Michael wrote: > Let’s talk in person Vincent, this email exchange is not productive > and there seems to be a complete misunderstanding about how patents work. > > > On 11/8/09 2:54 AM, "Vincent Roca" <vincent.roca@inrialpes.fr> wrote: > > Okay Mike. The various dates show that RFC 3453 is clearly > anterior (several > years) to the filling dates of both U.S. Patent Application > 20080034273 and > U.S. Patent 7,418,651. Since you did not bring any new elements to the > discussion > and did not question anything, we can conclude it's indeed prior art > (even if you > did not write it explicitly). > > Given that: > 1- the one and only motivation for the "10 additional patents" of IPR > disclosure > #1184 (WRT IPR disclosure #637) is the "multiple symbols per packet in > orderl > to improve the decoding efficiency of certain FEC codes with small > objects" > technique > (http://www.ietf.org/mail-archive/web/rmt/current/msg01358.html), > 2- there is prior art (i.e. RFC 3453) for this technique, > do you/QC intend to update IPR disclosure #1184 and remove the "10 > additional > patents"? > > Regards, > > Vincent > > > Luby, Michael wrote: > > Vincent, > > I gave you a way to determine yourself a definitive answer (see > > below). Apparently, you just don’t understand it. Sorry about that! > > Mike > > > > ----previous post--------- > > Vincent, > > With regards to the question about whether or not RFC 3453 is prior > > art, you can > > check (or have checked) the filing dates of the parent applications > > which includes > > the specifications upon which the claims are based. All of this > > information is > > publicly available. > > Regards, Mike > > -----end previous post------- > > > > > > On 11/6/09 12:50 AM, "Vincent Roca" <vincent.roca@inrialpes.fr> > wrote: > > > > Mike, > > > > Apparently I won't get any answer to confirm or invalidate the > > possibility of Prior Art. It's a pity since it would have clarified > > the situation, perhaps definitively. > > Regards, > > > > Vincent > > > > > > Vincent Roca wrote: > > > Hello Mike, > > > > > > I'd like to have your opinion on the following point. > > > > > > Claims 27-28 of US patent application 20080034273 detail the > > > "multiple symbols per packet" technique as follows: > > > > > > " 27. The method of claim 25, wherein the number of ouptput > > > symbols carried in a packet is determined based on a desired > > > number of input symbols. > > > > > > 28. The method of claim 25, wherein the number of output > > > symbols carried in a packet is determined based on desired > > > reception overhead." > > > > > > Now if I have a look at RFC 3453 (or the previous I-Ds, > > > http://tools.ietf.org/html/draft-ietf-rmt-info-fec), it is said in > > > section 2.4, p.12: > > > > > > " There is a weak tradeoff between the number of source symbols > > and the > > > reception overhead for LT codes, and the larger the number of > source > > > symbols the smaller the reception overhead. Thus, for shorter > > > objects, it is sometimes advantageous to partition the object into > > > many short source symbols and include multiple encoding symbols in > > > each packet. In this case, a single encoding symbol ID is used to > > > identify the multiple encoding symbols contained in a single > packet." > > > > > > Of course, the "man in the art" immediately understands that the > > above > > > paragraph is not limited to LT codes but is applicable to any code > > > that performs better with large objects, in particular LDPC codes. > > > > > > And RFC 3453 was published in 2002, several years before the > filling > > > dates of 20080034273 and 7,418,651 (the latter containing IPR > related > > > to the claims 25-29 of patent 20080034273, as you explained). > > > > > > Did I miss something? I'd like to understand. > > > > > > Another detail that surprises me is the fact there is no > reference to > > > RFC 3453 in U.S. patent application 20080034273 (the same is > true for > > > patent 7,418,651) whereas this RFC discloses what is claimed in > > the patent. > > > It won't simplify the work of the USPTO examiner. > > > > > > Regards, > > > > > > Vincent > > > > > > > > > Luby, Michael wrote: > > >> Hi Vincent, > > >> Yes, you got it with respect to the technical reason for the new > > >> patent information in the updated IPR declaration on RFC 5170. > > >> > > >> With respect to 20080034273, it is not yet granted, it was > published > > >> in February of 2008. > > >> > > >> I’ll get back to you as soon as practical in a different thread > > >> concerning > > >> > http://www.ietf.org/mail-archive/web/fecframe/current/msg00516.html. > > >> Best, Mike > > >> > > >> On 10/6/09 3:18 AM, "Vincent Roca" <vincent.roca@inrialpes.fr> > > wrote: > > >> > > >> Mike, > > >> > > >> If I understand correctly, your point is related to the > possibility > > >> offered by RFC 5170 of having several encoding symbols per > packet in > > >> order to increase the number of symbols, which is useful to > improve > > >> LDPC erasure correction capabilities when dealing with small > > objects. > > >> This is what I understand when comparing claims 25-29 of U.S. > patent > > >> 20080034273 to our RFC. > > >> > > >> And from your 09/23/2009 email, this is the "additional element > > added > > >> to the ldpc draft" that justified the 10 additional patents of IPR > > >> disclosure #1184 (WRT IPR disclosure #637). > > >> > > >> So I recognize there is a problem here. Now that it has been > > >> clarified, > > >> we can search for a solution that would hopefully satisfy both > > of us. > > >> > > >> As I said, we always did our best to avoid infringing any > patent we > > >> were aware of... But of course, there's nothing we can do in > case of > > >> unpublished pending patents! > > >> > > >> Especially when an IPR disclosure referring to an unpublished > > pending > > >> patent is not quickly updated once the patent has been granted or > > >> rejected. In this case, patent 20080034273 has been granted in > > >> February > > >> 2008, but the IPR disclosure only updated in September 2009. > In the > > >> meantime I haven't received any complain from you there could > be an > > >> issue with the "several symbols per packet" technique. It does not > > >> help! > > >> > > >> This reminds me of the similar situation (unpublished pending > > patent) > > >> we are currently experiencing with our FECFRAME document... So > far I > > >> didn't receive any clarification after my email sent > mid-September: > > >> > http://www.ietf.org/mail-archive/web/fecframe/current/msg00516.html > > >> > > >> Cheers, > > >> > > >> > > >> Vincent > > >> > > >> > > >> > > >> > > >> > > >> Luby, Michael wrote: > > >> > Hi Vincent, > > >> > > > >> > Claims 25-29 of U.S. patent publication number 20080034273 is > > >> related to the IPR issue. Note that the patent specification for > > >> U.S. Patent 7,418,651 (and the patent specification for U.S. > > >> Provisional Patent Application No. 60/569,127 to which it claims > > >> priority and is incorporated by reference) also contains IPR > > >> related to claims 25-29 of U.S. patent publication number > > >> 20080034273. It was realizing that the IPR in the patent > > >> specification for U.S. Patent 7,418,651 (and the patent > > >> specification for U.S. Provisional Patent Application No. > > >> 60/569,127) is relevant, based on looking more carefully at the > > >> drafts as they evolved and not the specific material in any one > > >> particular draft, that triggered the new DF IPR declaration in > > >> December 2007. > > >> > > > >> > Best, Mike > > >> > > > >> > > >> > > ------------------------------------------------------------------------ > > >> > > >> _______________________________________________ > > >> Rmt mailing list > > >> Rmt@ietf.org > > >> https://www.ietf.org/mailman/listinfo/rmt > > >> > > > > > > _______________________________________________ > > > Rmt mailing list > > > Rmt@ietf.org > > > https://www.ietf.org/mailman/listinfo/rmt >
- [Rmt] Posting of IPR Disclosure related to QUALCO… IETF Secretariat
- Re: [Rmt] Posting of IPR Disclosure related to QU… Vincent Roca
- Re: [Rmt] Posting of IPR Disclosure related to QU… Luby, Michael
- Re: [Rmt] Posting of IPR Disclosure related to QU… Luby, Michael
- Re: [Rmt] Posting of IPR Disclosure related to QU… Vincent Roca
- Re: [Rmt] Posting of IPR Disclosure related to QU… Luby, Michael
- Re: [Rmt] Posting of IPR Disclosure related to QU… Vincent Roca
- Re: [Rmt] Posting of IPR Disclosure related to QU… Luby, Michael
- Re: [Rmt] Posting of IPR Disclosure related to QU… Vincent Roca
- Re: [Rmt] Posting of IPR Disclosure related to QU… Vincent Roca
- Re: [Rmt] Posting of IPR Disclosure related to QU… Luby, Michael
- Re: [Rmt] Posting of IPR Disclosure related to QU… Vincent Roca
- Re: [Rmt] Posting of IPR Disclosure related to QU… Luby, Michael
- Re: [Rmt] Posting of IPR Disclosure related to QU… Vincent Roca
- Re: [Rmt] Posting of IPR Disclosure related to QU… Vincent Roca