Re: [codec] Skype IPR disclosure

Rob Glidden <rob.glidden@sbcglobal.net> Thu, 25 March 2010 00:50 UTC

Return-Path: <rob.glidden@sbcglobal.net>
X-Original-To: codec@core3.amsl.com
Delivered-To: codec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3866D3A67AF for <codec@core3.amsl.com>; Wed, 24 Mar 2010 17:50:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.924
X-Spam-Level: *
X-Spam-Status: No, score=1.924 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, GB_I_LETTER=-2, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_HTML_ONLY=1.457, UNPARSEABLE_RELAY=0.001]
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 dzkRyPSBue1c for <codec@core3.amsl.com>; Wed, 24 Mar 2010 17:50:00 -0700 (PDT)
Received: from smtp107.sbc.mail.gq1.yahoo.com (smtp107.sbc.mail.gq1.yahoo.com [67.195.14.110]) by core3.amsl.com (Postfix) with SMTP id A64A43A6B89 for <codec@ietf.org>; Wed, 24 Mar 2010 17:49:57 -0700 (PDT)
Received: (qmail 89478 invoked from network); 25 Mar 2010 00:50:16 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=sbcglobal.net; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=tHiXqIEkEPxkoTM+J+DWpok9ParCaHLq/RWaegvhVo3RayTKFQp95TGURmEL+jYoftvNReXDRQH6+99pqjSF5kPQ6uL0LNQZ1ZoWy/q+AlXKWLFDlAv7kKt8PgpKlNDFHRqiC3q0giz+9MgkAnFBvw4ES0iiAakeRG0gIqFduUs= ;
Received: from adsl-69-104-3-62.dsl.pltn13.pacbell.net (rob.glidden@69.104.3.62 with plain) by smtp107.sbc.mail.gq1.yahoo.com with SMTP; 24 Mar 2010 17:50:15 -0700 PDT
X-Yahoo-SMTP: xflwSnaswBCuS46GvTyhPI4RUJpgPG5UXouB5Vxqo4t9fsHeH0I-
X-YMail-OSG: wvyYmL0VM1l4YUXTufpU6.X8HF_sShV5sigtlvOoqnPgl85p2z.WzXWawyzZN3MnVnfEZWUA4WWq_e0LAbAe.M3Py1gPnp866r1J5lkmB9pOmBX10xtdJUGkSySH.49BaUz5DlGGFWnP.4flDvZ3uHtzEvp26nz5gty2mJEbr8aCsfc378848FXcdqD6VVa7C5MZddArRk0qf5DpzvG8WQYqbKqNbQhMxmmtvZb0pPHzLc3ODjgzB_VEfb6st4A5V.pZlA9Gbxt9kcpdnK38t6fYmQ5iVzyHiY_JryZyv4roE7W0.YEZidr0qM2g2h0mfGAXWEq_5Az2cyZz1_kNVA--
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4BAAB345.2070601@sbcglobal.net>
Date: Wed, 24 Mar 2010 17:50:13 -0700
From: Rob Glidden <rob.glidden@sbcglobal.net>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Stephan Wenger <stewe@stewe.org>
References: <C7CFE81B.206DE%stewe@stewe.org>
In-Reply-To: <C7CFE81B.206DE%stewe@stewe.org>
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: Codec WG <codec@ietf.org>
Subject: Re: [codec] Skype IPR disclosure
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Mar 2010 00:50:08 -0000

Stephan:

(apologies for long email)

Thanks for the reminder.  I've re-read 3979 and 4879 (on third party disclosures), and you are wise to encourage care.

However, in this case the IPR has already been responsibly disclosed by the owner.  So this thread is not disclosing any IPR of a third party, for which as you indicate sections 6.1.2 and 3 (on IPR of others) would be appropriate -- by form or email.

Rather, 3979 clearly expects working groups to use the disclosures, once made, in their evaluations and deliberations.

   6.5 Since IPR disclosures will be used by IETF working groups during
   their evaluation of alternative technical solutions, it is helpful if
   an IPR disclosure includes information about licensing of the IPR in
   case Implementing Technologies require a license.
This includes the licensing information in the disclosures:

   The inclusion of licensing information in IPR disclosures is not
   mandatory but it is encouraged so that the working groups will have
   as much information as they can during their deliberations.
And in weighing alternatives:

8. IETF working groups have the discretion
   to adopt technology with a commitment of fair and non-discriminatory
   terms, or even with no licensing commitment, if they feel that this
   technology is superior enough to alternatives with fewer IPR claims
   or free licensing to outweigh the potential cost of the licenses.
and even in developing broader IETF consensus:

An IETF consensus
   has developed that no mandatory-to-implement security technology can
   be specified in an IETF specification unless it has no known IPR
   claims against it or a royalty-free license is available to
   implementers of the specification unless there is a very good reason
   to do so.

