Internet of Things: The Implications for IP Law Practice

IoT businessmanUp until now, many IP practitioners have focused on protecting the physical – devices, structures, the configuration of physical systems, physical outputs, the operation of physical systems and physical connections. In Industry 4.0, however, focus needs to remain on the foregoing but thought also needs to be invested in IP protection for methodologies, the configuration of virtual components, data handling and storage, processing algorithms, user interfaces/experiences, methods of use and brand recognition.

The IoT presents a challenge to IP practitioners to adapt existing IP protection strategies by developing new approaches better suited to the rapidly changing, connected-yet-disconnected network of innovations forming the IoT. By opening communications and application programming interfaces (APIs) to more and more collaborator-yet-competitor devices, innovators (i.e., clients) must carefully guard their IP while at the same time facilitating interoperability and security among connected devices. Below, we present the adaptation of some existing strategies as well as thoughts on new strategies for IP protection in the interoperable world of the IoT.


Over the last decade, there has been a movement among the software developer community to employ some form of “agile development” rather than the traditional (i.e., “waterfall”) software development methodology.39 The belief is that these agile methodologies (e.g., Scrum,40 Extreme Programming (XP), Feature-Driven Development (FDD), Kanban, Lean, etc.), achieve higher quality software in a shorter period of time via self- organizing teams collaborating with customers with less documentation and reduced time to market. [41]

Traditional software development is a sequential approach where once a software application is designed and coding is complete, then the software is tested (and debugged) before it is deployed in a customer environment. This sequential “throw it over the wall” approach, where designers, developers and testers fail to interact during each step of the process, takes place over the course of several months or even years. Thus, end users typically only get to see results at the very end of the waterfall project.

In contrast to the sequential, waterfall approach is the agile software development approach in prevalent use among analytics software developers during the Fourth Industrial Revolution. (A 2013 survey of over 3,500 software professionals concluded that 88 percent of organizations were using some form of agile.) [42] Generally speaking, the agile approach employs small, cross-functional teams of designers, coders and testers working through multiple iterations (called “sprints”) that last two to four weeks in order to produce a potentially shippable product – termed a “minimally viable product” or “MVP.” After each sprint – each delivering a software product with increasing functionality – there is an opportunity for (internal and external) customers to review the latest incremental build. Agile is based on the notion that sometimes customers need to see the wrong product before they can articulate what they really need!

As shown in Figure 3, agile projects proceed in an iterative fashion where new features are integrated to extend the capabilities of the software. That is, each sprint delivers user-desired, working and tested features. Each iteration generally consists of four distinct phases: planning, development, user review and retrospective.


Figure 3

Figure 3

In the planning phase, all stakeholders (i.e., designers, testers, coders and product management) meet to decide and document which new features are to be added to the software, or what changes to existing features need to be made. Once decided, the order of feature completion or change is prioritized. Next, the development team creates a list of technical tasks necessary to create each of the one or more desired features and allocates a time and resource estimate to each such task. This phase comes to an end when all stakeholders agree upon the features to be implemented within the given time and resource constraints.

In the development phase, the development team works to code, test and debug the one or more features agreed upon between product management and other stakeholders during the planning phase. Then, in the user review phase, the development team demonstrates the software and its newly implemented features or changes to product management (and perhaps potential customers/product advisors). Product management then decides if the software is correct and complete. Thus, completed features are removed from the list of features needing another planning phase and incomplete features are again candidates for future iterations. Lastly, in the retrospective phase, the development team meets to reflect on the last iteration and discuss those tasks, techniques and team interactions that worked and those that need improvement.

In sum, organizations implementing agile development approaches believe that the software development process improves through “more stable requirements, earlier fault detection, less lead times for testing, increased communication, and increased adaptive capacity.”[43]

