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

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

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" <[e-mail]> 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" <[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
>