Re: Formal Objection to One vendor, One Veto

At 10:44  +1000 17/07/09, Silvia Pfeiffer wrote:
>I think patent roll calls are usually done within a standards body to
>get everyone who is involved in creating the standard to step forward
>and register their demands on the patent pool at the given time. I
>have indeed taken this concept out of that context and suggested using
>it for a different but related purpose. Until we see such an approach
>tested in court, we will probably not know if it can have the effect
>that I am hoping for. But it's an idea and it would be nice if there
>was a lawyer to comment on its potential.

I think you have two activities mixed up.

Standards bodies generally issue calls for patents so that they can 
document, informatively, who claims IPR on a standard.  This is done 
to assist implementors in finding who they might need to approach, 
and to get a commitment that the IPR is licensable (usually on 
reasonable and non-discriminatory terms).  If IPR emerges which 
cannot be licensed on the terms the standards body asks for (e.g. the 
owner doesn't want to license) then the standards body takes evasive 
action.

Licensing pools are a convenience.  For standards that entangle a lot 
of IPR, it can be tedious to approach every IPR owner separately, and 
it is sometimes hard to reconcile the variations in terms they ask 
for.  Accounting and so on are also complicated if many must be paid. 
Pools are formed independently of the standards activity to provide 
'one stop shopping', as a convenience.  However, I think it has been 
ruled that they cannot be the exclusive access to the IPR, that the 
licensors cannot be constrained to make their IPR only available 
through a pool.  Some IPR owners also, as a policy, do not join pools.

Using the first part of this to raise the profile of the open-source 
codecs, and to get any owners of IPR that reads on these codecs, to 
declare that, might help.  It does, however, take work.

Hope this helps.
-- 
David Singer
Multimedia Standards, Apple Inc.

Received on Tuesday, 21 July 2009 22:36:14 UTC