However, while agile development produces innovations worth protecting, the limits imposed by an agile methodology wreak havoc on the traditional workflow of an IP practitioner. For instance, traditional IP capture methodologies rely on a more relaxed flow of invention disclosure, evaluation, strategy and IP rights procurement, which unfolds over a period of several months during (or sometimes after) a traditional product development cycle. In an agile environment, however, a faster-paced, condensed idea submission and evaluation process that occurs over the course of a few days or weeks is needed. Similarly, the rapid pace of sprints leaves developers with precious little time to strategize, analyze, document and capture any potentially new IP.

As shown in Figure 4, the goal of the practitioner should be to mirror the client’s agile development methodology. This results in an IP-educated development team entering into the planning phase where initial IP priorities are identified. In the sprint phase, inventions can be mined and in the user review phase, provisional patent filings are made. During the retrospective phase, IP protection strategies can be reviewed, confirmed and finalized. Using this rhythm, each iteration of the agile project provides a subsequent opportunity to further refine the IP capture/ protection strategy. The resulting product can then be reviewed prior to release to identify further opportunities for (domestic and international) patent filings and other protection mechanisms (e.g., trademark and copyright registrations, end- user license agreements, etc.).



As clients “go digital,” they will no doubt be developing (more) software as part of IoT solutions (i.e., hardware equipped with sensors and wireless communications generating valuable data to enable end-users to monitor and operate such hardware more e ciently). This software, however, will not be 100% proprietary software written by our client’s employees, contractors or development partners. Rather, portions of such software will most certainly contain third-party code known as “Open Source Software” (or “OSS”).

OSS is defined as: “Software that can be freely used, changed, and shared (in modified or unmodified form) by anyone … and distributed under various licenses… [where the] source code is available.” [44] OSS code can be in the form of “snippets” that provide a software application with specific functionality (e.g., data sorting, event scheduling, etc.) or can be a complete application (or operating system). OSS di ers from “proprietary” (or “closed source”) software in that the source code – not just the executable – is available for anyone to view, modify and redistribute. Yet, these activities must be done consistently with the OSS license pursuant to which the code was received. [45]

OSS licenses may generally be described as falling into one of the following three categories (with varying levels of risk): (1) Permissive – An OSS license that contains little or no restrictions on the use, modification and redistribution of the OSS other than requiring giving the original author attribution (e.g., the Apache License [46]); (2) Less Restrictive – An OSS license where any use of the OSS requires attribution and any redistributed modifications require making the modified source code available to third parties unless the new code simply links to the original OSS code (e.g., the Mozilla License [47]); or (3) Restrictive (or Copyleft) – An OSS license where any use requires attribution and any redistribution requires making the source code available to third parties under the same OSS license as the original code (e.g., the GPL License [48]).

In sum, before any client’s project uses OSS, it is important that the client understands the code’s pedigree (think malicious code and cybersecurity), how exactly the OSS will be used (e.g., incorporated into a customer-facing product or used solely for internal development and testing), and what the terms of the OSS license dictate based on such proposed use. Given the danger of using OSS – especially the restrictive-type licenses where internally-developed code may become “infected” with OSS thus requiring the release of such proprietary code to the public – why would anyone ever use OSS!? That is, there is a common myth – even among supposedly well-informed IP practitioners – that OSS is a bad thing and must be avoided. This is untrue.

According to one study, only 3% of companies use no OSS code whatsoever (i.e., no OSS usage in their internal IT systems or as part of their external, proprietary code distributed to their customers). In fact, of companies with over 5000 employees, 67% participate in at least one OSS project and 66% of all companies consider OSS before considering proprietary software alternatives. [49] This is because OSS has four important advantages:

  1. The cost of obtaining OSS is often free and thus significantly less than purchasing proprietary software that is typically licensed under “per user” fees;
  2. Because the source code is freely available, a large community of talented developers are able to inspect, improve and redistribute the code, leading to a more reliable product with bugs being fixed quickly;
  3. OSS allows consumers of the code to not be tied to a proprietary product, where upgrades, patches and hardware requirements are dictated by a single company on their pricing terms; and
  4. OSS insulates consumers of the code from a commercial software company going out of business or ceasing to support previously- purchased proprietary code.

