Booking Holdings Inc v. Express Mobile Inc

1. Case Identification

• Case #: IPR2022-00248
• Patent #: 9,471,287
• Filed: December 1, 2021
• Petitioner(s): Booking Holdings, Inc.
• Patent Owner(s): Express Mobile, Inc.
• Challenged Claims: 1, 3, 5-7, 11-13, 15, 17, 19-21, 24-27

2. Patent Overview

• Title: Systems and Methods for Integrating Widgets on Mobile Devices
• Brief Description: The ’287 patent discloses a system for generating code to provide content on a device display. The system uses an authoring tool to create a device-independent "Application" and a device-dependent "Player," which work together to access web services and render content.

3. Grounds for Unpatentability

Ground 1: Obviousness over Web Application Development References - Claims 1, 3, 5-7, 12-13, 15, 17, 19-21, 24, 26-27 are obvious over Anderson, Bowers, Jacobs, Ambrose-Haynes, and Geary.

• Prior Art Relied Upon: Anderson (a 2006 field guide for Java Studio Creator), Bowers (a 2003 web development book), Jacobs (a 2006 book on XML for Flash), Ambrose-Haynes (a 2001 book on Professional ColdFusion), and Geary (a 2004 book on Core JavaServer Faces).
• Core Argument for this Ground:
  • Prior Art Mapping: Petitioner argued that the combination of references taught every element of the challenged claims by describing a standard architecture for creating a Java-based web application that accesses a web service. Anderson’s Java Studio Creator was asserted to be the claimed "authoring tool" that produces a device-independent "Application" (Java bytecode) and relies on a device-dependent "Player" (the Java Virtual Machine or JVM). The "registry" storing "symbolic names" corresponds to a Web Services Description Language (WSDL) file, which both Anderson and Bowers teach is used to describe the Google web service. Bowers and Jacobs were cited to show that this WSDL file contains symbolic names (e.g., doGoogleSearch) corresponding to web service functions and their inputs/outputs. Geary was used to show that standard JavaServer Faces (JSF) classes, such as UIInput and UIOutput, meet the limitations for subclasses of UI objects. Finally, Ambrose-Haynes was cited to describe the JVM as the device-dependent "Player" code that is separate from the application bytecode it executes.
  • Motivation to Combine: A POSITA developing a Java-based web application as described in Anderson would combine these references to implement known, industry-standard technology. Anderson expressly taught using a WSDL file and the JSF framework, which would lead a POSITA to consult references like Bowers and Geary for implementation details. Ambrose-Haynes provided fundamental details on the JVM, a standard component of any Java environment. All references addressed the same field of web application development.
  • Expectation of Success: A POSITA would have a high expectation of success, as the combination involved using well-established, compatible technologies (Java, JVM, WSDL, JSF) for their intended purposes to build a conventional web application.

Ground 2: Obviousness with Network File System - Claims 11 and 25 are obvious over Anderson, Bowers, Jacobs, Ambrose-Haynes, Geary, and NFS Administration.

• Prior Art Relied Upon: The combination from Ground 1 in further view of NFS Administration (a 1993 manual for UNIX Network File System).
• Core Argument for this Ground:
  • Prior Art Mapping: This ground addressed dependent claims 11 and 25, which added the limitation that the "code" (the Application and Player) is "provided over said network." Petitioner asserted that NFS Administration taught a well-known Network File System (NFS) that allows a computer to access files from remote storage over a network as if they were stored locally. This technology directly disclosed providing application and player files over a network.
  • Motivation to Combine: A POSITA would combine the web development environment of Ground 1 with a networked file system for common and predictable reasons, such as centralizing file storage for easier administration, ensuring version consistency across a development team, and reducing local storage costs. Ambrose-Haynes further taught that the code for a JVM ("Player") was typically obtained over the internet.
  • Expectation of Success: Success would be expected, as integrating networked file storage into a software development workflow was a routine and well-understood practice at the time of the invention.

4. Key Claim Construction Positions

• "Application" vs. "Player": Petitioner argued for a construction that distinguished the "Application" from the "Player." The "Application" was contended to be device-independent code (e.g., Java bytecode), while the "Player" was construed as separate, executable, device-specific code (e.g., the JVM) that interprets and executes the Application.
• "Registry": Petitioner contended that the claimed "registry" storing symbolic names corresponds to a WSDL file, which is an XML-based file used to describe web services. This construction aligned with the patent's specification and the teachings of the prior art.
• "Device-dependent code" / "Device-independent code": Consistent with the Application/Player distinction, Petitioner argued that device-independent code is code not specific to any platform (like Java bytecode), whereas device-dependent code is specific to an operating system or platform (like a compiled JVM).

5. Arguments Regarding Discretionary Denial

• Fintiv Factors (§314(a)): Petitioner argued against discretionary denial under Fintiv, asserting that the parallel district court litigation against it was in a very early stage with no trial date set and that a stay was likely upon institution of the IPR. Petitioner also stated its intent to stipulate not to pursue in the litigation any invalidity ground raised or that could have been reasonably raised in the IPR, minimizing any overlap of issues.
• General Plastic Factors (§325(d)): Petitioner argued against denial under General Plastic, stating that this was its first IPR petition against the ’287 patent. It contended that the asserted prior art combinations were not cumulative to art previously considered during prosecution or in prior IPRs filed by other parties (e.g., Google, SAP, Adobe). While the same art was asserted in a co-pending IPR by Facebook, this petition challenged additional claims, and Petitioner expressed its willingness to consolidate proceedings to conserve resources.

6. Relief Requested

• Petitioner requested institution of an inter partes review and cancellation of claims 1, 3, 5-7, 11-13, 15, 17, 19-21, and 24-27 of Patent 9,471,287 as unpatentable.