First thoughts on Bilski

Some very preliminary thoughts on Bilski, written in the course of one train-ride to work. This does not represent the viewpoint of my employer and should not be taken as legal advice; merely observations on one ruling.

  • In the lower court (Federal Circuit) ruling on this case, the Federal Circuit was very aggressive in trying to limit business method patents by applying an old rule very, very broadly. The Supreme Court here reached the same conclusion about the specific patent at issue (holding it not patentable) but chastised the Federal Circuit for their aggressiveness in going from step 1 (invalidate this particular patent) to step 2 (invalidate all business method patents). At the highest level, this is not good for opponents of software patents- this is the most change-averse patent opinion the Supreme Court has issued in recent years, and it will leave the Federal Circuit very reluctant to broadly attack entire classes of patents in the near future. But the court did not completely bar such attempts, and it also strengthened some older anti-software-patent rulings, so it is not a complete loss for opponents of business method and software patents.
  • This was a very splintered decision- while every judge agreed in the outcome, no part of the opinion got more than five votes, and many parts got only four. This probably explains why it took so long, and why Stevens was not (as widely anticipated) the author of the majority opinion- one or more judges probably were swinging between the two opinions until very late in the process. The addition of the probably pro-business Judge Kagan to replace the (effectively) pro-technology Judge Stevens could make future cases along these lines more conservative. And the court itself basically admits in their first section that this is hard; saying of the Federal Circuit’s ruling in the case that “Students of patent law would be well advised to study these scholarly opinions.”
  • The court punts on the most difficult questions, quite explicitly: “This [Information] Age puts the possibility of innovation in the hands of more people and raises new difficulties for the patent law. With ever more people trying to innovate and thus seeking patent protections for their inventions, the patent law faces a great challenge in striking the balance between protecting inventors and not granting monopolies over procedures that others would discover by independent, creative application of general principles. Nothing in this opinion should be read to take a position on where that balance ought to be struck.” [emphasis mine.] Unfortunately, this buys into the rhetoric that all inventors are patenters, but otherwise makes it explicit that the court is staying out of the deeper policy question to the greatest extent it can.
  • Core of the decision is to set up a very conflicting set of tests: business methods can in some circumstances be ‘processes’, which are patentable, but they may also be abstract ideas, which are not patentable. (The lower court had said that business methods are never processes and therefore a court did not need to ask ‘is this an idea?’ before ruling that it was unpatentable.) So future seekers of business method patents (and presumably software patents as well) will have to thread the needle, showing that they are a process (probably not difficult after this ruling) but also that they are not an abstract idea (may be hard, not clear yet.)
  • Needless to say, this kind of gap is the kind of thing that sophisticated lawyers love to drive trucks through, and which will continue to create lots of uncertainty for small innovators for whom even the threat of a patent suit is enough to stop innovation.
  • When deciding that the patent is an idea, and hence unpatentable, the court has kind things to say about Benson and Flook, two older case which spoke against patenting algorithms but which were then sort of ignored. This may signal to lower courts that they should take these cases more seriously when looking at software and business method patents, which would be a good thing for anyone who is seriously interested in the quality of software patents and not the worst possible outcome for those who believe that all software patents should be banned- these could become potent weapons against some of the most outrageous patents on algorithms.
  • At the same time, the court also speaks well of Diehr, another older case. This case has generally been interpreted to stand for the idea that a combination of software with hardware (originally, use of software to control a rubber curing machine) is patentable, but the court here seems to read it more broadly, arguing that Diehr should be interpreted to mean that algorithms combined with any new processes (whether mechanical or otherwise) might still be patentable.
  • The court specifically tells the Federal Circuit that the method of restriction it had been using is barred or weakened (not great for those who dislike software patents) but also specifically says that the Court can and should explore new methods of limitation as long as they are consistent with the text of the patent act; seemingly implicitly stating that the pre-Bilski situation (where business method patents ran rampant) was untenable. This suggests to me that we’ll see a period of several years of experimentation in the Federal Circuit, where the Federal Circuit attempts to find new ways to limit business method patents on something other than a case-by-case ‘I know it is an idea when I see it’ rule of thumb.
  • The court specifically says that they did not want to create uncertainty for software patents, citing the pro-software-patent amicus briefs, but then goes ahead to create such uncertainty by allowing the Federal Circuit to find new, narrower tests. However, these two sections of the majority holding got only four votes; Scalia did not join this part of the otherwise majority opinion- presumably because it seems to give the Federal Circuit very wide interpretive powers.
  • The Stevens opinion, at a glance (remember, brief train ride) would have been much more amenable to the anti-software-patent crowd, but I imagine that it is exactly this quality that made it the minority opinion.