In sum, while the use of OSS should be generally encouraged, there may be significant risks depending on several factors. The fact is, world- class software companies employ rigorous end-to-end OSS review processes in order to mitigate risks to their proprietary code. That is why IP practitioners should assure their clients have an OSS policy in place that dictates internal procedures for Engineering, Legal and Product Security to work together to ensure only approved OSS is used in any project. Such a policy would require:

  • The designation, by each P&L or division, of a knowledgeable software engineer as the “OSS Compliance Leader,” responsible for ensuring compliance with the policy and serving as a liaison to the legal department;
  • The clearance of all OSS snippets and programs before any internal use or incorporation into any of the company’s software/products;
  • Automated scans of any software or product prior to its release to identify all OSS therein (this list will then be reviewed by the OSS Compliance Leader (or delegate) to ensure there is no high-risk OSS in the software/ product); and
  • Approval of any potential employee contributions to an external OSS project community.


During the Fourth Industrial Revolution, the concept and nature of proprietary files are also changing. This is especially true for those client firms that design and manufacture IoT-related hardware. Such clients are now striving to become “Model Based Enterprises” (or MBE)50 where engineering departments are moving away from using 2D engineering drawings (i.e., blueprints) to utilizing 3D product definition (i.e., Model Based Definition or “MBD”)51 digital files. Such digital files can then be utilized and shared across their “digital thread” (i.e., the digital data flow between engineering, manufacturing, business processes and across supply chains). [52] This enables the rapid, seamless and a ordable deployment of products from concept to disposal. In fact, one study has shown that organizations utilizing MBD files can save millions by reducing new product introduction cycle time by an average of 74.8%. [53]

Given that MBE digital files – produced by 3D Computer Aided Design (CAD) software – define and provide the specifications for individual components and product assemblies (e.g., geometric dimensioning, tolerances, component level materials, assembly level bills of materials, engineering configurations, etc.), the potential loss of valuable IP obviously increases. In the wrong hands, these digital files contain a company’s confidential information that allow for the rapid prototyping and copying of product designs by methods such as 3D printing.

Thus, as clients use 3D CAD software – such as Creo®, NX® and SolidWorks® – to generate MBE digital files that are: (1) non-intelligent (i.e., read-only) files in 2D PDF, Ti or 3D (interactive) PDF format; (2) intelligent (i.e., containing product and manufacturing information or “PMI”) files in a format native to the particular 3D CAD software in use); or (3) intelligent files in neutral, multi-CAD portability format (e.g., ISO 10303 format [54]); it is essential that IP practitioners instruct their clients to:

  1. Share MBD files only under a Non-Disclosure Agreement (NDA) where “Confidential Information” is broadly defined to cover electronic files such as MBD files;
  2. Always think carefully before sharing to determine what level of detail the recipient of an MBD file actually needs (e.g., contract manufacturers, suppliers and customers need di erent levels of detail so that the “enveloping” feature of the CAD software is used accordingly to mask design details that the recipient has no need-to-know); and
  3. Include “[Company] Confidential” in the MBD file name prior to transmitting and embed a proprietary notice in the file, such as:The information contained herein is the confidential and proprietary property of [Company]. It is to be used only for the benefit of [Company] and shall not be disclosed, transferred, reproduced, altered, or used for any purpose without the express prior written consent of [Company].


While we focus herein on IP, and the other legal and regulatory issues implicated by the IoT are beyond the scope of this paper, we do need to address one labor and employment law-related issue. After all, you cannot have smart objects without smart people designing, building and deploying them!

In today’s labor environment, more and more technical work is being done not by full-time, local (i.e., on-premise) employees, but by contingent workers in the “human cloud.” That is, in today’s Industry 4.0 economic environment, “white-collar jobs [e.g., programmers and statisticians] are chopped into hundreds of discrete projects or tasks, then scattered into a virtual ‘cloud’ of willing workers who could be anywhere in the world, so long as they have an internet connection.” [55] It is estimated that in 2014, companies spent between US$2.8-3.7B globally on payments to workers in the human cloud and the online platforms that serve as intermediaries. [56]

