Admissions that programming was commonly known doom patent owner in CBM appeal

Federal CircuitApple, Inc. v. Ameranth, Inc., Nos. 2015-1703, 2015-1704, 2016 U.S. App. LEXIS 21277 (Fed. Cir. Nov. 29, 2016) (Before Reyna, Chen, and Stoll, J.) (Opinion for the court, Reyna, J.)

The Federal Circuit affirmed the Board’s decision to invalidate certain claims in three patents owned by Ameranth. The Court also reversed the Board’s decision to uphold other claims in the patents, finding that all of the claims were unpatentable under § 101.

The Director of the USPTO intervened to challenge the Court’s jurisdiction to review the Board’s ultimate decisions, including whether the patents are covered business method (CBM) patents. The Court explained that it does have jurisdiction to review CBM determinations, as explained in Versata Group, Inc. v. SAP America, Inc., 793 F.3d 1306, 1323 (Fed. Cir. 2015).

The three Ameranth patents are from the same family, comprising a parent, a continuation, and a continuation-in-part. The specifications are nearly identical; the continuation-in-part included two additional figures and some additional description. The patents concern “a first menu that has categories and items, and software that can generate a second menu from the first menu by allowing categories and items to be selected.” A preferred embodiment is for use as a point of sale interface in restaurants.

The Court first addressed Ameranth’s claim construction arguments, finding that the Board correctly construed the claims “according to their broadest reasonable construction in light of the [corresponding] patent’s specification.”

The Court then reviewed the CBM status of the patents. A CBM patent must claim “a method or corresponding apparatus . . . used in the practice, administration, or management of a financial product or service,” unless the patent is for “technological inventions.” (internal quotations omitted). Ameranth did not challenge the Board’s “financial product or service” determination” but did argue that the patents fall within the exception for technological inventions.

According to 37 C.F.R. § 42.301(b), two prongs must be met for the “technological invention” exception. The claimed subject matter, as a whole, must “recite[] a technological feature that is novel and unobvious over the prior art, and it must “solve[] a technical problem using a technical solution.” The Board found that Ameranth’s patents failed to meet either prong. On review, the Court agreed with the Board’s finding that Ameranth failed to meet the second prong, as the “claims do not solve technical problems using technical solutions” and “this was ‘more of a business problem than a technical problem.’” Because the Court affirmed the Board’s determination on the second prong, it declined to address the first prong. Thus, Ameranth’s patents are CBM patents.

The Court also agreed with the Board’s determination that certain claims are invalid under § 101. This inquiry asks whether the claims are directed to a patent-ineligible concept, such as an abstract idea. If they are, the elements of each claim must be considered “both individually and as an ordered combination to determine whether the additional elements transform the nature of the claim into a patent-eligible application.” (internal quotations omitted). The Court agreed that the claims “are directed to the abstract idea of generating a second menu from a first menu and sending the second menu to another location.” Further, the patents “do not claim a particular way of programming or designing the software to create menus that have [certain] features, but instead merely claim the resulting systems. . . . Alternatively, the claims are not directed to a specific improvement in the way computers operate.”

The Court also agreed that certain claims failed to add anything more to “transform the nature of the claim[s] into a patent-eligible application.” The claim limitations relied on by Ameranth were insufficient to overcome this hurdle, as “the specifications describe the hardware elements of the invention as ‘typical’ and the software programming needed as ‘commonly known.’ The invention merely claims the addition of conventional computer components to well-known business practices.”

The Court reversed the Board’s decision that some of the claims were patentable. These claims recited a limitation that was not supported by any disclosure regarding how the limitation would be technologically implemented. “Generally, a claim that merely describes an effect or result dissociated from any method by which it is accomplished is not directed to patent-eligible subject matter.” (internal quotations omitted). Other dependent claims upheld by the Board merely recited manual modification of the menu after generation. These claims recited insignificant post-solution activity that is not patentable. Although some of the methods of modification utilize certain technologies, “[a]ppending these preexisting technologies onto those [unpatentable] independent claims does not make [the dependent claims] patentable.”

The Court relied heavily on Ameranth’s concessions within the specification that certain aspects of the invention were “typical” or “commonly known.” Practitioners should be wary of using such language and should take steps to identify specific technological improvements.

[Troutman-Ad]

[Troutman-About]

Share

Warning & Disclaimer: The pages, articles and comments on IPWatchdog.com do not constitute legal advice, nor do they create any attorney-client relationship. The articles published express the personal opinion and views of the author as of the time of publication and should not be attributed to the author’s employer, clients or the sponsors of IPWatchdog.com.

Join the Discussion

3 comments so far.

  • [Avatar for John White]
    John White
    December 12, 2016 12:19 am

    Paul: here, here, Well said. John

  • [Avatar for Paul Morinville]
    Paul Morinville
    December 11, 2016 10:44 am

    IP Newbie @1, I would guess that is how the courts are looking at it. If a coder can code it, then it is obvious. That is basically what was said in oral arguments at the Supreme Court hearing on Alice.

    Coding is certainly a high level skill. It takes a lot of knowledge especially in complicated software systems that are intended to integrate with others.

    But patents are not code. I don’t know what a software patent is, but most patents that are called software patents are at least method patents. The method of the system is what coders code. Without that, coders do not code anything. Generally, it says what the code does, what steps it takes to do it, and what the result of the code is. Sometimes this can be obvious or anticipated, but it is never abstract.

    You may believe that that patent is obvious because it is simple and anyone could do it, but invalidating it as abstract blows up every other patent. Unless you take the position that every patent is invalid under Alice, the abstract idea is very dangerous. Even if the patent could be invalidated as obvious on the merits, calling it abstract conflates the issues and puts all other patents at risk of invalidation.

    It is that risk that shuts down the patent system for inventors and startups. If nobody knows what is patentable because the definition of abstract is that a coder can code it, and that sucks up the definition of obviousness or anticipation, then nobody will consider the value of a patent when considering investment into a startup. It is just too risky. First the startup will not be able to keep infringers at bay and they will steal it. Second if they steal it, then the investor will not be able to return their investment.

    The abstract idea means that it is better to invest in a company that would steal it than it is to invest in the company that invented it.

  • [Avatar for IP Newbie]
    IP Newbie
    December 11, 2016 04:36 am

    As often seems to be the case, Ameranth ‘077 is claiming a software method that would be obvious to any entry-level programmer tasked with creating a restaurant menu system.

    101 is of course not the right way to invalidate the patent, but sometimes I get the impression that 101 is the court’s technologically inarticulate way of saying that programmers know how to create programs.

    It seems reasonable to evaluate this and other such patents for validity as a business method (since it might be that the basic idea of the system is inventive even if the implementation is not).