Expedia Inc v. IBM Corp

1. Case Identification

• Case #: IPR2019-01317
• Patent #: 6,374,359
• Filed: July 11, 2019
• Petitioner(s): Expedia, Inc.; Homeaway.com, Inc.; Hotels.com L.P.; Hotwire, Inc.; and Orbitz, LLC
• Patent Owner(s): International Business Machines Corp.
• Challenged Claims: 17-20

2. Patent Overview

• Title: Web Browser User Authentication
• Brief Description: The ’359 patent describes a method for authenticating a web browser user by requiring the browser to refresh a webpage. This refresh action allows a server to confirm that the browser successfully set a requested cookie, thereby verifying the user's session.

3. Grounds for Unpatentability

Ground 1: Obviousness over Reiche, Fisher, Goodman, Stubbs, and LDAP Draft - Claims 17-20 are obvious over Reiche in view of Fisher, Goodman, Stubbs, and the LDAP Draft.

• Prior Art Relied Upon: Reiche (Patent 6,092,196), Fisher (a 1996 publication titled Spinning the Web), Goodman (a 1996 publication titled JavaScript Handbook), Stubbs (a 1996 Usenet post), and the LDAP Draft (an IETF Working Draft from 1997).
• Core Argument for this Ground:
  • Prior Art Mapping: Petitioner argued the combination of references taught every element of the challenged claims. Reiche disclosed a base system for user authentication using an encrypted cookie sent back to the user via a server-based header-redirect (a 302-redirect) to the original URL for verification. This taught the core loop of setting and checking a cookie. However, the key limitation added during prosecution to overcome Reiche was the use of a "refresh page." Petitioner asserted that Fisher, which was not before the examiner, explicitly taught using an HTML META REFRESH tag as a well-known alternative to a server-side header-redirect to cause a browser to reload a page. Goodman taught using client-side JavaScript embedded in a webpage to set cookies, rather than relying on server-side HTTP headers as in Reiche. Stubbs, a Usenet post discussing cookie security, taught including additional information like the user's IP address (a "client destination address"), username, and password within an encrypted cookie to prevent tampering. Finally, the LDAP Draft provided the context of a well-known application (an LDAP directory) that required secure, authenticated access, serving as an obvious target for the combined authentication method.
  • Motivation to Combine: A POSITA would combine these references for several reasons.
    • A POSITA would substitute Fisher's HTML META REFRESH tag for Reiche's server-based header-redirect to solve a known technical problem where a server might ignore a Set-Cookie header when also processing a 302-redirect header, thus ensuring more reliable cookie setting. This modification was presented as a simple substitution of one known technique for another to improve performance.
    • A POSITA would incorporate Goodman's JavaScript cookie-setting method to give a web developer more direct control over cookie management, making it independent of server configurations which might be outside the developer's control.
    • A POSITA would add Stubbs's teachings to bolster the known security weaknesses of the cookie-based authentication in Reiche. Including the IP address, username, and password in the encrypted cookie provided a predictable way to enhance security and prevent forgery.
    • A POSITA would apply the resulting secure authentication system to the LDAP directory described in the LDAP Draft, as it was a common and widespread application at the time that required exactly the type of authenticated access control the combined method provided.
  • Expectation of Success: Petitioner asserted that combining these known elements—substituting a client-side refresh for a server-side redirect, using JavaScript for cookie setting, and adding security data to the cookie—involved predictable techniques to solve known problems, leading to a reasonable expectation of success.

4. Key Claim Construction Positions

• Petitioner argued for specific constructions of key terms that were central to its invalidity argument, contending they reflected the distinction that allowed the patent to issue over the Reiche reference during prosecution.
• "refresh page": Petitioner proposed this term be construed as a "page containing HTML code for causing a Web browser to refresh the page." Petitioner argued this construction is necessary because the patentability of the claims hinged on using a specific HTML-based mechanism (the <META HTTP-EQUIV="Refresh"> tag) rather than the generic server-based header-redirect disclosed in Reiche. Patent Owner's proposed broader construction ("content that redirects the web browser") would improperly eliminate the very distinction upon which the Patent Office relied in issuing the patent.

5. Arguments Regarding Discretionary Denial

• Petitioner argued that discretionary denial under 35 U.S.C. §325(d) would be inappropriate. The petition asserted it presented substantially different arguments and combinations that were never considered during prosecution. Critically, the examiner was not aware of prior art like Fisher, which taught the HTML metatag refresh mechanism. Petitioner contended that this new prior art filled the exact gap that led the examiner to allow the claims over Reiche, making review of this new combination necessary.

6. Relief Requested

• Petitioner requested the institution of an inter partes review and the cancellation of claims 17-20 of the ’359 patent as unpatentable under 35 U.S.C. §103.