Of further concern, in addition to the disperse nature of these short-term, free-agent human cloud workers, is the current transient nature of IT employment. That is, full-time IT workers have the highest turnover rate than any other industry with worldwide estimates ranging from 20–30% annual attrition rate and only 1–4 years of tenure.[57]

Thus, in a world where workers are as mobile as the apps they create, one of the biggest threats to a company’s IP, unfortunately, is its human-cloud contractors (and its own employees) through inadequate ownership rights and knowledge spillover due to subsequent (competitor) employment. [58] It is prudent for IP practitioners to advise their clients to: (1) enter into employment and contractor agreements that contain nondisclosure obligations and IP assignment clauses with all personnel upon their initial engagement with the company; and (2) implement physical and IT security controls (e.g., document management systems, network monitoring, data loss prevention software, disabling USB drives, etc.) to control access to source code files, MBD files, design specifications and other IP-rich documents. These measures, however, must be done in compliance with all applicable national
and local laws governing employee privacy, inventor remuneration and limitations on employee invention ownership.

Further, fostering a culture of IP training (both formal and informal “brown bags”) and inventor incentives (e.g., remuneration, recognition plaques, annual inventor dinners, etc.) will help ensure that a company’s personnel are not only aware of IP, but also enthusiastically participate in its capture, protection and enforcement.


Traditionally, IP practitioners have been concerned about protecting the software/algorithms that process data and the hardware that stores it. In Industry 4.0, however, the data itself is worthy of protection. This is because the IoT’s promise is the ability to perform analytics on data collected from connected smart objects to lead to new knowledge and provide insights. Thus, the legal rights to these (big) data sets are obviously of paramount importance.

Absent a jurisdiction’s sui generis protection scheme – such as the European Union’s Directive 96/9/EC on the legal protection of databases [59] – the protection of data has traditionally been through the trade secret and copyright laws. While useful, these laws have not always been adequate.60 It is most likely that contract law will best serve clients operating in the IoT space. Thus, as IP practitioners will no doubt be called upon
to draft, review and negotiate such IoT-related contracts, we now address the types of, rights to, and licensing constructs surrounding, such IoT data.

First, practitioners should be aware of the di ering types of data that an IoT-related contract may need to address: (1) machine/unprocessed/ raw data – this is simply the big data sets that are collected from the relevant smart objects at issue in the IoT-related contract; (2) processed data – this is the set of data resulting from (i.e., post-) analytics of the raw data by any actor (e.g., customer, ASP, smart object manufacturer or servicer) in the IoT ecosystem; and (3) input data – this is any data that is entered by the end-users who interact with the relevant smart objects at issue (and/or their respective customers).

Second, practitioners should be aware of the di ering legal ownership rights to IoT-related data that a contract may need to address: (1) the smart-object manufacturer may simply own the data regardless of whether the smart object itself is sold or leased to a customer; (2) the smart- object manufacturer may own the data, but the customer will receive a license to some or all of the data; (3) the smart-object manufacturer may own the data, but the customer and some third parties will receive a license to some or all of the data; or (4) the customer may own the data, but the smart-object manufacturer will receive a license to some or all of the data and for all or some specific purposes.

Third, much like joint IP ownership clauses in collaboration-type agreements discussed below, data rights provisions in IoT-related contracts will likely be the subject of heavy (and sometimes contentious) negotiations. After all, the data in is the gold in Industry 4.0 and cultural shifts in attitude towards data sharing in some industries have not kept pace with the progress of technology! So, in any IoT-related contract, at least the following licensing constructs surrounding the data must be addressed:

  • Who owns and who is licensee?
  • What is the business model: sale of services, software license or hardware sale?
  • What data?
  • What rights?
  • What products or field(s) of use?
  • What territory?
  • Exclusive or non-exclusive?
  • Right to sublicense?
  • How long (i.e., term)?

