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

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