Re: [codec] Skype IPR disclosure

[Stephan Wenger <[e-mail]>]

Hi Marc,

It is not difficult to convey a patent-related motivation--even
information--without exposing other people and their employers in an obvious
way.  

Allow me to put exaggerated words into your mouth: "I believe our current
draft, especially algorithm T, is infringing on US 1,234,567, claim 8.  We
may be better off with T', because <non-infringement argument>"  (Believe it
or not, I have seen this type of language, and not from a plaintiff's
attorney in a closing argument--which is the only place where such words
ought to be uttered :-)  And here is what I would write: "In conjunction
with IPR disclosure #1234, I have studied certain documents.  It may be to
all (well, almost all) of our advantage if we were replacing algorithm T
with algorithm T'.  One advantage would be <non-infringement argument>"

The first alternative exposes all subscribers to a patent number, and would
show up with a simple google search of a patent numbers (even lawyers
representing trolls know google, unfortunately, and probably a bit better
than some of us...).  The second conveys information that an informed and
interested reader can probably quite easily use to end up with the same
factual information, but is not so obvious.

That's all what I ask for.

(That I, personally, like my hide enough not to discuss someone else's
patent is a different story.)

As for the documentation of motivations for historic reasons: motivations
for design choices get lost in standardization all the time.

Regards,
Stephan




On 3.28.2010 11:13 , "Marc Petit-Huguenin" <[e-mail]> wrote:

> On 03/28/2010 10:13 AM, Stephan Wenger wrote:
>> Hi Marc, all,
>> 
>> The article you linked is IMO a useful thing to read for those who do not
>> know how to study patents.  But, please understand, it is really 101 level.
>> There are many, many subtleties when interpreting claim language, and this
>> is an ever-evolving field, just as technical codec design is,
>> 
>> The article is written from an US law perspective, but that's IMHO alright,
>> considering where the majority of the patent litigation is ongoing today.
>> The business situation addressed is clearly that of an open source
>> developer, not that of a multi-national corporation, but you indicated that
>> in your posting already.
>> 
>> Commenting on your own post, there are two key problems in your logic about
>> the non-issue of willful infringement (which many people inadequately
>> circumscribe as "triple damages"--triple damages are a consequence of
>> willful infringement, but not the root cause.)
>> 
>> The first flaw, as I perceive it, is that your (and your employer's)
>> exposure to the patent is not restricted to your work in this working group.
>> It may come haunt you on past and future projects, and on anything you are
>> doing in parallel with the work here, as well.  That may be a non-issue if
>> the work in the codec WG is a hobby of yours, but if you are a codec
>> professional, it is something to consider.
> 
> Well, this is not new for professional developers.  E.g. as a former Java
> Licensee, I cannot contribute to the Apache Harmony project.  C'est la vie.
> 
>> 
>> Second, there is also the issue of statuary rights under patent law.
>> Especially in the open source community, but also in other standardization
>> and implementation circles, individuals tend to worry mostly about patent
>> rights being violated by "implementing".  This corresponds to the "make"
>> category in patent law.  However, the (US-) patent law also allows to
>> exclude others from the "use" and "sell" of a patented invention (the
>> formulation in other jurisdictions vary, but are generally similarly wide as
>> in the US).  Arguably, if your employer (through your participation here)
>> learns of a patent today, and your employer is currently selling products
>> containing another codec that is encumbered by the patent right, and a bunch
>> of other conditions are met, then willful infringement may trigger.
>> 
>> The business decision to study patents is, of course, up to you (and
>> possibly to your employer).  If your goal is the design of a freely
>> practicable codec, it could be helpful to do so.  My guess is, though, that
>> the risk/benefit equation is very different between different employers,
>> even if they are of similar size.  That's why I'm arguing so strongly to
>> give people a chance stay ignorant and out of patent discussions.
> 
> I think that there is a problem here.  Let's say that the CODEC's codec
> algorithm uses a specific technique, let's call it "T".  I then discover that
> T
> is patented.  I can (and will) fill a third party IPR disclosure.  People in
> the
> mailing-list will know about this but cannot discuss it, according to what you
> are saying.  OK, then I propose a modification to the specification to replace
> T
> by T'.  According to you I still cannot discuss why T' is better than T,
> because
> it is not a technical argument.  Let's say that people got a clue and decide
> to
> put T' in the specification instead of T.  According to you we still cannot
> say
> in the specification that T' is here because even if T seems obvious (a common
> characteristic of all things patented) we cannot use it.  Now 5 years from
> now,
> someone wanting to implement the specification has no idea why it is so
> complex,
> because the reason is not in the spec and not in the mailing-list archives.
> 
> How is that not fundamentally broken?
> 
>> 
>> Stephan
>>    
>>    
>> 
>> 
>> On 3.28.2010 08:22 , "Marc Petit-Huguenin" <[e-mail]> wrote:
>> 
>>> On 03/24/2010 06:58 PM, Stephan Wenger wrote:
>>>>  Hi Rob,
>>>> 
>>>> Wearing my ³technical advisor to the IESG on IPR matters² hat:
>>>> 
>>>> I¹m commenting in this email only on the ³third party disclosure²
>>>> subject.  I may comment on the other subject later, as, admittedly, they
>>>> are more murky.  Phrasing a reply certainly requires more undistracted
>>>> time than I have now (sitting in the IETF77 plenary).
>>>> 
>>>> I note that you have provided information of two patent applications
>>>> that have not been recited in Skype¹s declaration.  Specifically,
>>>> neither the GB application, nor the PCT application, have been disclosed
>>>> by Skype.  Nowhere in BCP 79 or in the IETF¹s current practice I find
>>>> language or common conduct indicating that, by disclosing one or more
>>>> patent family members, one has to infer that all patent family members
>>>> are disclosed.  If you are aware of such language, I would appreciate a
>>>> pointer.
>>>> 
>>>> In this light, I continue to believe that you were not within the
>>>> language, nor the spirit, of BCP 79 when you cited these patent numbers.
>>>> 
>>>> Advisor hat off, private statement:
>>>> 
>>>> Rob, you are a lawyer, and are listed in the IP law section of the CA
>>>> bar association.  You are a professional in this field.  Most of the
>>>> subscribers of this *technical* working group list are not.  They may
>>>> not know what harm could befall them, and their employers, if they start
>>>> reading someone else¹s patents, and perhaps start commenting in public
>>>> on it.  
>>> 
>>> http://news.swpat.org/2010/03/transcript-tridgell-patents/
>>> 
>>> The arguments presented were for FOSS, but I am thinking that one argument
>>> in
>>> this presentation may apply to the CODEC work.
>>> 
>>> My thinking is this:  The goal of this WG, as described in the charter is to
>>> produce a RF codec.  Producing a royalty-free codec means that each time a
>>> technique is used in the codec, it should be either covered by an expired
>>> patent; or have plenty of prior art anterior by at least one year to the
>>> oldest
>>> valid patent; or been so new that there is no patent; or been covered by a
>>> patent with a royalte-free license that apply to this work.  If a
>>> non-expired
>>> patent without an RF license is found for the technique, then there is only
>>> one
>>> way to fix this: remove the technique from the codec and find another way.
>>> If
>>> the goal of this WG is really to produce a RF codec, then it does not matter
>>> if
>>> we discuss patent and prior art and so on in this mailing-list, because
>>> neither
>>> single or triple damages can apply, as any technique that could trigger
>>> either
>>> of them will be removed.
>>> 
>>> Now finding a workaround for a technique that we cannot use is impossible
>>> without discussing it.  If we want our best minds trying to find how to not
>>> employ a specific technique, then we have to explain why this specific
>>> technique
>>> cannot be used, and I do not see how to do this without discussing the
>>> patent
>>> in
>>> this mailing-list.  In fact I think that each single line of the codec
>>> description should be annotated in some way with all the prior art, expired
>>> patent and so on all the way to the Sumerians to prove to everybody that
>>> there
>>> is no issue.  (I suspect that the triple damage thing is used to frighten
>>> the
>>> very people that could really do harm a patent by finding a way to ignore
>>> it).
>>> 
>>> The only possible collateral damage would be if a developer is reading this
>>> mailing-list and discover that a technique applies to its own code and thus
>>> will
>>> be eventually open to triple damages on its own code.  I think that somebody
>>> like this should not be in this mailing-list in the first place.
>>> 
>>> And, BTW, IANAL.
>> 
>> 
>