An example ownership clause that implements the “smart-object manufacturer owns the [machine and processed] data, but the customer will receive a [limited] license to some of the data” model is as follows:

Customer acknowledges and agrees that Manufacturer owns all right, title and interest in the Equipment Data. Customer will upon request deliver such data to Manufacturer. Manufacturer hereby grants Customer a perpetual, non- exclusive, non-transferable, royalty-free license to use, reproduce and store the Equipment Data solely to the extent required to operate Customer’s equipment.

“Equipment Data” means any data, metadata, logs or other information generated by the operation of the Software or the Device, but does not include any personally identifiable information nor any information entered into the Software or the Device by Customer’s employees, agents or end-users, except to the extent portions of such information appears in anonymized or aggregated form or in automated logs or similar records through the normal operation of the Software.

Lastly, it is a best practice in theory to obtain user consent before leveraging user data in the form of smart object operating information, usage patterns, measured environmental factors and the like. In practice, however, it may be impractical to keep track of who is contributing and who is using which information when multiple devices are involved. In an IoT environment, data from one or more customers is often comingled with other device data generated by (and arguably owned by) one or more device providers. If expectations and responsibility for data security and privacy are not made clear, a client may be vulnerable to consumer action regarding breaches of data security, privacy, etc. We have not yet seen a thorough body of case law enumerating who owns  or is responsible for which data in a connected device environment. Therefore, drafting contracts which are clear and careful as possible with respect to gathering, anonymizing, notifying and using customer data remains a best practice to be carefully implemented in an IoT environment.

TO BE CONTINUED… Up next — IP Protection Strategies to match the Uncertainties of an IoT Environment.


39 See C. George & R. Millien, “Protecting IP in an Agile Software Development Environment,” American Bar Association Landslide® Magazine (July 2015), reprinted in 27 State Bar of Michigan IPLS Proceedings 1 (2016) at pp.8-14, portions of which are reproduced herein.

40 This is the most popular form of agile software development. (For a tutorial video, see Scrum.htm.).

41 Gaurav Kumar & Pradeep Kumar Bhatia, Impact of Agile Methodology on Software Development Process, 2 Int’l J. Computer Tech. & Electronics Engineering, no. 4, Aug. 2012, at p.46.

42 VersionOne, 8th Annual State of Agile Survey (2014).

43 Id. at 49.

44 Open Source Initiative, Open Source Definition (visited Aug. 8, 2016).

45 A list of the most common OSS licenses may be found at 46 http:/



49 North Bridge and Black Duck, 2015 Future of Open Source Study.

50  See

51  See

52  Thomas Hedberg, Jr. et al., Testing the Digital Thread in Support of Model-Based Manufacturing and Inspection, ASME Journal of Computing and Information Science in Engineering (Mar. 8, 2016) at p.1.

53  Id. at p.12.

54 Wikipedia, ISO 10303 (visited Aug. 11, 2016).

55 Sarah O’Connor, The Human Cloud: A New World of Work, Financial Times (Oct. 8, 2015). 56 Id.

57  Auriga, Employee Tenure Becomes Hot Topic for Tech Companies (June 15, 2015).

58  See Symantec Corp., What’s Yours Is Mine: How Employees Are Putting Your Intellectual Property at Risk (2013), (citing survey results that 59 percent of U.S. software developers believe that they have the right to reuse source code they’ve written for their next employer, and 42 percent believe that employees should have ownership rights in their inventions)

59 Directive 96/9/EC, European Parliament and of the Council (March 11, 1996).

60  See DLA Piper, Rights in Data Handbook (Jan. 2013) (John Wilks & Alex Christie, Eds.) at p.46.


Warning & Disclaimer: The pages, articles and comments on do not constitute legal advice, nor do they create any attorney-client relationship. The articles published express the personal opinion and views of the author as of the time of publication and should not be attributed to the author’s employer, clients or the sponsors of

Join the Discussion

No comments yet.