Patenting Software Technology in the current patent environment

newspaperA brief recent history of patenting software in the United States goes something like this:  before 1998 it was possible, but the internet was just coming to its own so there were not many software patents; then in 1998 the State Street decision was handed down.  The State Street decision essentially said that patents that claimed inventions for methods and processes traditionally accomplished using manual techniques but now accomplished using a computer process or method such as spreadsheets, financial calculations etc could be valid – that is, they were at least within patent subject matter and not merely laws of nature. In the ensuing years before the run up to the turn of the century “everything under the sun” in software and internet technology was sought to be patented, and hundreds of thousands of “software” patents were issued.  The crash of 2000 wiped out a lot of marginal internet businesses, however software patenting continued in earnest under State Street.   Thanks in part to the combination of the huge number of software patents issued and the bankruptcy of a lot of companies after the financial crashes of 2000 and 2007, a new industry was born – the so called “patent troll” or in our parlance, non practicing entity (NPE) or patent assertion entity (PAE).  Whatever you call it, the business model is to sue companies that use what most of us consider to be “basic building blocks” technology in those patents.  Economically patent suits are staggeringly expensive so many companies, including many of our clients, opted to pay -or colloquially – feed the troll – it just made more economic sense.  However, slowly bigger companies started fighting back. What was born from that unholy (or holy, depending on your view) war was  a series of Supreme Court cases, starting with In Re Bilski, and finishing on the Alice Corp decision.

Alice Corp literally laid waste to nearly every software/internet patent in its path.  Alice Corp’s impact can be seen in the somewhat dramatic reduction of patent filings since it issued (see 2015 Patent Litigation Study) – some people have just given up trying…  Recently, however, a Federal Circuit decision has given some hope in overcoming Alice Corp.

In Enfish v Microsoft the Federal Circuit found that certain database technology process described in the patent was not abstract – that is, that the invention overcame the first prong of the 2 part Alice Corp test.  Under Alice Corp and the previous decision in Mayo Collaborative Services v. Prometheus Laboratories, Inc. “First, we determine whether the claims at issue are directed to one of those patent-ineligible concepts. [] If so, we then ask, “[w]hat else is there in the claims before us?” [] To answer that question, we consider the elements of each claim both individually and “as an ordered combination” to determine whether the additional elements “transform the nature of the claim” into a patent-eligible application.” The first prong of the test is known as the “abstract idea” prong, meant to embody “the longstanding rule that ‘[a]n idea of itself is not patentable.”  So, for example “an algorithm for converting binary-coded decimal numerals into pure binary form” was merely abstract because it sought to “in practical effect . . . [] patent [] the algorithm itself.” Likewise, “a method for hedging against the financial risk of price fluctuations” was unpatentable because “”the basic concept of hedging, or protecting against risk. [is] a fundamental economic practice long prevalent in our system of commerce and taught in any introductory finance class.'”  The addition of the computer did not transform the idea of hedging into anything inventive.  Most cases that find prong 1 of the test go on to find that whatever the system or process that is claimed in the patent is, it is not sufficiently transformative to overcome the 2nd prong.   

In Enfish, the Federal Circuit held that the database technology described in the claim was not abstract.  The specific technology deals with a better method of handling related database data.  In a traditional relational database, an information source is stored in one table, another information source is stored in another table, and the relationship between those tables is either defined in columns on each table, or held in a third “pivot” table that defines the foreign table keys that link the tables together.  The invention in Enfish involved placing all of the related data in ONE table, and defining the relationships in table columns in that same table.  The effect of doing that was to make the process of retrieving related data faster and more efficient, among other benefits.  This invention thus directly impacted computer process efficiency – in this case, database efficiency.  The Federal Circuit held that “the first step in the Alice inquiry in this case asks whether the focus of the claims is on the specific asserted improvement in computer capabilities (i.e., the self-referential table for a computer database) or, instead, on a process that qualifies as an “abstract idea” for which computers are invoked merely as a tool. . . [a]ccordingly, we find that the claims at issue in this appeal are not directed to an abstract idea within the meaning of Alice. Rather, they are directed to a specific improvement to the way computers operate, embodied in the self-referential table.”

The patent lawyers at Oliver & Grimsley have overcome Alice Corp rejections in several instances, and have learned to navigate the intricacies of obtaining patent protection over computer based technology.  In a series of future articles we will go over some of the issued patents we have been counsel on and some of the issues that come up during prosecution of software and computer based patents.

For further information, feel free to contact Mike Oliver, Larry Guffey or Pamela Riewerts.   You can view many of our prosecuted patents here.

The Four Most Common Mistakes Made In Hiring a Website Developer

We meet a lot of clients that fail to obtain a written agreement, or blindly sign the form provided by the developer – and when a dispute arises, only too late realize the problems created by that lack of diligence.  This post addresses critical provisions in a website development agreement.

