Booking Holdings Inc v. Express Mobile Inc

1. Case Identification

• Case #: IPR2022-00247
• Patent #: 9,928,044
• 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 PROGRAMMING MOBILE DEVICES
• Brief Description: The ’044 patent relates to a system for generating code to display content on a device. The system uses an authoring tool to build a device-independent "Application" that interacts with web services, which is then executed on a device by a device-dependent "Player."

3. Grounds for Unpatentability

Ground 1: Obviousness over Core Web 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 book on Java Studio Creator), Bowers (a 2003 book on web development), Jacobs (a 2006 book on XML for Flash), Ambrose-Haynes (a 2001 book on ColdFusion), and Geary (a 2004 book on JavaServer Faces).
• Core Argument for this Ground:
  • Prior Art Mapping: Petitioner argued that the combination of references taught every element of the independent claims. Anderson’s Java Studio Creator was presented as the claimed "authoring tool" used to build a Java web application (the claimed device-independent "Application"). This application was designed to interact with a known web service (Google Search), whose inputs and outputs constitute the "web components." Bowers and Jacobs were cited to provide specific details of the Google Search WSDL file (the "registry" storing "symbolic names"), confirming it was a standard XML file. Ambrose-Haynes was used to show that the Java Virtual Machine (JVM) is the device-dependent "Player" that executes the device-independent Java bytecode application. Geary was cited to teach standard JavaServer Faces (JSF) classes, like UIInput and UIOutput, which correspond to the claimed User Interface (UI) object subclasses for handling web service inputs and outputs.
  • Motivation to Combine: Petitioner contended a Person of Ordinary Skill in the Art (POSITA) would combine these references as a matter of routine web development. Anderson's use of Java, JSF, and a specific Google WSDL file would have directly motivated a developer to consult standard references like Geary (for JSF), Ambrose-Haynes (for the underlying JVM), and Bowers/Jacobs (for details on the exact WSDL file) to implement the system. The combination involved integrating well-known, compatible technologies to achieve the predictable result of creating a web application that interacts with a third-party web service.
  • Expectation of Success: A POSITA would have had a high expectation of success because the combination relied on well-established industry standards for Java programming, web services, XML, and WSDL, which were designed to be interoperable.

Ground 2: Obviousness over Core Combination plus Network Storage - 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 view of NFS Administration (a 1993 book on Network File System).
• Core Argument for this Ground:
  • Prior Art Mapping: This ground addressed the additional limitation in claims 11 and 25 that the application and player code is "provided over said network." Petitioner argued that NFS Administration taught a well-known Network File System (NFS) for storing files on a remote server and accessing them transparently over a network as if they were stored locally. This technology directly disclosed providing code, such as the Java "Application" and JVM "Player," over a network.
  • Motivation to Combine: A POSITA developing the system in Anderson would have been motivated to use a distributed file system like NFS to enable centralized storage of code. This common practice simplified administration, ensured consistency for multiple developers, and reduced storage costs—all compelling benefits in a software development environment.
  • Expectation of Success: Combining a standard network file system with a software development environment was a routine and predictable task.

Ground 3: Obviousness over Core Combination plus Relational Database - Claims 1, 3, 5-7, 12-13, 15, 17, 19-21, 24, 26-27 are obvious over Anderson, Bowers, Jacobs, Ambrose-Haynes, Geary, and Witkowski.

• Prior Art Relied Upon: The combination from Ground 1 in view of Witkowski (Patent 6,125,360).
• Core Argument for this Ground:
  • Prior Art Mapping: This ground was presented as an alternative to Ground 1, addressing a potentially narrow construction of the term "database." While Petitioner argued Anderson's project file structure met the term, if a more formal database was required, Witkowski taught using conventional relational database management systems (DBMS) for storing organized data. A POSITA would have used a relational database as taught by Witkowski to store the UI object information and related settings from Anderson's project.
  • Motivation to Combine: Petitioner argued a POSITA would have been motivated to use a mature, stable, and well-documented relational database from Witkowski instead of a simple file structure to manage the application's project data. This would offer superior data organization, scalability, and integrity, making it a natural choice for storing information about UI objects and their properties.
  • Expectation of Success: Integrating a standard relational database into a software application was a well-known and straightforward task with a high expectation of success.
• Additional Grounds: Petitioner asserted an additional obviousness challenge (Ground 4) based on the combination of Ground 2 and Witkowski, applying the same rationale for using a relational database to the network-provided code scenario.

4. Key Claim Construction Positions

• "Application": Petitioner proposed the construction "device-independent code that is separate from the Player/player and is interpreted or executed by the Player/player." This construction was central to mapping Anderson's device-independent Java bytecode to this claim term.
• "Player": Petitioner proposed the construction "Executable device specific code, that is separate from the Application and interprets or executes the Application." This was critical for identifying Anderson's Java Virtual Machine (JVM), which is specific to an operating system but executes portable bytecode, as the claimed "Player."

5. Arguments Regarding Discretionary Denial

• Petitioner argued against discretionary denial under Fintiv, stating that the parallel district court litigation was in an early stage with no trial date set, making a stay likely and ensuring the IPR would conclude first. Petitioner also agreed to a Sotera stipulation to not pursue the same grounds in the district court case. Petitioner further argued against denial under §325(d), asserting that the prior art references were not cumulative to the art considered during prosecution and were not considered in prior IPRs that resulted in denial of institution.

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 as unpatentable.