Image from NegativeSpace

For the last few decades, corporations ranging from startups to large multinationals first turned to utility patents to protect their innovative software. These patents protected everything from the minute details of microprocessor operation (e.g., Intel’s microprocessor power consumption patent) to algorithms for a search engine (e.g.Google/Stanford’s page rank patent) to innovative user interfaces (e.g.,Amazon’s “one-click” patent). In fact, by 2011, patents on software made up more than half of all patents being issued.

The Supreme Court’s June 2014 ruling in Alice v. CLS Bank calls into question the eligibility for patent protection of these issued utility patents on computer software, and is a barrier to future applications on computer software.  Alice and its progeny compel software developers to look beyond patents to protect their intellectual property.  What are these alternatives?  When and how can they be used?

In Alice, the Supreme Court found that an issued patent protecting high frequency trading software was invalid because it was directed to patent ineligible subject matter.  Unfortunately, the Court provided little or no direction as to how to determine patent ineligibility. The Court said that a “patent-ineligible concept” is “an abstract idea.” So the natural next question must be: What is an abstract idea? The Court defined “an abstract idea” as “[a]n idea of itself,” or one that is “a fundamental truth.”

With the issued patent challenged in Alice, the Court used this definition to deem them directed to an “abstract idea” and therefore patent ineligible. But the Court did not explain how the patented claims were “drawn to the abstract idea of intermediated settlement” in the high frequency trading software realm. The Court did not pinpoint what fundamental truth the patents purported to protect such that they were ineligible.

In practice, the Court’s Alice decision boils down to a “you know it when you see it” test. Following the Supreme Court’s decision, district courts have applied this test in a similar manner with devastating effects on issued software patents. The following issued patents were recently found invalid for being directed to patent ineligible subject matter:

• The “Interactive, On-Demand Media and Program Guide” Patents (U.S. Patent Nos.6,898,762; 7,065,709; 7,103,906; 7,945,929; and 7,974,962): These patents were directed to searching, finding, bookmarking, and reviewing media and programs available to users, where users interact with the program to identify media and programs to view and save.
• The “Business Intelligence” Patents (U.S. Patent Nos. 6,859,798; 7,260,577; and7,228,303): These patents covered business intelligence server systems involved in the creation of reports, methods and systems to provide business intelligence web content with reduced client-side processing, and systems and methods for remote manipulation of analytics reports.
• The “Emergency Call Analysis” Patent (U.S. Patent No. 8,447,263): This patent covered a dashboard system, which receives emergency call information such as a 911 call, performs statistical analyses of the calls received, and displays the results of the analyses in a customizable, visual way, organized by geography, type of call, and such.
• The “Flight Jet Motion-Tracking” Patent (U.S. Patent Nos. 6,474,159): The patent described and claimed systems for using inertial trackers to track motion relative to a moving platform instead of relative to the Earth. This approach disclosed allows the benefits of inertially-based motion tracking to be realized on moving platforms, without the head-tracking accuracy being disturbed by the unpredictable motions of the platform.
• The Cloud Computing/Distributed Processing Patents (U.S. Patent Nos. 8,200,746and 8,341,209): The patents disclosed systems and methods of using a network of multiple actors to efficiently and reliably process information and/or complete a task by breaking down the job into small pieces, each handled by a different actor organized within an internal hierarchy.

With the implementation of Alice and its repercussions, software technology companies can no longer count on utility patents — alone — for protection.

Companies should not abandon their current utility patent filing strategies, as it is unclear how quickly the law may change and utility patents on software and business methods may regain strength. But a comprehensive strategic approach should include using design patents along side copyright, and trade secret protections.

Additional intellectual property protections will make it more difficult for a company’s competitor to directly copy the substantial research and development efforts traditionally described in issued patents or published applications directed to software or business methods.

So what can a technology company do to protect its software?

Most companies did not rely heavily on these other protections before because their reach was more limited when compared to utility patent protection. The shift in eligibility requirements for utility patents, however, requires companies now to consider other protections for software technology such as design patents, copyrights, and trade secrets.

