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.

 

 

32 thoughts on “Guest Post: Secret Software Sales

  1. 10

    The post states “These release techniques could hurt a patentee’s chances to secure a medium claim, while still possibly rendering method claims patentable.” I think the secret sale prior art would tend to hurt the claims regardless of whether the claims are to a method or a medium. The issue is that while only the method or medium claims may have been anticipated (as the post explained) the secret sale is prior art under pre-aia 102(b) and present 102(a)(1), both of which are available for an obviousness combination (as opposed to prior art in a patent application that was commonly owned).

  2. 9

    Yawn. You’re talking a difference of what, a few weeks? A couple months at most? Meanwhile if the code for a patent-eligible feature is included in a distributed version of the software, then the invention is already reduced to practice. What are you waiting for? File your patent application already!

    I can see this being a bigger issue in countries without a grace period. In the US? Not so much. Of course clients will wait until the last minute to seek protection and make it their attorney’s problem, who will look for creative ways to pushback on the on-sale bar rules. But the client has no one to blame but themselves. The system shouldn’t reward procrastination.

    1. 9.1

      KnowBuddy,

      You “Yawn” at the difference in time and then turn around and complain about “reward”…?

      You want it both ways here too?

      1. 9.1.1

        I don’t follow. What are you trying to say? I’m not complaining about any rewards. I’m saying the system is designed properly to reward diligent behavior. Changing the outcome of Helsinn would go against that.

        1. 9.1.1.1

          Changing the outcome of Helsinn would NOT go against what Congress has dictated.

          Congress (in the AIA) set forth that “new to you” is all the “new” that is needed.

          And if you don’t get why led in with a deprecating “yawn,” then why did you do so?

          1. 9.1.1.1.1

            Changing the outcome of Helsinn would NOT go against what Congress has dictated.

            I never said it would. Regardless, I don’t want to change Helsinn. Helsinn is just fine and dandy.

            Congress (in the AIA) set forth that “new to you” is all the “new” that is needed.

            Where exactly does it say that? The statute pretty clearly says the opposite to my eyes. What is your reasoning?

            35 U.S. Code § 102
            (a)Novelty; Prior Art.—A person shall be entitled to a patent unless –
            (1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention;

            I yawn because this post contained nothing of interest to me. It seems like a simple issue with a simple solution: file quicker. Don’t wait til month 11 and realize your bar date is actually two months earlier than you thought.

            I’m sure practitioners will still bump into this issue thanks to demanding clients with unreasonable expectations. In the real world, many clients wait til the 11th hour. That’s a real problem, but one which has little to do with the legal system. We should not cater to such behavior.

            1. 9.1.1.1.1.1

              Changing the outcome of Helsinn would go against that.

              contrast with:

              Changing the outcome of Helsinn would NOT go against what Congress has dictated.

              I never said it would

              plus

              I yawn because this post contained nothing of interest to me.” so the point being made was minimized by you, and yet, you had enough interest to immediately turn around and try to make the opposite point…..

              Are you really that clue1ess as to how contradictory you are?

  3. 8

    I’ve been avoiding the comments here for years due to MM’s a55h013ry, but figured this post would trigger him, and I had to check. Yep, MM is triggered. Ha ha.

  4. 7

    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

    LOLOLOLOLOLOLOLOLOLOLOLOL

    I wonder why the “cycle is so rapid”? I thought writing instructions for comp00 ters was, like, s00per d00per techn0. It’s so hard and dangerous that nobody wants to do it unless they get a zillion dollars first. That’s why the patents are needed, right? Otherwise we end up like the Amish.

    Maybe the software patent club’s script needs some adjusting. Or maybe it was always just a huge deep pile of b.s.

    1. 7.1

      No. Software is super duper obvious, as you have told us many times. You have even told us that software to do any function is inherent in the mere existence of a computing device.

      1. 7.1.1

        Software is super duper obvious

        Most of it is. That would explain the super rapid “cycle” of development and “continuous release” of “upgrades”, wouldn’t it?

        But go ahead and tell everyone how incredibly difficult is to “conceive” of a “new” meaning for data (i.e., “wherein data is [species] data”) or to add another “if then” logical step to a series. S00per d00per hard! Like rocket science, except without the rocket and without the science.

        You have even told us that software to do any function is inherent in the mere existence of a computing device.

        No, I never told you that. I did tell you that programmable digital computers exist to be programmed to carry out logic instructions, and I did tell you that the computer doesn’t care about what the data “means” to humans.

        I told you that for two reasons: (1) true and (2) you lack the integrity and intelligence to say so yourself.

        1. 7.1.1.1

          ” That would explain the super rapid “cycle” of development and “continuous release” of “upgrades”, wouldn’t it? ”

          No. The”continuous release” of “upgrades” is clear evidence that software is not obvious. If it were, it would be perfect with the first release, and there would be no need for patches, fixes and updates.

          1. 7.1.1.1.1

            The”continuous release” of “upgrades” is clear evidence that software is not obvious. If it were, it would be perfect with the first release,

            LOL

            Oh, this just keeps getting better and better all the time.

            Let’s be clear: there is a rapid cycle for bug fixes and “upgrades”. And they all deserve patents, even though they are buggy and immediately obsolete.

            Sure, that makes tons of sense. Let’s melt down the patent system with a zillion piles of scrivened “do it on a computer” junk because some Silly Con Valley bros need “angels” to pay for their sports cars. And then let’s shreek and cry like babies when anyone tries to take the grift away. What could go wrong?

            1. 7.1.1.1.1.2

              I don’t think I said that. I said, it shows that it is not obvious to get to the method “ready for patenting”.

        2. 7.1.1.2

          ” I never told you that. I did tell you that programmable digital computers exist to be programmed to carry out logic instructions, ”

          Yes, that is the preamble or post script to your assertion that whatever computer implemented method being discussed is obvious and inherently available in the mere existence of a computing device and that combining a computing device with instructions that implement an new method dose not make a new machine because the machine could always do “that” even though it didn’t know how to do it and couldn’t actually do it before the combination with the new instructions because it could always had the inherent ability to do it, it just chose not to.

          1. 7.1.1.2.1

            Les,

            Malcolm stays as far away from the proper patent doctrine of inherency as he can.

            We’ve been over this.

        3. 7.1.1.3

          ” I never told you that. I did tell you that programmable digital computers exist to be programmed to carry out logic instructions, ”

          Ah yes, the Big Box of Protons, Neutrons, and Electrons mindset.

          (But shhhh – let’s pretend that we don’t understand that – 😉 )

      2. 7.1.2

        And just to be clear, snowflake, I’m not suggesting that some programmers aren’t skilled at what they do, or that no training is required.

        I am suggesting that writing instructions for computers doesn’t belong anywhere near the patent system.

        And I’m telling you that every skilled programmer with half a brain who I’ve talked to about this subject ends up agreeing with me once they understand the issues. The ones who don’t agree are invariably the types who are invested in bilking money out of people who are even less intelligent than they are.

        [shrugs]

        1. 7.1.2.1

          Ya know, not everyone who nods their head and says “Yeah, yeah, uh hu” and stops talking and walks away is “ending up agreeing with” you. Some of them are just trying to get away.

            1. 7.1.2.1.1.1

              Shrug, he said he talks to programmers with half a brain, so I figured I better be generous.

  5. 6

    If, years after the filing date, the claimed “innovation” in logic “on a computer” is reduced to practice on just one operating system because of numerous bugs that arise when the program is run on other operating systems, what claim scope is the “innovator” fairly entitled to?

    What if I, as a customer, identify the bug and, before I reply to the developer about the problem, I immediately file a patent claim that functionally describes the solution to the bug (e.g., “wherein said result is achieved without [describe features of bug]”? Can I sue the software “developer” when the bug is fixed?

    This is fun. And easy. Who knew? LOLOLOL

  6. 5

    Most software patent claims are constructed as method claims or medium/apparatus claims.

    LOL

    Why is that? Why not just claim “Instructions for a computer, comprising”… What’s the problem with that?

    a computing device performs a series of steps in an algorithm.

    That’s fascinating. Can you give me an example? Oh wait you already did.

    if(version == “test”)

    Ah, so it’s logic.

    Thanks for the wonderful admissions here! It’s refreshing to run into a professional who doesn’t hide the ball like the tr 0lls here insist on doing.

    1. 5.1

      You see “admissions” where none exist.

      How is your project to copyright logic coming along?

      What do your (lemming) programmers say about copyright? Do they feel that they should be paid for anything that they do?

  7. 4

    When a bug is identified by a customer and the solution is claimed functionally as the obvious logical solution to the bug, who is the “innovator”?

    Rhetorical question.

  8. 3

    Fantastic analysis.

    It seems to me that this medium vs. method dichotomy really can be thought of more broadly as a medium/apparatus/system/mpf vs. method dichotomy, with the key distinction being between claims where mere existence is anticipatory/infringing and claims where activity is required for infringement. Worth considering when deciding which claim categories to select in a given 3-20…

  9. 2

    While anon, it just seems to me that a standard way of developing software is to engage beta users to debug and address other performance issues in the software. This is SOP. I think this should be legitimate experimental use by the software developer.

    1. 2.1

      I think this should be legitimate experimental use by the software developer.

      What does the experimental use of the Paving Case say though?

    1. 1.1

      Whose experimental use are you referring to, Ned?

      More than one doctrine out there with “experimental use.”

Comments are closed.