I’m afraid that at the end of this brief train ride, my only firm conclusion can be that the real winners here are patent lawyers- this decision creates no new certainties, only uncertainties, which will encourage patenters to spend more money patenting things, and the rest of us to waste time and energy worrying about the problem- time and energy that should have been spent on innovating. But this is a long, multi-layered ruling, and will require a lot of time for the full implications to be truly understood, so take this one-train-ride blog post with a large grain of salt :) Hopefully more writing tonight/tomorrow.

17 thoughts on “First thoughts on Bilski”

  1. In all honesty, for most appelate and especially Supreme court decisions I’ve encountered the primary winners seem to be lawyers; it’s very rare for the decision to actually make things _simpler_.

  2. […] Needs to Read ( 3 points by mattgratt 4 hours ago | 2 comments73.First thoughts on Bilski by Mozilla lawyer Luis Villa ( 3 points by mbrubeck 4 hours ago | discuss74.Map of Silicon Alley's Early-Stage Tech […]

  3. While some are disappointed in this ruling in terms of how it might relate to software patents, I see it as promising in that connection. It simply forces the argument against software patents to be based on their being abstract ideas. By finding the machine-or-transformation principle not sufficient and by not finding an exclusion on business method patents, the court actually pushes us to making the right point regarding software patents. I believe all the confusion among the justices can be resolved by acknowledging the following.

    Software patents are patents not just on abstract ideas, but on *pure* abstract ideas. By pure I don’t mean “extremely” — I mean “independent of empirical facts or particulars,” like math.

    The general purpose logic processor does *pure* logical operations; it follows that the instructions provided to that processor are likewise *pure* logic. What translates a pure logical algorithm or process to something of specific use is the devices you attach to the logic processor; it is in principle perfectly conceivable that the exact same set of logic instructions could control entirely different processes, just depending on what devices you attach. And while higher-level, human-readable code uses language that humans can relate to specific things or uses in the empirical world (variable names like “PartNo” or “EmployeeID” or “Chemical1Proportion,” or function names like “InitiateStirring” or “TurnOnBlender”), at bottom the compiled code is a pure logical abstraction.

    The point is, the software is in principle not patentable, though it may be the case that a particular empirical process that that code is being used to control, is patentable. But what decides that is the empirical process as such, not the pure algorithm that the code expresses.

    Note that interestingly, this ruling may also undermine the European “computer-implemented inventions” formula, since it disallows the machine-or-transformation test as solely determining the question, and then it specifically resorts to the abstract idea exclusion. Note also that the Court states that its ruling should not be construed as endorsing the Federal Circuit’s past interpretations of patentable subject matter under section 101.

    So I see this ruling as simply excluding the easier resolution to the software patent issue (an approach not really on point and not really addressing the nature of the issue of software patents) that sees software patents becoming untenable along with business methods, as well as the notion that what makes something patentable is that it is a machine or a transformation.

    What makes software unpatentable is not really directly related to either of those points, but rather to the fact that it is *pure* abstraction. You don’t have to say patents only cover machines and transformations to eliminate software patents. Instead, all you have to do is show that software is always abstract because the nature of the logic processor is inherently pure — it deals only in bits/numbers and logical and methematical operations and algorithms — and when one says those numbers and algorithms are meant to refer to something more, what you’re really saying is that there’s also an empirical process, alongside the pure code, which is the actual process which may be patentable or not.

Comments are closed.