1. Design Patent: Design patents differ from what we regularly refer to as a patent. Patent usually refers to a “utility patent,” which software companies can no longer rely on for protection as discussed above. A design patent refers to legal protection granted to the ornamental design of a functional item. Design patents do not need to satisfy the patentability requirement discussed above.
2. Copyright: Copyright is a right granting a creator of an original work exclusive rights to its use and distribution for a limited time. Unlike patents, these exclusive rights are not absolute. For example, the fair use doctrine is an exception in copyright law that allows use of copyrighted material for limited “transformative” purposes, such as to comment upon, criticize, and or parody a copyrighted work.
3. Trade secret: Trade secret protection can be sought for a formula, practice, process, design, instrument, pattern, commercial method or compilation of information. A trade secret is (1) information; (2) reasonable measures taken to protect the information; and (3) which derives independent economic value from not being publicly known. Trade secret laws do vary by state, but the three defining characteristics are generally consistent.

So how does one apply these IP protections to the software space?

To apply these distinct legal protections to software, it is helpful to break down the software stack into layers: (1) user interface and experience; (2) application programming interfaces (APIs) and action layers; (3) data modeling and business logic; and (4) server/network/hosting environment.

The first layer, the user interface and experience, is the front end that most consumers will encounter. It is part branding, part look and feel, and part functionality. This layer can be protected by design patents.

The next layer, an API or action layer, allows the outside world to communicate with the complex software that is being created. APIs are shortcuts that allow programmers to use pre-written code and libraries to build functionality into their programs without writing all of the code from scratch. Allowing software developers access to certain APIs has become commonplace. This layer can be protected by copyright.

The last two layers are at the heart of any software — those layers include the big ideas that require the most attention and are complex, like algorithms, and data models. These layers can be protected as trade secrets.

Design patents can protect the user interface layer

Design patents are an increasingly important intellectual property protection available to technology companies. Design patents do not have the same eligibility requirements as utility patents and they do not protect functionality, but they can protect the user interface and experience. Design patents are only granted for novel, and not obvious, designs. To be eligible for this protection, the ornamental design aspects must have function, but the design cannot be dictated by the function.

One well-known company has amassed design patents covering its user interface and its hardware design. In fact, the company’s success in litigation against its largest competitor can be attributed in large part to its design patents. Can you guess what company this is? (Hint: It’s a red fruit that keeps the doctor away.)

Apple most recently used two design patents as ammunition in its litigation against Samsung. In Apple v. Samsung patent dispute, Apple alleged that Samsung infringed a number of patents, including a design patent (U.S. Patent No. D627,790 or the ‘D790 Patent) that protected the look of Apple’s iOS user interface on an iPhone.

Here is a photo of the design that was protected and the allegedly infringing Samsung device:

To determine infringement of a design patent, it’s only necessary to compare the solid lines. The dotted lines don’t count. Here is an example:

This means that the fewer solid lines in a design patent, or conversely, the more broken lines in a design patent, the stronger the patent.

Here is a closer look at Apple’s design patent image:

Based on design patent principles, Apple chose to protect the look and layout of its rounded user interface icons and layout, but not any other features in its design. Apple is especially aggressive in its pursuit of user interface design patents, as are other technology giants.

Here are other examples of user interface patents:

Apple’s design patent (left) protects a user interface with a bottom row of four icons. Other than the number of icons on the bottom row, everything else — including the shape of the icons in the bottom row — is drawn in dashed lines.

 

 

 

 

 

 

Facebook’s “status update” user interface design patent (left) uses dashed lines for the computer monitor and all of the text and certain icons and buttons. Only the solid lines show the protected portion of the Facebook’s status update interface.

 

 

 

 

 

 

Google’s landing page design patent protects its simple look. If someone used the layout but replaced “Google,” the patent would be infringed. Note the bottom of the figure is marked with a circle-c ©. That indicates that Google is also claiming copyright protection for this layout.

 

 

 

 

A software application’s success can depend on user design and experience, so protecting a company’s design choices using design patents is important.

Additionally, with the changes in patent law, specifically, the ineligibility of software to be protected by utility patents, it is crucial that companies protect their novel user facing designs.

Copyright can protect the API and action layer

Another protection available for software companies is copyright. And, it was recently confirmed that APIs can be protected by copyright law, thanks to the Oracle v. Google dispute. The copyright infringement allegations in that case revolved around a widely known set of APIs — Java APIs.

Sun Microsystems originally developed Java in 1991, a programming language, a virtual machine, and a set of libraries for use with the language. When Google released the Android operating system in 2007, it noted that it would use some Java technologies. Indeed, Google and Sun negotiated about a possible partnership, but no agreement was reached. In early 2010, Oracle purchased Sun and continued to develop Java. Oracle and Google also discussed a possible licensing deal, but never reached an agreement.

