‘Graphical User Interface’ does not necessarily invoke means-plus function analysis

Including claim language that embodies a function did not necessarily transform the limitation into a means for performing that function.

Image Source: DepositPhotos

Zeroclick, LLC sued Apple Inc. in the U.S. District Court for the Northern District of California, asserting claims 2 and 52 of U.S. Patent No. 7,818,691 and claim 19 of U.S. Patent No. 8,549,443. The district court found the asserted claims invoked means-plus-function by using terms for which the specifications of the patents did not disclose sufficient structure, which rendered the claims indefinite. In a decision authored by Judge Hughes, the Federal Circuit determined the district court failed to undertake the appropriate inquiry and make related factual findings to support its conclusion that the asserted claims recited means-plus function terms. See Zeroclick, LLC v. Apple Inc., No. 2017-1267, 2018 (Fed. Cir. June 1, 2018) (Before Reyna, Taranto, and Hughes, J.) (Opinion for the court, Hughes, J.)

Zeroclick filed suit against Apple alleging infringement of its patent directed to modifications to graphical user interfaces. The asserted claims recite the terms such as “program” and “user interface code” in conjunction with functional phrases, e.g., a “program that can operate the movement of the pointer (0) over a screen (300)” and a “user interface code being configured to detect one or more locations.” The district court interpreted the claims as containing “means plus function” limitations under 35 U.S.C. § 112 ¶ 6. Then, the court found the specification lacked sufficient corresponding structure, rendering the claims indefinite.

Zeroclick appealed, arguing that the district court erred by imposing a means plus function analysis. The Federal Circuit agreed with Zeroclick, and ultimately vacated and remanded the case to the district court.

The district court failed to give appropriate weight to the rebuttable presumption created by the absence of the word “means” within the claims. Including claim language that embodies a function did not necessarily transform the limitation into a means for performing that function.

Like many devices, the terms “program” and “user interface code” are named for the functions they perform. Reciting the particular use for a known functionally named component does not trigger a means plus function analysis. Additionally, by removing “program” and “user interface code” from their context in the claims, the district court lost sight of the intrinsic support for their plain and ordinary meaning.

A person of ordinary skill would reasonably recognize that these terms connote conventional graphical user interface programs or code. The district court’s ruling provided insufficient support for concluding that “program” and “user interface code” are substitutes for the missing term “means.” Accordingly, the Court vacated and remanded the case to the district court.

Take Away

Some devices are named for the function they perform. The use of such an art-recognized name, even with functional limitations, does not require construction as a means-plus-function limitation. The inquiry requires attention to the meaning of such terms, in context, to a person of ordinary skill in the art.

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. Read more.

Join the Discussion

3 comments so far.

  • [Avatar for John Wu]
    John Wu
    June 13, 2018 02:26 pm

    This post is important to many software patents. I have prosecuted software patents for more than ten years. I must say that most office actions rejecting means plus functions in software were wrong.

    As a programmer myself, I know that most graphic user interfaces were well known. A programmer who just takes a glance of a GUI photo would know how to implement it. However, most examiners kept arguing on it. Most of them had no experience in writing code. So, their actions reveal ignorance.

    However, similar cases existed long before Zeroclick, LLC v. Apple Inc.,. I cannot understand who in the USPTO ran the internal practices. Its past policy forced patent applicants to show structures of every bolt and nut–even though they were known. Due to the difficulties to discuss algorithms, most applicants could not claim systems using means plus functions. They lost some patent rights.

    Incompetency of USPTO leadership is responsible adverse impacts to many applicants. I hope applicants will tell their stories. It is important to prevent the USPTO from screwing up inventors and patent owners in a whole scale.

    Now, the USPTO screwed up inventors by entering 101 rejection for claiming mental steps. I see the same pattern: 90% of rejections are frivolous.

  • [Avatar for step back]
    step back
    June 11, 2018 05:07 pm

    Do you want a twist of lime in it? 😉

    https://en.wikipedia.org/wiki/Screwdriver_(cocktail)

  • [Avatar for Anon]
    Anon
    June 11, 2018 09:48 am

    Hand me a screwdriver, please.