First, you want to make sure you will own the material and content created by the developer.  Thus, you want a provision in the agreement (which must be in writing) that recognizes that the developer’s work for you is considered a “work made for hire” and you want a copyright and intellectual property assignment as well.  These clauses ensure that, although the developer is not your employee, you are the owner of the website materials and intellectual property rights.  You do not want to find that your website designer created something unique for you only to discover the same unique layout on another website.  Many businesses are surprised to learn that in the absence of this statement in a written agreement, an independent contractor (in this case the website developer) typically is the owner of work they create, and the business at most would be a licensee of the material. This means you don’t own the work; rather, you only have permission to use it.

Second, you want to have a provision in the contract that states that the work on the website is the website developer’s original work and/or that the developer has the necessary permission/licenses from the owners to use the work on your site.  For instance, the website developer may place photographs on your website – you want the developer to represent that the developer has the right to use those photographs on your website (i.e. either the developer took the photos or it has the permission to use them).  If the developer uses photographs owned by a third party on your website without the third party’s permission, the third party could claim you are infringing on their copyright by displaying their work on your website without their permission, and would demand you cease use of the photos and may demand damages as well.  Thus, have your website developer represent the work is original or that he has permissions to use all work on your website.

Third, make sure to have an indemnification provision in your agreement.  This provision should provide that the developer will indemnify you in the event you incur damages or a loss due to a third party claim that you are infringing their intellectual property rights – where they claim the work on your website is actually their material.  For example, a business thinks the graphics on its site are original, however, it receives a cease and desist letter from a third party alleging that its use of the works on its website without the third party’s authorization is copyright infringement and demands damages.  Under Copyright Law, if the third party is the owner of a registered copyright in the work, the business as an unauthorized user could be subject to statutory damages ranging from $700 to $30,000 for unintentional infringement, and up to $150,000 for willful infringement. Thus, if material placed on your website by your developer is subject to a claim or legal action for infringement, you want your developer to indemnify you for these actions since you are relying on their knowledge, creativity and skill in developing and designing your website.

Finally, it is important that you make sure that the developer periodically delivers all source codes and native files to you, and that you control all passwords and access to critical website assets, such as the domain registration.  You want to make sure that such files and access rights cannot be withheld in the event of a dispute.  Thus, if a dispute arises, the developer’s sole remedy should be money damages.  You should not be prevented from transferring the work done (to the point of a dispute) to a new developer, so you can finish your site, and deal with the dispute separately.

For more information, please contact Kim Grimsley.

In software disputes, don’t send someone armed with Play-doh to a knife fight – GMG Health Systems v Amicas, Inc.

In GMG Health Systems v. Amicas, Inc., 1st Cir April 10, 2012, the court had occasion to address a dispute between a software licensor / developer, and a licensee, in which more typical contractual language was in issue (for example, use of the term “go-live” and the phrase “substantially conform to Documentation” and typical warranty limitations).

GMG is a medical services provider – they typically have several systems to manage their billing, processing and other business functions.  Here, GMG contracted with a third party (Amicas) for its software – which had to interoperate with software from an already existing vendor used by GMG.  Like so many disputes, this one arose because of finger pointing between two vendors as to whose software was causing the error.  As an added twist here, and something we have litigated on at least one occasion here – GMG had decided to leave Amicas and go with another vendor, and was desperately trying to find a way out of the long term agreement.

Normally in such disputes, the licensee (client) makes some effort to produce a viable claim of breach of the agreement by the licensor / software developer.  In this case, however, GMG, which had not negotiated the agreement and signed a pre-printed form provided by the software company, produced a sole witness to fight the motion for summary judgment filed by the software developer.  This witness had no IT or software training, was not a project manager, was not familiar with the function of either of the software systems at issue, and could not provide any details beyond that the “interface did not work.”  GMG feebly tried to argue that the merger clause – a clause that states that all prior agreements including verbal understandings between the parties are “merged” into the agreement, did not apply because it had not negotiated the agreement.  The court dismissed that argument without any discussion.

Without the ability to provide evidence of what the parties intended – the so called “seamless integration” with the other system – GMG was unable to overcome the warranty limitation in the agreement, which stated that Amicas did not promise that the software would work for GMG in its environment.  Not surprisingly, GMG lost on all counts . . . and that loss was affirmed on appeal.

What is the moral of the story?

First, negotiate large scale enterprise resource planning agreements! Yes, the negotiation can be expensive, but far, far less than the litigation costs and potential damages.  For example, in the GMG case, it was forced to pay an additional $700,000 for software it had abandoned, it was subject to an attorney fee award, it lost all kinds of time dedicating resources to fight the case, it had to pay its own lawyers, and it ended up taking 5 times as long to reach it s goal (of an integrated system).