Later that year, Oracle sued Google for copyright infringement of the structure, sequence and organization of certain Java APIs and the API documentation used in Android. Below is an example of a Java API presented at trial, showing that the structure and class names are identical:

Google did not deny copying, but rather argued that it should be allowed to copy such small amounts of code. After being presented with the evidence, in 2012, a jury found that the API was infringed under copyright laws and rejected Google’s defenses of de minimus copying and fair use.

The judge set aside the jury verdict, however, by ruling that APIs were not eligible for copyright protection as a matter of law and were functional “methods of operation” that didn’t warrant copyright protection. Oracle appealed the ruling and last year, the Federal Circuit reversed and found the particular way of naming and organizing the APIs was copyrightable. In June of this year, the Supreme Court chose not to revisit the Federal Circuit’s ruling.

The takeaway is that copyright law can protect the structure, sequence and organization of APIs.

To protect an API, both the API and the API’s documentation must be publicly disclosed and registered with the Copyright Office. Note, this would only protect the API disclosed, and not a particular implementation or source code using the API.

To decide what to protect using copyright law, a company should consider that the copyright statute requires public disclosure. Given that requirement, a company may choose to seek copyright protection on APIs that can be reverse engineered easily, or those that will be publicly disclosed for interoperability reasons.

An additional consideration of what to protect by copyright is whether the fair use doctrine applies to APIs. The fair use doctrine is a legal doctrine that promotes freedom of expression by permitting the unlicensed use of copyright-protected works in certain circumstances.

In the Oracle v. Google saga, the Federal Circuit has remanded the case to the district court where the question of whether Google’s use of Java APIs were fair use will be decided. Before the Supreme Court decided not to review the case, the U.S. Solicitor General recognized that Google was entitled to a fair use defense in an amicus curiae brief:

“. . .[I]it is the function of the fair-use doctrine . . . to identify circumstances in which the unauthorized use of copyrighted material will promote rather than disserve the purposes of the copyright laws.”

Using copyright to protect source code (e.g. the implementation of APIs) is disfavored. As discussed above, copyright protection requires public disclosure of the material. Unlike APIs, the source code implementations are more complex and include information that a company may want to keep confidential. As a rule of thumb, copyright is not the right tool to protect all of the implementations of the APIs, or the source code files themselves.

Trade secret law can protect the remaining layers

The last type of protection, trade secret, can be referred to as a “catch-all” for that which you want to protect. Why trade secret? Because the intellectual property stays confidential and secret. This protection is particularly relevant to the last two layers of software: data modeling and business logic, and server/network/hosting environment because it represents models and algorithms developed by your company to effectively provide a service — whether it is data modeling to produce output to your users, or internal algorithms that allow your company to scale.

Technology companies with strong trade secret policies may actually be better protected than those technology companies that have a collection of utility patents, but few trade secrets. Utility patents expire after a certain time, and once they expire everything in the patent is free for the taking; trade secrets continue in perpetuity.

For example, the formula for Coca-Cola is over almost a century old (likely, the world’s most famous trade secret). Had Coca-Cola decided to patent its formula instead, the patent would have expired decades ago and the company would not be the giant it is today. Technology companies are no different. Google’s longevity (or Alphabet’s), in part, will be measured by how well it can keep secret its evolving search algorithm.

Unlike patents, trade secrets become effective immediately and do not require upfront fees associated with acquiring a patent. Filing for a patent, for example, requires an attorney or patent agent to draft a patent with detail so that an expert can understand how the invention is made and how it should be used.

Although trade secrets have fewer requirements, these requirements must be met for the trade secret to remain protected. To qualify as a trade secret, the protected information must have economic value and must be kept confidential. If the information is ever disclosed publicly, trade secret protection can be lost forever. Thus, keeping information confidential requires ongoing measures to be in place.

Access Granted! Check out the Vault where the secret formula for @CocaCola is secured. http://t.co/MH04fZopnR pic.twitter.com/TrFU5bX2Qy

— World of Coca-Cola (@WorldofCocaCola) July 9, 2015

Some companies, like Coca-Cola, employ extreme ongoing measures to protect the trade secret formula. We know that Coca-Cola does at least the following: (1) locks the formula in a vault at its headquarters, (moved from a bank vault where the formula resided for 86 years); (2) only two Coca-Cola senior executives ever know of the formula at the same time; and (3) the two executives identities are never disclosed to the public, nor can they fly on the same airplane at the same time.

