Chip design teams are all pretty well trained by now to equate “IP” with a block of design content, either “soft” or “hard”, licensed from some external supplier, leveraged to improve design reuse and time-to-market. However, this blog isn’t about that. It’s about managing the “other” kind of IP… actually the original, broader legal interpretation of “intellectual property”, as in patented works. Specifically, I’m talking about the role of managing patents in the world of standards. It’s not what you worry about every day, but that’s why I’m writing this — to share a few core principles you really ought to understand if you develop, contribute, or even use standards in your work.

In EDA, we used to create simple “file format” standards with little regard to patents – after all, what could possibly be patentable in a file filled with “Parameter == <value>” statements? Yet over time, much more sophisticated standards would emerge, closely correlating to much more valuable concepts and clever implementations as we kept advancing toward 20nm silicon techniques. Furthermore, many standards today routinely include software source code IP. These risks became real with consortium-related lawsuits over RAMBUS and SCO Unix, and legal departments now had to worry about the origins of contributed technology, the risks of adopting it, and the risks of sharing what they had if it related too closely to patented techniques.

For standards bodies, there are two broad categories of risk I’ll discuss:
1. The legal risk to a participating company’s own IP portfolio, and
2. The financial risk to using a standard that may contain hidden, latent licensing surprises.
The main idea behind the first risk, protecting the member’s IP portfolio, is to ensure that contributions of IP are always voluntary and explicit. There should be clear, written procedures for offering IP to (or excluding IP from) the group developing the standard. You should make sure that the standards group’s processes ensure that typical technical discussions or slide presentations among peers do not trigger an involuntary “contribution” of IP.

The central idea to avoiding nasty royalty surprises after adopting a standard, is to ensure a transparent, legally binding development process. This means that if any member of the group developing the standard has direct knowledge of IP in their company that might be necessary to adopt the standard, they must either exclude that IP in a certificate attached to the draft specification before voting, or be be legally committed to offer “RAND” licensing terms to all requesters, if the issue arises later. After the standard is published, a “reciprocal RAND licensing” clause then adds growing safety as other companies adopt the standard more broadly across industry. Essentially, each company accepting the license terms for that standard agrees to offer similar RAND terms to all others who developed the standard and/or accepted the license.

Si2 worked this all out 5-6 years ago with a thorough “IP Policy” that implements the above ideas. If you hear about a “60 day exclusionary period”, that just means that the standard is considered done, but is not yet published so any member has time to review and submit a RAND License certificate or Exclusion Certificate on that specification (if they so choose). The resulting standard can then be adopted as safely as possible, across industry, for years and years to come.