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

From: IETF Secretariat <[email-masked]>
Date: Tue, 8 Sep 2009 14:03:55 -0700 (PDT)

Dear Vincent Roca, Christoph Neumann, David Furodet:

An IPR disclosure that pertains to your RFC entitled "Low Density Parity Check
(LDPC) Staircase and Triangle Forward Error Correction (FEC) Schemes" (RFC5170)
was submitted to the IETF Secretariat on 2009-09-08 and has been posted on the
"IETF Page of Intellectual Property Rights Disclosures"
(https://datatracker.ietf.org/ipr/1184/). The title of the IPR disclosure is
"QUALCOMM Incorporated's Statement about IPR related to RFC 5170."

The IETF Secretariat

---

From: Vincent Roca <[email-masked]>
Date: Mon, 21 Sep 2009 15:12:29 +0200

Mike,

I have a comment W.R.T. your IPR disclosure against RFC 5170:
	https://datatracker.ietf.org/ipr/1184/

The IPR disclosure #1184 updates the disclosures #637 and #908,
issued respectively in October 2005 and December 2007.
	https://datatracker.ietf.org/ipr/637/
	https://datatracker.ietf.org/ipr/908/
However the new disclosure mentions 13 patents, whereas the previous
ones mention 3 patents. Hence my remarks:

You know that IETF participants MUST disclose any IPR they are aware of
"as soon as reasonably possible" (RFC3979/section 6.2.2). You and Mark
said in a separate email exchange in April that "[DF] have followed and
are following RFC3979".

So why did you wait almost 4 years to disclose your additional 10
patents? Where is the truth?

Or, said differently: you recognized during 4 years that the additional
10 patents of disclosure #1184 were not applicable to RFC 5170, since
they were not mentioned at all. So what happened? I'd like to understand.

Regards,

    Vincent

IETF Secretariat wrote:
> _______________________________________________
> Rmt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rmt

---

From: "Luby, Michael" <[email-masked]>
Date: Tue, 22 Sep 2009 15:18:16 -0700

Vincent,
The December 2007 update to the DF IPR declaration on then  changed the IPR declaration from "No" to "Yes" in answer to the question "Are there any unpublished patent applications".  The reason we did this at the time is because we realized that an additional element had been added to the ldpc draft at the time that was relevant to one of our unpublished patent applications at the time, which eventually became U.S. Patent No. 7,418,651 that issued Aug. 26 2008, and also Publication number 20090031199 (these two have the same common patent specification).  During the course of the process of acquisition by Qualcomm, we realized that this same element was also relevant to one of our earlier patent specifications, which is why we added the list of the remaining 8 new items listed (they all have the same common patent specification, just different claim sets).

One other change worthy of mention in the newest IPR declaration is that we have change the terms from "Licensing terms are available upon request" to "Reasonable and Non-Discriminatory License to All Implementers with Possible Royalty/Fee".

We have been adhering to the IETF policy, and we will continue to adhere to it.
Best, Mike

On 9/21/09 6:12 AM, "Vincent Roca" <[email-masked]> wrote:

Mike,

Regards,

    Vincent

---

From: "Luby, Michael" <[email-masked]>
Date: Tue, 22 Sep 2009 15:22:53 -0700

Vincent,
Sorry, that was a bit garbled.  Let me try again... (corrected below).  BTW, the email for David Furodet bounces, which is why I removed him from the list of recipients.
Best, Mike

On 9/22/09 3:18 PM, "Luby, Michael" <[email-masked]> wrote:

Vincent,
The December 2007 update to the DF IPR declaration on the then current ldpc draft  changed the IPR declaration from "No" to "Yes" in answer to the question "Are there any unpublished patent applications".  The reason we did this at the time is because we realized that an additional element had been added to the ldpc draft at the time that was relevant to one of our unpublished patent applications at the time, which eventually became U.S. Patent No. 7,418,651 that issued Aug. 26 2008, and also Publication number 20090031199 (these two have the same common patent specification).  During the course of the process of acquisition by Qualcomm, we realized that this same element was also relevant to one of our earlier patent specifications, which is why we added the list of the remaining 8 new items listed (they all have the same common patent specification, just different claim sets).

Mike,

Regards,

    Vincent

---

From: Vincent Roca <[email-masked]>
Date: Thu, 24 Sep 2009 17:22:44 +0200

Mike,

Thanks a lot for your clarification.

Since patents #7,418,651, #20090031199 and the additional 8 patents all
refer to "an additional element added to the ldpc draft" that was not
present in draft-ietf-rmt-bb-fec-ldpc-00.txt (i.e. the one available
when you filled IPR disclosure #637), then it makes sense that none of
these 10 patents were listed in the disclosure #637. I agree.
---
BTW, I was not aware that checking the "unpublished patent applications"
box exempts the Discloser from listing the unpublished pending patent
numbers, hence my error (probably something to clarify in RFC3979
successor).
---
So I apologize for having suggested that you and DF were not following
the IETF policy.

Now we have clarified this important aspect, let me continue.

As you know, we have always been very respectful of IPRs. In particular
we always did our best to avoid infringing any patent we were aware of.
So I want to understand your point of view and where the problem is
according to you.

Since, the 10 additional patents not in IPR disclosure #637 all refer
to "an additional element added to the ldpc draft", as you said, I have
listed these differences (see the list at the end of my answer, below).

Honestly speaking, when I look at the 11 claims of patent #7,418,651,
I do not see any obvious overlap.

This patent, if I understand correctly, describes Multi Stage Chain
Reaction (MSCR) codes. These codes first generate a "static" set of
redundant symbols (where "static" means their number is predefined
during code construction). Typically the "intermediate symbols" of
Raptor. Then these codes generate a "much larger" number of Output
symbols from the input and redundant symbols (note the use of "much
larger" here, typical of small-rate/rateless codes). Typically the
LT encoder of Raptor codes.
Claim 1 summarizes this two step process typical of MSCR codes,
and the remaining claims just provide some simple refinements to
Claim 1 (they all depend on Claim 1).

So what is "[the] additional element added to the ldpc draft" in
my diff list (below) that conflicts with one (or more) of the claims?
I'd like to understand your point of view. Did I misunderstood
something? Can you clarify?

Thanks in advance.
Cheers,

   Vincent

draft-ietf-rmt-bb-fec-ldpc-00 to -07 differences
---------------------------------------------------------------------

1- section 4.2.4.2, FEC-OTI-Scheme-Specific-Info specification
  It simply says the OTI it contains the PRNG seed and G value, with
  Base64 encoding.

2- section 5.1, a small paragraph to say that "sending parity symbols
  in sequence is suboptimal and that instead it is usually recommended
  the shuffle these symbols."

3- section 5.3, where we detail a way of determining the encoding
  symbol size (E) and number (G) of encoding symbols per group (i.e.
  packet) in order to artificially increase the number of symbols
  when dealing with small source objects.
  Version -00 also offers the possibility of having several symbols
  per group but does not clarify how to choose the G value.

4- section 5.4 and 5.5 that are in fact a split of the previous
  section 5.4. It's essentially editorial work.

4- section 5.6, better explains how to identify the G symbols,
  but it's essentially editorial work.

5- section 5.7 better explains the PRNG aspects, but there's nothing
  particularly new here, the algorithm is well known.

6- section 6.4, concerning decoding, is similar to that of version -00,
  except that we now explicitly say a receiver can start with the
  trivial decoding algorithm and finish, if need be, with a Gaussian
  elimination.
  The new version also mentions that choosing a decoding algorithm
  will impact both erasure capabilities and processing overhead.
  I don't see any problem here, it's obvious.

7- the security/IANA sections have been added to -07 too.

8- Appendix A provides an example implementation of the PRNG used.

9- Appendix B sketches the Trivial Decoding Algorithm used with
  more details than what was done in the -00 version.
---------------------------------------------------------------------

NB: I removed from the list editorial differences that I think are
not likely to raise any problem . If ever I erroneously removed
something, do not hesitate to correct me.

In any case, the full differences are available at:
http://planete.inrialpes.fr/~roca/doc/draft-ietf-rmt-bb-fec-ldpc-07-from-00_diff.html

Luby, Michael wrote:
> ------------------------------------------------------------------------
>