Clean Room Development to Prevent the Spread of ‘Infectious IP’
“A correctly implemented clean room development process can reduce the possibility of infection significantly, if not entirely.”
There are often situations where a company has come into contact with intellectual property that it cannot allow to spread to a product in development. One example is a joint development project between two companies where the IP for the jointly developed product cannot seep into other products but where each company must develop products that interface with the jointly developed one. This situation can occur when groups create standards that involve IP from various sources.
Another example is where two parties have a business relationship where each supplies its own product to the other but where one party terminates the relationship in order to design a replacement for the other party’s product.
Yet another example is where one company is found to have misappropriated another’s IP and, after litigation, must redesign its product without any of the misappropriated IP.
I will call the IP at issue “infectious IP” because, like a disease in a human body, it cannot be allowed to spread within the company and certainly not to a new product without first being “vaccinated” with a license agreement. Just as a disease in a human body can lead to illness, the spread of infectious IP in a company can lead to litigation. Ultimately, the point of clean room development is to reduce the potential for litigation.
In this article, I describe the gold standard for clean room development that I have taught for years, the principles of which have been around since at least the first software clean room implemented for such cases as NEC Corp. v. Intel Corp., 10 U.S.P.Q.2d 1177, 1178 (N.D. Cal. 1989), Computer Assocs. Int’l, Inc. v. Altai, Inc., 982 F.2d 693, 701 (2nd Cir. 1992), and Nordstrom Consulting, Inc. v. M & S Techs., Inc., No. 06 C 3234, 2008 WL 623660, at *7–8 (N.D. Ill. Mar. 4, 2008).
There are other ways of preventing contamination than clean room development, just as humans can avoid a disease by simply isolating themselves from infected individuals. Also, clean room development may be impractical or unnecessary in certain situations. And there are always business and legal tradeoffs to consider. However, if you do implement a clean room, this article describes the concepts and best practices for doing so. This first article in this series describes the general protocol. The second article in this series will describe practical implementation.
I. Clean Room Development Protocol
The clean room development protocol is a method for developing a product in such a way that the protected intellectual property (“infectious IP”) does not get transferred to a new product. A clean room is named after a semiconductor manufacturing “clean room” where the manufacturing area is filtered to keep it free of small particles that could contaminate the semiconductor wafers, introducing defects into the integrated circuits that would render them unreliable or unusable. In a similar way, a clean room is kept free of the infectious IP that could contaminate the new product’s development.
The setup for clean room development basically involves three entities: a dirty room, a clean room, and a monitor, as shown in Figure 1. Members of the dirty room, the “dirty personnel,” have knowledge of the infectious IP. Members of the clean room, the “clean personnel,” have never had knowledge of the infectious IP. Monitors are third parties that monitor communications between the dirty room and the clean room.
The protocol is designed so that transfer of the infectious IP to the new product would be extremely small if not impossible and that a reasonable person, such as a judge or jury member, would understand that easily, should the protocol be challenged in court. The protocol is set up so that any violations, while not impossible, would almost certainly be noticed and recorded.
A. The Dirty Room
The dirty room is a place where certain developers have access to all information about an existing product that is (legally) available to them. We will call these developers the “dirty developers.” They can examine these materials, including those that contain the infectious IP, to understand the product’s functionality and how to interface to it. It is ideal that the dirty room be a physical place where access can be monitored and verified, though it may be a virtual place where access is allowed remotely if that access is restricted to dirty developers.
The dirty developers will produce a functional specification for the new product that will be submitted to the monitor for evaluation to make certain that no infectious IP is included in this functional specification.
Ideally, all communications coming out of the dirty room must be sent to the monitor for examination before being forwarded to the recipients outside the dirty room. In today’s world, there are so many means of communication and reasons for communication, that it might not be possible to restrict all communications. For example, the dirty developers may need to communicate with the Human Resources Department, coordinate company events, or ask questions of their bosses about their salaries and benefits. If it is not possible to restrict all communications, then at least all communications regarding product development must be sent to the monitor for examination before being forwarded to the recipients outside the dirty room.
Communications into the dirty room need not have any restrictions except that all direct communications from clean developers must be copied to the monitor. If it is absolutely necessary for dirty developers to send communications directly to clean developers about issues unrelated to product development, those communication should be minimized, and communications about development issues must be prohibited.
Developers in both rooms must agree in writing that any inadvertent communication from the dirty room to the clean room about development issues will be immediately reported to the monitor who should examine the communication and verify that no infectious IP was shared. If infectious IP was inadvertently shared, some sort of remediation must occur, the specific of which will depend on the situation.
B. The Clean Room
The clean room is a place where developers have no access to any materials that contain or could possibly contain the infectious IP. This includes any specifications, plans, software code, hardware schematics, or other proprietary materials that were used or could be used to develop the product containing the infectious IP. It is ideal that the clean room be a physical place where access can be monitored and verified, though it may be a virtual place where access is allowed remotely if that access is restricted to clean developers.
In the clean room, developers produce a product that does not contain the infectious IP. People who have knowledge of the infectious IP or have had close contact with the developers of any product containing the infectious IP must not have access to the clean room. If absolutely necessary, access to these materials may be allowed for former employees and independent contractors to of the company that owned or currently owns the infectious IP, but only if it can be reasonably determined that these employees and contractors did not have access to the infectious IP. Essentially, access to the clean room should be denied to anyone who may reasonably be thought to have had access to, or knowledge of, the infectious IP. The goal is to make sure that a reasonable person would not believe that someone in the clean room might have had such access and such knowledge to contaminate the new product.
All communications coming out of the clean room can be sent directly to the dirty room but must also be copied to the monitor so that the monitor has a record of all communications and can flag any that might cause the dirty developers to give a response that includes the infectious IP.
Developers in both rooms must agree in writing that any inadvertent communication from the dirty room to the clean room about development issues will be immediately reported to the monitor who should examine the communication and verify that no infectious IP was shared.
C. The Monitor
The monitor must be a trusted third party, not directly related to the company developing the new product, who verifies that communications between the dirty room and the clean room do not contain any infectious IP. The monitor must have access to all materials in both the dirty room and the clean room. In fact, the monitor must be highly knowledgeable of the infectious IP to be able to detect when infectious IP is being communicated from the dirty room to the clean room and block such communication.
Every communication regarding development from the dirty developers that is intended for the clean developers must be sent to the monitor for approval. If the monitor finds anything that contains the infectious IP, or that could be reasonably construed to contain the infectious IP, the monitor will inform the dirty developers about the specific concern, and the dirty developers will be given a chance to modify the communication to alleviate the concern and resend the communication. If the monitor approves the communication, the monitor will send the communication to the clean room.
The monitor must receive copies of all direct communications from the clean room to the dirty room and keep a record of all communications to flag any that might cause the dirty developers to give a response that includes the infectious IP.
Any inadvertent communication about development issues from the dirty room to the clean room will be reported to the monitor who should examine the communication to verify that no infectious IP was shared. If infectious IP was inadvertently shared, some sort of remediation must occur, if possible.
It is recommended that the monitor also verify that the final product created in the clean room does not contain the infectious IP. This verification can be done manually and/or by using a tool that compares the original product to the new product to determine whether any infection occurred. If such infection occurs, the appropriate steps must be taken to remediate the infection, if possible.
The monitor must be a party that is independent from the company developing the new product and who does not have a stake in whether the new product works or whether it contains the infectious IP. The monitor is often an independent contractor, and the monitor’s payment cannot depend on the success of the product being developed or any other factor relating to the company’s business activities.
There is often a strong desire, for convenience or to minimize expenses, to appoint a “trusted employee” as the monitor. This practice must be avoided as it breaks the fundamental concept of a clean room. The monitor must be trained in the infected IP, which by definition makes the monitor dirty, and thus is further spreading the infectious IP within the company. Also, the monitor must communicate directly with the clean room, which breaks the rule that no dirty personnel can communicate directly with the clean room.
II. No Excuses
As I stated above, each situation is different, and there are other ways of preventing an infection of unwanted IP during product development. Further, a clean room may not be practical in every situation. However, a correctly implemented clean room development process can reduce the possibility of infection significantly, if not entirely. Throughout my career, including as a designer of clean room development processes and as an independent monitor, I have heard some excuses to cut corners that are just not accurate.
I sometimes hear that a clean room process is too difficult or expensive to implement. However, the difficulty or expense must be weighed against the possibility, difficulty, and expense of litigation. If litigation is not a possibility or, for some reason, would not be expensive or inconvenient, then that argument makes sense. In my experience, there is a potential for litigation in most situations, and if it occurs, will be very difficult, inconvenient, and expensive.
I have also heard arguments that corners can be cut in setting up a protocol. Often, I’ve been told, it is too expensive to hire an independent monitor so a “trusted” employee can be used to monitor the clean room development. As I explained above, using a monitor who is not completely independent, or who has the appearance of conflict, will almost certainly not hold up in court. Also, the expense of a monitor, who is simply reviewing communications, is a very small fraction of the expense of the clean room developers and certainly tiny compared to that of the lawyers involved in writing contracts, supervising the setup, overseeing the maintenance, and any future litigation.
If you determine that you do not need a clean room, then do not implement one. If you decide to implement one, implement the optimal one that gives you the most protection.