Second, even if you do not want to hire a lawyer to negotiate, at least make sure that the party providing the service has stated clearly in the agreement, the deliverable, what it will do, and what you expect from the service.  We have reviewed too many scenarios to count where a client has signed a pre-printed form that had NO promises or very light ones, like this agreement.  If it is a critical result that software X must interoperate with software Y, state that in the agreement.

Third, consider the remedy.  Many contractual negotiations can get hung up on the representations, warranties, disclaimers and so on – when they can be resolved by thinking in the opposite direction – assuming a performance representation is not met, what is the remedy?  Remedies range from the “nuclear” option (total contract termination), to some form of “notice and cure” to a repair, re-perform remedy.

Fourth, consider the term of the agreement.  In the GMG case, the parties amended their agreement and made it a longer term agreement.  Many vendors will offer more significant fee discounts, or less escalation, if the term is longer.  These can be attractive deals – but consider that as with GMG, you may desire to move away from that solution.  So, my rule of thumb on this point is . . . the longer the fixed term of the contract, the more closely you must negotiate it – and the more you must pay attention to escape hatches and “relief valves” if something changes.  Technology changes very fast – locking into a vendor for 5 years (as was done in GMG) is almost unheard of.  A three year deal presents enough technology-change-risk to be the outer limit of most of these deals.

I could go on, but if you made it this far . . . well, thanks!

For more information, contact Mike Oliver.

Recent court decision in Oracle v Google raises serious copyright questions in certain types of software

In a decision in the Oracle v Google case, the court held that APIs – application program interfaces – small amounts of human readable source code, are not sufficiently original to qualify as copyrights.  This decision can impact API licenses, which most likely are based on copyrights.

What Google did.  Google decided that to construct a mobile platform operating system (ultimately, the Android operating system) it wanted to be able to “interoperate” with java programs – in this way, developers could rapidly publish their programs written in Java, to the mobile platform.  In order to do this, however, Google either needed a license to the Java virtual machine to allow it to “port” it to the mobile hardware, or it needed to emulate that environment.  Google approached Sun (later bought by Oracle) for this license, but the parties never agreed.  Google eventually copied the names of the base classes and methods, and wrote its own original code to implement the particular functions.  So as an example, a Java program would call a function, using the precise identical name of the function, class or method, but the “behind the scenes” black box code in Android that returned a result, was written by Google and not copied from Java.  Google did a few other things (for example, they decompiled some executable code in Java, and used the source code derived from that to test their own software compatibility, and they included verbatim 9 lines of code in a range check function, which the court utterly dismissed as De-minimis copying)

What Oracle claimed.  Faced with having examined 15 million lines of code and discovering that only the structure, sequence and function was copied, Oracle took the position that it had a copyright in that structure, function and sequence.

What the court held.  The parties had agreed that the issue of copyright was for the court to decide, with the jury being the arbiter of any infringement or damages.  The court did a very good job of reviewing the history of protection of computer software – which really started in about 1980, with amendments to the Copyright Act that recognized computer software as a literary work.  (this case is very well written and researched, so I can commend it to anyone who wants a crash course in software law)

The trouble with the copyright protection, however, is that copyrights cannot protect ideas – that is the exclusive domain of patent law.  So, whenever a copyright expresses an idea, we often say that the idea is free but the expression of it may not be.  However, where there is only a limited way of expressing the idea – courts hold that the idea then “merges” into the expression, becoming inseparable, and renders that particular expression free from copyright protection.   That is what the court held here – essentially, the court said that if you want to protect the sequence, function and structure of how a software program works, you must use patent, and not copyright, law.  This ended the case for Oracle, as Oracle had lost on patent infringement.

The court summarized the best argument as follows: “Oracle’s best argument, therefore, is that while no single name is copyrightable, Java’s overall system of organized names — covering 37 packages, with over six hundred classes, with over six thousand methods — is a “taxonomy” and, therefore, copyrightable under American Dental Association v. Delta Dental Plans Association, 126 F.3d 977 (7th Cir. 1997).” (emphasis added)

What impact does this case have?   In the abstract, this case follows a fairly well defined line of cases that have denied copyright protection to such things as menu structures and programmatic access to underlying operating systems.   In this regard, the case does not change the law.  However, in a bigger picture view, and with particular reference to the amount of copying here – all of the main class and method calls in Java were replicated verbatim . . . it could be seen as a step toward requiring either very good contracting practice, or patenting, to protect access to a software language system.   The only other way to protect access is under the Digital Millennium Copyright Act – installing and using a sufficient technological measure that must be decrypted in order to access content.

If a software developer desires to restrict access to base operating code, the Oracle v Google case poses a significant barrier to reliance on copyright alone.  As stated above, the developer should consider proper contract language, patenting the system, and use of encryption technology to unlock such access.

For more information contact Mike Oliver.