Once upon a time, if you asked a standards setting organization (SSO) what its intellectual property policy rights (IPR) policy was, you’d get a simple answer: “We own the copyright in everything we produce.” Today, if an SSO that develops standards in the technology arena were to give an answer like that, it would find that its members were heading for the exits.
What’s changed, of course, is that information technology has infiltrated almost every aspect of our existence, and that includes standards development as well. For example, an SSO that used to limit its attention to setting construction standards relating to heating and ventilation installations will now also host working groups developing standards for sophisticated building control systems.
The result is that scores of traditional SSOs now support working groups that focus on information and/or communications technology (ICT) standards in addition to their traditional subject matter areas. And many hundreds of new SSOs (often referred to as consortia, alliances or forums) have been launched over the past thirty years with the mission of developing ICT standards alone (you can find a list of them here), with more being launched almost every week.
An unfortunate and complicating fact is that virtually every one of the technology standards that one of these SSOs creates has the potential to result in patent infringement when it is implemented (although this actually happens infrequently). Most SSOs would like to avoid that result if they can, and if they can’t, they’d like to be as sure as possible that any “necessary claims” under a patent (i.e., patent claims that a vendor can’t avoid infringing when it builds to the standard) will be available to everyone on reasonable and non-discriminatory (RAND) terms. There’s nothing they can do about non-members that own patents, but they can stop members from over-charging for their technology when it does get incorporated into the SSO’s standards – often because the member urged the working group to accept it. The way they achieve this goal is through the adoption of a carefully thought-through IPR Policy that sets forth the rights and obligations of the members that help develop a standard.
Twenty years ago, such a policy would usually have been quite brief, and would have limited itself to making high-level statements. In the U.S., many traditional SSOs simply adopted the one page minimum requirements text found in the American National Standards Institute (ANSI) Essential Requirements accreditation document. But with the increasing proliferation of patent “thickets” in the ICT area, many SSO members decided that this approach had become inadequate, a perception that multiplied dramatically when the U.S. Supreme Court ruled in 1998 that software was patentable.
The sequel to The Alexandria Project
Just $2.99 at Amazon
Along the way, existing SSOs found they were having increasing difficulty attracting new members with large patent portfolios if they did not have an up to date IPR policy. And it became impossible to recruit members to a new SSO until it had adopted an IPR Policy that contained not only precise rules relating to patents as well as copyrights, but also specific process rules directed at requiring working group participants (and often all members) to disclose any necessary claims they owned before final adoption of a standard. They were also required to state whether they were willing to license those claims on RAND terms, and if so, whether they would, or would not, require a RAND payment for such a license. Some organizations prohibited charging patent license fees at all.
As the last statement above suggests, there are many different opinions about what the specific IPR rules and processes should be in any given SSO. This range of viewpoints is exacerbated by the fact that some members have huge patent portfolios while others have none, and the reality that some members are vendors (and are in a position to charge for their patents) while others are users (and would have to pay those fees), among many other complications and variables. Moreover, the same company may be a vendor with respect to the standards being created by one SSO, but a user when it comes to the standards created by another that it is active in. Further, rules that be acceptable in one industry (like consumer electronics) may be unacceptable in another (such as Internet-based services).
The result is that not only do some types of stakeholders have dramatically different interests (and therefore opinions) when it comes to IPR policy rules, but those interests (and opinions) may change from one industry niche or SSO to another. Indeed, it is not unusual for a given company to argue forcefully in favor of toggling a given term one way in one SSO, and just as vigorously advocate for it to be flipped in the opposite direction in another, an experience I’ve witnessed first-hand on many occasions.
What this means for an SSO that develops ICT standards is that its ability to recruit members is critically dependent on whether it has adopted an IPR policy that its target membership finds acceptable. Due to the divergences of interest alluded to above, “acceptable” might more accurately be phrased as “tolerable,” reflecting a state where if every member type is equally unhappy with the result (but still happy enough to join), the SSO has probably hit the nail on the head.
That’s not a glib statement, by the way. If an IPR policy is slanted too far towards one viewpoint over another, those with the other viewpoint will simply not join, thereby damaging the SSO’s reputation for neutrality. The result can be that the marketplace distrusts its standards, and that adoption of those standards suffers. Where achieving interoperability between products or services is the purpose of the standard in question, that means that the goals of the SSO may be defeated, and the dues and efforts of its members wasted.
One might think that eventually things would settle down, and that consensus on IPR policy terms would emerge, at least within an industry. However, this has never proven to be the case. Because court decisions may highlight IPR policy deficiencies, and since technology and business models continue to evolve, the expectations of members, markets and regulators regarding IPR policies have remained in a state of continuing development and change. For example, in the last decade, many SSOs introduced changes to their IPR policies to make their standards more acceptable to those developing open source software. Today, most ICT SSOs are amending their policies to require that RAND obligations to license necessary claims will travel with the patents containing those claims when they are transferred to another party.
The moral of the story for anyone that manages an existing ICT SSO is that maintaining a state of the art IPR policy is essential to the health of the organization. For anyone seeking to launch a new ICT SSO, the warning you should hear loudly and clearly is that generating the right IPR policy (and not simply copying the policy of another SSO) will make the difference between success or failure – full stop. Unless that challenge is accepted at the beginning of the planning process, the eventual launch of the new organization will likely be delayed. Either way, unless the inevitably divergent opinions and priorities of the founding members are skillfully reconciled and appropriately documented, the organization may never launch at all.
Not sure what (exactly) has gone on here, but I am distinctly getting a case of ‘deja-vu’ all over again …
The paragraph that starts: ‘The moral of the story for anyone that’, ends with ‘all.), with more being launched almost every week.’ This appears to be a duplicate from the end of your third paragraph.
One quick question: What is in it, from an SSO’s perspective, to encourage them to run the obvious gauntlet(s) delineated in your article. Is it mainly kudos? While obvious for ‘construction’ type standards, and while, from my understanding, the SSO is not liable from the actions/ inactions/ infringements of its members, do they risk anything but reputation? Are ‘international’ SSOs equivalent to herding cats, since different laws/rules or lack thereof affect the effectiveness of their ICT policies. (I am specifically thinking of China and/or India). Is there actually going to be a worldwide standard for IoT communications protocols, and will a standard 5G cellular/mobile phone protocol evolve before or after an SSO gets involved?
If that question wasn’t short enough for you, I can make it Loooonger!
Actually, study after study has shown that when someone reads the same text twice, they are 49% more likely to remember what they read. Incredible, don’t you think? Of perhaps I just screwed up and cut and pasted twice (thanks for catching that).
Regarding your question(s): regrettably, companies with huge patent portfolios are more likely to worry about subjecting a patent to a licensing obligation they didn’t expect, or don’t agree with, than they are with stopping other members from gaming the system. The result is that they won’t join an SSO at all until they know what the rules are. So it’s not kudos or masochism, it’s a necessary and unavoidable hurdle that the founders of an SSO can’t avoid.
And yes, herding cats is not a bad description. There’s a well-recognized range of acceptable terms, but where a given organization falls out along that spectrum can be a matter of vigorous disagreement, in part because different members have different business models (technology licensors, component makers, aggregators, technology licensees, etc.).
The international aspect isn’t as bad as it might seem, since patents and copyrights are the subject of various international treaties, thereby limiting the local variations in many countries. And IPR rules themselves are general rather than specific – you’re required to "provide a license on reasonable and non-discriminatory terms" rather than to provide a specific license with line by line standardized terms.
Regarding the IoT, it’s likely that there will be more standarization on open source stacks than using standards. I represent several of those efforts (AllSeen, Node.js, etc.).
As far as 5G, well, you’re on your own for that one.