And you are also wise in reminding that the IETF will not make determinations for many excellent reasons, but
Although the IETF can
   make no actual determination of validity, enforceability or
   applicability of any particular IPR claim, it is reasonable that a
   working group will take into account on their own opinions of the
   validity, enforceability or applicability of Intellectual Property
   Rights in their evaluation of alternative technologies.
So I'd suggest this dialog is both in scope and constructive, fully in spirit and letter of BCP 79, seeking to clarify the nature of a licensing disclosure and the specific value of a particular technique of noise level estimation and application of opposite non-linear functions.

Rob

Stephan Wenger wrote:
Re: [codec] Skype IPR disclosure Hi Rob, all,

Wearing my “technical advisor on IPR matters hat”:

Please let me remind you that the IETF takes no position on scope and validity of patent claims.  I don’t believe that the use of an IETF mailing list to collaboratively create such a position—even it it were not marked as an IETF position—is appropriate.  Please refrain from using this list for such discussions.   

Further, I’m also not sure that everyone here—even a majority—appreciates being advised of patents through means other than the IETF’s IPR tracking system.  It is certainly against language and spirit of BCP 79.  If you want to advise people of third party IPR henceforth, please use the tracker.  Feel free to contact me in private it you need logistic help with that.

Thanks,
Stephan



On 3.24.2010 15:13 , "Rob Glidden" <rob.glidden@sbcglobal.net" rel="nofollow">rob.glidden@sbcglobal.net> wrote:

I would agree that the wording seems to go beyond a narrow non-assert into business strategy, and this is furthered by potentially ambiguous phrasings such as "royalty free, reasonable and non discriminatory terms".  "RF" and "RAND" might overlap in some definitions, but they are not the same.

Also I would note the two statements (1297 and 1164) appear to be (only?) a single patent application for a method of estimating noise levels with 3 independent claims.  As further progress is made, it might be helpful to understand scope and prior art, and relationship to an entire contribution, and the specific quantified value of the novelty identified in the international search opinion of applying opposite non-linear functions.

Though not reflected in the disclosure, the US application claims priority to a Great Britain Application No. 0703275.8, filed Feb. 20, 2007.

http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=1&f=G&l=50&co1=AND&d=PG01&s1=12%2F006057&OS=12/006057&RS=12/006057" rel="nofollow">http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=1&f=G&l=50&co1=AND&d=PG01&s1=12%2F006057&OS=12/006057&RS=12/006057

The PCT is at:

http://www.wipo.int/pctdb/en/wo.jsp?WO=2008102207" rel="nofollow">http://www.wipo.int/pctdb/en/wo.jsp?WO=2008102207

Perhaps someone familiar with this application would correct any mis-impressions above?

Rob


Benjamin M. Schwartz wrote:

stephen botzko wrote:
  
 

I think it is unreasonable to require IPR holders to unconditionally promise
to not assert their patents under any and all circumstances.
    
 


I am not asking for such an unconditional promise.  I am just noting some
restrictions that seem especially onerous to me.

  
 

In practice the first clause does not immunize Skype from lawsuits.  Many
companies have similar "defensive suspension" clauses, and they still get
sued fairly regularly.  
    
 


There are different kinds of defensive suspension.  For example, the W3C
allows defensive suspension, but only for lawsuits on patent infringement:
"""
a W3C Royalty-Free license ... may be suspended with respect to any
licensee when licensor is sued by licensee for infringement of claims
essential to implement any W3C Recommendation ... [but] may not impose any
further conditions or restrictions
"""
(http://www.w3.org/Consortium/Patent-Policy-20030520#sec-Requirements" rel="nofollow">http://www.w3.org/Consortium/Patent-Policy-20030520#sec-Requirements)

That seems like a reasonable case for defensive suspension.  Skype's
wording, by contrast, is totally unreasonable, as it extends the defensive
suspension to _all_ lawsuits, no matter their object.  I expect most
companies to use the IWAC, and maybe even most humans eventually.  The
retroactive revocation means that these people can be deterred from suing
Skype/Ebay even after the patents have all expired.

It's absurd, not to mention legally questionable.

  
 

The second clause ensures that someone outside the IETF cannot take the
Skype technology, improve it, and offer a competitive proprietrary codec
that uses Skype IPR. If you modify the codec, you should be doing it in the
context of the IETF standard.
    
 


And once the standard is made?  Skype could effectively block the IETF
from creating an improved version of its own codec, or any optional
extensions (they're not "necessary").  I don't think that's reasonable at all.

--Ben

  
 



_______________________________________________
codec mailing list
codec@ietf.org" rel="nofollow">codec@ietf.org
https://www.ietf.org/mailman/listinfo/codec" rel="nofollow">https://www.ietf.org/mailman/listinfo/codec
  



_______________________________________________
codec mailing list
codec@ietf.org" rel="nofollow">codec@ietf.org
https://www.ietf.org/mailman/listinfo/codec" rel="nofollow">https://www.ietf.org/mailman/listinfo/codec