Guest Post: Secret Software Sales

Guest post by Matthew Fagan, Principal at KDP where he handles patent matters.  Much of the post-Helsinn analysis has focused on its impact on pharma where substantial strategic pre-filing activity is the norm. I asked Mr. Fagan to come at the problem from the computer and software perspective.  – DC

= = = = 

When the Federal Circuit decided Helsinn v. Teva last month, the patent world expected to the Court to resolve an issue simmering since 2011: namely, do purely private, secret sales toll the on-sale bar of post-AIA §102?  The court declined to provide an answer, instead reframing Helsinn’s activity as a public sale in which the details of the invention were not publicly disclosed.

Practitioners may be inclined to dismiss Helsinn as a judicial dodge in which the Court avoided the more interesting “secret sales” question.  But the issue the case turned on may ultimately be of more significance.  Cases of purely private sales are relatively rare as compared to public sales in which the details of an underlying technology are not fully disclosed or are actively hidden – especially in the software industry.

When combined with the Federal Circuit’s 2010 decision in Finjan v. Secure Computing and its 2006 decision in Plumtree Software v. Datamize, the Helsinn case raises interesting questions about how developers release software products.  There are several techniques available for distributing software to customers; after these cases, the date on which patented software is “sold” to the public may vary depending on the distribution method.  In fact, a patent directed to a single algorithm might have two different on-sale dates arising from the same transaction.

Most software patent claims are constructed as method claims or medium/apparatus claims.  In a computer-implemented method, a computing device performs a series of steps in an algorithm.  Plumtree offered two scenarios under which a computer-implemented method would be placed on sale: first, if the patentee “made a commercial offer to perform the patented method (even if the performance itself occurred after the critical date);” second, if the patentee “in fact performed the patented method for a promise of future compensation.

In medium claims, computer code is embedded in a computer-readable medium or implemented in an apparatus.  Finjan stands for the proposition that, because medium claims are directed to the device storing code rather than the actions embodied in the code, they do not necessarily require performance of a patented algorithm for infringement.  Any medium storing the instructions can infringe (or anticipate) a medium claim regardless of whether the claimed steps are actually performed.

What Helsinn adds to this line of cases is the concept that a sale of a medium holding an algorithm, or a performance of a method embodying the algorithm, will trigger the on-sale bar even if the invention is not discernible to the end-user.

Helsinn could be problematic for software developers using typical software development methods.  For example, one common software engineering strategy is the “continuous release” technique, whereby a publisher releases software and then rolls out updates repeatedly over short intervals (e.g., every two weeks).

Because the cycle is so rapid, oftentimes new features are partially developed but not ready for release by the time that the next update is due.  Accordingly, some developers use feature toggles or feature flags, like the following:

if(version == “test”)

              <implement new feature>

if(version == “release”)

              <implement old feature>

This allows the developer to control which version of the code is available to the public by changing the “version” variable: if set to “test,” the new features are enabled for use by programmers; if set to “release,” the old feature becomes active to avoid exposing undeveloped features to the end user.  When the new feature is tested and ready, the programmer can copy the code to the release section and the next version of the code can be implemented in the test section.  This technique is currently used by Netflix, Gmail, Reddit, Flickr, and Etsy, among others.

The critical observation is that, although the new feature will not be performed in the version of the software released to the public, the released software may include both the old version of the feature and an inaccessible copy of the code for the new version.  Even though users may not be able to invoke the test code, Helsinn does not require “that members of the public be aware that the product sold actually embodies the claimed invention.”  Consequently, under Finjan the on-sale bar may be triggered for a medium claim.

In contrast, under Plumtree this scenario may not implicate a corresponding method claim.  Assuming the public was not informed of the new features, there was likely no promise to perform the method in the future.  The method may not be considered sold until the code for the new feature is moved to the “release” section and performed by the user base.

Therefore, although the release might not immediately trigger the on-sale bar for a patented method arising out of the test code, it might trigger the on-sale bar for a patented medium.

Other software distribution methods raise similar risks.  One recent trend in software engineering is to leave software in an open- or limited-beta test for an extended period.  The beta may be offered at a reduced cost as compared to the full-release version (a similar trend has more recently been labeled as “early access”).  For example, Gmail remained in limited beta for five years before being identified as “released;” the popular simulation game Kerbal Space Program was in beta for nearly four.  The beta software might include under-development code callable only by developers, which is interspersed with active code invokable by end users.  If the developer-only portion of the code includes patentable technology, then beta users may unwittingly receive a medium embodying a patentable invention even though the corresponding method is not publicly performed.

Similarly, a normal software update cycle may incorporate “code freezes,” after which programmers are instructed not to modify certain portions of the source code.   When a code freeze is called, unfinished patentable features may become stranded in the source code; these unfinished features may be flagged for inclusion in a future patch or update.  Although not used in the released version, inactive features embodied in the source code could trigger the on-sale bar for the medium holding the code.

To some extent, this problem can be alleviated with optimizing compilers that remove dead or unreachable code.  However, such optimizations take time that developers of large, complex programs may not wish to spend.  Moreover, dead code elimination is primarily used to reduce the size of a deployed program and hence might not be prioritized by developers of code deployed on servers where storage space is readily available.

These release techniques could hurt a patentee’s chances to secure a medium claim, while still possibly rendering method claims patentable.  Another release scenario called “pre-patching” implicates the opposite combination: method claims may be placed on sale while medium claims might remain protectable.

Pre-patching is typically used when software developers provide client software that works with a back-end server.  On the software’s release date, the back-end server is activated and the client can access the server’s services.  Sometimes, if the client software is particularly large, developers may allow the end-users to purchase and download the client before the release date, even though the client will not be able to immediately access features on the server.  This technique is employed for complex online games such as World of Warcraft to avoid swamping download servers on release day.

In this case, patentable activities may be performed on the server, or through a combination of actions by the client and server.  Whether the server’s software was “sold” remains ambiguous in light of the Federal Circuit’s analysis in Minton v. National Association of Securities Dealers.  Consequently, there remains a chance that the on-sale bar is not triggered for medium claims directed to software partially or entirely stored on the server.

On the other hand, it seems clear that a sale of pre-patched software in which a patentable method is performed on the server constitutes a promise to perform the patentable method when the server code is unlocked, falling under the first “on-sale” scenario of Plumtree.  Consequently, the on-sale bar is likely triggered with respect to method claims even though the user base may not be aware that the method will be performed by the server.

In each of these release scenarios, the technology remains locked in unused or inaccessible software code prior to an official release.  Helsinn makes it clear that hiding away patentable features will not prevent the on-sale bar from being triggered in these situations.  Avoiding the on-sale bar may require that programmers be aware of these issues and take special care to remove test features from the release version of the software.

Although the situations described above specifically relate to software development, there are myriad examples from other industries in which an invention is sold without disclosing implementation details.  Thus, although Helsinn does not tell us whether purely secret sales will be patent invalidating, the case may ultimately have a greater impact than whichever dispute ultimately decides the private sales issue.