Re: [Rmt] Posting of IPR Disclosure related to QUALCOMM Incorporated's Statement about IPR related to RFC 5170

Vincent Roca <vincent.roca@inrialpes.fr> Thu, 22 October 2009 06:56 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 BD22D28C137 for <rmt@core3.amsl.com>; Wed, 21 Oct 2009 23:56:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.835
X-Spam-Level:
X-Spam-Status: No, score=-3.835 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 yRos6ignDnmQ for <rmt@core3.amsl.com>; Wed, 21 Oct 2009 23:56:47 -0700 (PDT)
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by core3.amsl.com (Postfix) with ESMTP id 39CEE28C131 for <rmt@ietf.org>; Wed, 21 Oct 2009 23:56:47 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.44,603,1249250400"; d="scan'208";a="36788614"
Received: from vpnloria18.inrialpes.fr (HELO macbook-de-vincent-roca.local) ([194.199.16.146]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Oct 2009 08:56:54 +0200
Message-ID: <4AE00235.5000800@inrialpes.fr>
Date: Thu, 22 Oct 2009 08:56:53 +0200
From: Vincent Roca <vincent.roca@inrialpes.fr>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: "Luby, Michael" <luby@qualcomm.com>
References: <C6F09F94.77CF%luby@qualcomm.com>
In-Reply-To: <C6F09F94.77CF%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: Thu, 22 Oct 2009 06:56:48 -0000

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
>