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

["Luby, Michael" <[e-mail]>]

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" <[e-mail]> 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" <[e-mail]> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rmt
>>
>
> _______________________________________________
> Rmt mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rmt