These extraordinary trade secret protection measures are seldom necessary. It is, however, very important that access to the protected information be restricted to a limited number of persons, and that these people sign a non-disclosure agreement, or commonly referred to as an NDA. Such protection measures allow one to establish that reasonable precautions were taken to prevent disclosure of the secret information.

Courts repeatedly reiterate that the use of NDAs is the most important way to maintain the secrecy of confidential information.

Apart from NDAs, a company should have other reasonable precautions to protect trade secret information in place. Trade secrets are governed by state law, which can vary as to confidentiality requirements, but certain precautions such compartmentalizing information, applying physical (lock and key), applying computer security, and enforcement actions against leakers of information, are universal.

A company may employ simple ways to establish and strengthen trade secret protection for their software:

1. Use access control on your source code repositories. The majority of software developers (if not all) need access only to specific portions of a company’s source code. Giving developers only access to limited portions of the source code significantly reduces the exposure with respect to inadvertent disclosure or disclosure by a single rogue employee. A competitor can no longer hire away one person with access to everything.
2. Create and maintain a strong document retention policy. This is for all documents — from emails to bug reports to source code archives. The policy should limit the time that the documents remain “live” on employees laptops and mobile devices. The less trade secret that is out in the world, the more secret it remains.
3. Create and require employees to sign an IP policy. Any technology company should have an IP (intellectual property) policy that includes a discussion of its trade secrets and confidentiality measures. The company should have all of its employees that have access to trade secrets sign it. As a rule of thumb, however, it is generally easier for a company to just have all of its employees sign such a policy. The policy can include letting employees know that the company will track their use of the company’s servers and collect forensics to confirm that the employees are not divulging anything that relates to trade secrets and intellectual property.
4. Exit interviews that reiterate the IP policy. The turnover at technology companies can be high, so exit interviews are generally a tool for the companies to protect the information an employee may be trying to leave with. Make sure exit interviews require a departing employee to confirm that she is not violating the IP policy. This can serve as a helpful reminder as to the proper procedures.
5. Anti-compete clauses may be helpful in some states. Anti-compete clauses cannot be used in all states. For example, anti-compete clauses are not enforceable in California — an employee who wants to leave to go work for a competitor can do so, even if she has signed an employment agreement that includes an anti-compete clause. In states like these, the four ways to protect your trade secrets discussed above are especially necessary. In other states, like Massachusetts, a company can add an anti-compete clause to assist in protecting information it hopes to protect as a trade secret.

Despite being a “catch-all” protection, trade secret laws are not perfect.

In the last few years, the saga of a software developer working on high frequency trading system for Goldman Sachs has provided some insight of the failures and loop holes in trade secret laws.

An high frequency trading system uses networked computers to perform complex algorithms that transact orders at high rates of speed. Goldman’s system was a closely guarded trade secret, and the developer was employed under strict confidentiality obligations. Further, the developer was the highest paid of the 25 programmers in the software development group at $400,000.

In late April or early May, 2009, the developer resigned and accepted a position as a computer programmer at another high frequency trading firm, Teza Technologies LLC, in Chicago, at an annual salary of $1.2 million.

The developer was twice arrested under criminal charges and twice convicted (of theft of trade secrets and transportation of stolen property in the first case and of unlawful use of secret scientific material in the second), but each conviction was overturned at the appellate level. One appellate court noted the following in its decision:

“The demands of the digital age will doubtless require further refinement of our criminal laws. But it is the job of the courts to apply the laws that exist.”

New York v. Aleynikov, 04447–2012, New York State Supreme Court, New York County (Manhattan) (July 6, 2015) (overturning the New York state court conviction and dismissing the indictment). Additional details about this case and other trade secret cases here and here.

Given trade secret laws cannot always address evolving technology, it is possible utility patents on software may be better in the long run, particularly if the patent landscape does change. For now, simultaneously pursuing all of these protections, including utility patents, may be a technology company’s best bet.

Mansi H. Shah is an IP litigator with a computer science background and a partner at Valorem Law Group in Northern California. She is the immediate past president of SABA North America. Follow her on Twitter at @mansiesq.

Edited by Wendy McGuire Coats.

First published on Aug. 28, 2015 in STARTUPS+WANDERLUST+LIFE HACKING as Is Your Code Protected?