In an article published here in January we addressed some of the more significant Internet of Things (IoT) -specific standards and initiatives and emphasized the importance of interoperability as central to the growth and success of the products and services that leverage the IoT. In this follow-up piece, we provide a detailed update regarding one of the leading efforts around standardization, the Open Connectivity Forum (OCF). We also cover three additional industry standards that have particular potential when used in IoT: Bluetooth Low Energy, Wi-Fi (including 5G) and Blockchain.
“Fragmentation is the Enemy”
On February 19, 2016, the Open Connectivity Forum (OCF), a new standards effort for the IoT, was announced. Led by Intel, Qualcomm, ARRIS, CableLabs, Cisco, Electrolux, GE Digital, Microsoft and Samsung, the OCF reportedly seeks to merge the current efforts towards standards development in the IoT, uniting the former Open Interconnect Consortium with companies at all levels, and is “dedicated to providing this key interoperability element of an IoT solution.” The initiative hopes to circumvent the expenditure of time and resources in building consensus between multiple standards approaches, accelerating innovation and assisting developers create solutions that map to one open IoT interoperability specification. Emphasizing this point, Qualcomm recently published on its website that “fragmentation is the enemy of IoT.” The OCF sponsors the IoTivity open source project (covered in Part 1 of this Alert) which includes a reference implementation of the OCF specification licensed under the open source Apache 2.0 license.
OCF Intellectual Property Policy
The Intellectual Property Policy adopted by the OCF shows a high level of attention to detail, thoroughness and nuance. Those considering joining would be well-advised to get some help in understanding how these terms will apply to their specific intellectual property portfolio, products, components and services. We have chosen to take a deeper dive into the intellectual property policy for this standard because the details of the policy reveal a number of areas of focus of the founding members.
While the policy imposes obligations on members as well as their affiliates to grant licenses under copyrights and patents, the scope and cost of those licenses will depend on a number of specifics that will vary depending on the precise contours of the final specifications. Members are required to represent that they are authorized to bind their affiliates to the terms of the policy, including parent and sister companies.
1. Patent Claims Captured. The patent claims captured by the policy are limited in a number of ways:
- The only claims captured are those that would be necessarily infringed by implementing the mandatory portions of the specifications within the bounds of a tightly defined scope that ties specifically to enabling the compliant portions of products to interoperate, interconnect or communicate.
- Necessary infringement is defined as there being no “commercially reasonable” non-infringing alternative for this enablement. The policy requires that any transfer of these necessary patent claims to unaffiliated third parties must be subject to the terms and conditions of the policy, and transfer or assignment agreements must explicitly address the fact that the transfer or assignment is subject to existing licenses and obligations imposed by standards bodies such as OCF. Those who practice in the merger and acquisition arena will want to take note of the potential issues for both sellers and acquirers in light of these requirements.
2. Patent License Scope. The license scope is also limited in similarly nuanced ways. The license under the above patent claims extends to only those portions of products and services that implement the protocols, functions, APIs and their adaptation layers, input parameters, data structures, services and firmware descriptors that fall within the mandatory portions of the final specification (including mandatory portions of optional components of the specification). Moreover, the policy goes to great lengths to ensure that, unless the final specification is explicit and describes in detail these items where the description’s sole purpose is to enable interoperability, interconnection or communication, no license will apply. This would seem to place a heavy burden on the developers of the specification taking this into account in developing the details of the specifications.
3. Opt-Out is not true Opt-Out. Another interesting aspect of the policy is that while the policy allows for members to exclude specified patent claims from the royalty-free license, this opt-out mechanism is constrained. Most importantly, members cannot opt out entirely. The policy imposes a requirement to license those excluded patent claims on reasonable and necessary non-discriminatory terms—again, this applies even if patent claims are excluded in accordance with the opt-out framework. The opt-out mechanism also only can be exercised 4 times in any 60 month period.
4. Copyright and Software. While we have focused on patents here due to the policy’s emphasis on the patent rights granted, the policy also imposes obligations to license copyrights. The policy only addresses rights under copyright to contributions made by members to the specification itself. The policy also includes a brief statement permitting members to contribute OCF open source that OCF deems acceptable and non-confidential as well as modifications and additions to such open source software to open source projects. It is not clear what will be considered acceptable and what software will be made non-confidential. It is also not and does not appear to extend to software beyond acknowledging that members may license their software source code that implements the specification under open source licenses and may make contributions of such source code to open source projects. No limitations on which open source projects are permitted appear. This seems odd given that this could result in OCF open source software ending up being contributed to projects that impose license terms that conflict with one another. It seems that OCF may have decided to defer these issues to the future once it has determined what is “acceptable” and what software OCF itself will make available.
5. Rights on Termination. Termination also raises issues for terminating as well as continuing members. Once members join, they may not terminate the licenses they have previously granted to other members prior to termination with respect to versions of the final specification that existed while they were members or contributions to draft specifications that they made which become part of subsequent versions of the specification after their termination. Continuing members are also required to provide more or less reciprocal grants. Continue Reading