PTAB

IPR2016-01157

Facebook Inc v. Windy City Innovations LLC

Log In
Key Events
Petition
petition

1. Case Identification

2. Patent Overview

  • Title: Real Time Communications System
  • Brief Description: The ’356 patent discloses a computer-based system for real-time communication among multiple users. The system uses a central controller computer and a database of "tokens" to authenticate users and arbitrate interactive connections between independent participant computers over a network.

3. Grounds for Unpatentability

Ground 1: Obviousness over Roseman, Rissanen, and Vetter - Claims 1-5, 8, 9, 12, 14-16, 19-24, 27, 28, 31, 33-35, and 37

  • Prior Art Relied Upon: Roseman (Patent 6,608,636), Rissanen (EP 0621532), and Vetter (a 1995 article on internet videoconferencing).
  • Core Argument for this Ground:
    • Prior Art Mapping: Petitioner argued that Roseman disclosed all major elements of the claimed system, including a server-based virtual conferencing system with a central host computer (the "controller") and participant computers. Roseman’s system used access "keys" stored on the host to authenticate users, which Petitioner mapped to the claimed "tokens." To address limitations not explicitly in Roseman, Petitioner asserted that Rissanen taught the obvious step of using a "database" to store user authentication data, and Vetter taught using the "Internet" as the underlying network for such real-time conferencing systems.
    • Motivation to Combine: A Person of Ordinary Skill in the Art (POSITA) would combine Roseman with Rissanen to use a well-known and reliable database structure for storing authentication keys, which was a predictable and superior design choice for data management. A POSITA would also have been motivated to adapt Roseman's wide area network (WAN) system to the Internet, as taught by Vetter, to leverage the Internet's ubiquity for connecting geographically diverse users, representing a logical evolution for any network communication tool.
    • Expectation of Success: Petitioner contended that the proposed combination involved applying standard, well-understood technologies (databases, the Internet) for their intended purposes within a known system architecture (virtual conferencing), leading to a predictable result and a high expectation of success.

Ground 2: Obviousness over Roseman, Rissanen, and Vetter, in further view of Pike - Claims 6, 7, 17, 26, and 36

  • Prior Art Relied Upon: Roseman (Patent 6,608,636), Rissanen (EP 0621532), Vetter (a 1995 article), and Pike (a 1994 book on the Mosaic web browser).
  • Core Argument for this Ground:
    • Prior Art Mapping: This ground built upon the base combination of Ground 1 to address dependent claims reciting a "pointer" or a "Uniform Resource Locator (URL)." Petitioner argued first that Roseman's own system of using clickable icons to access shared documents already met the "pointer" limitation. Alternatively, Petitioner asserted that Pike explicitly taught the concept and use of URLs as pointers to locate and retrieve content across the Internet.
    • Motivation to Combine: The petition argued that once a POSITA decided to implement the conferencing system on the Internet (per the motivation from Vetter), it would have been an obvious and advantageous design choice to incorporate the standard Internet mechanism for referencing content—the URL, as taught by Pike. Using URLs would be an efficient method for sharing resources without immediately transmitting the entire file to all participants, thereby conserving network bandwidth.
    • Expectation of Success: Integrating URL technology, a fundamental and well-established component of the Internet, into an Internet-based application was a straightforward task with a high expectation of success.

Ground 3: Obviousness over Roseman, Rissanen, and Vetter, in further view of Gosling - Claims 18 and 25

  • Prior Art Relied Upon: Roseman (Patent 6,608,636), Rissanen (EP 0621532), Vetter (a 1995 article), and Gosling (a 1995 paper on Java).
  • Core Argument for this Ground:
    • Prior Art Mapping: This ground addressed dependent claims requiring the controller software to comprise a "JAVA™ application." Petitioner asserted that the base combination of Ground 1 rendered the underlying communication system obvious, and Gosling taught that Java was a known programming language suitable for developing such applications.
    • Motivation to Combine: A POSITA would have been motivated to write the controller software from Roseman in Java, as described by Gosling, to leverage Java's primary benefit of platform independence or "portability." This would allow the server software to run on various hardware and operating systems without modification, a significant and well-known advantage that would reduce development and maintenance costs.
    • Expectation of Success: Using a known programming language like Java to build application software for its well-understood benefits was a common practice with predictable results.

4. Key Claim Construction Positions

  • Petitioner argued for specific constructions based on explicit definitions and disclaimers in the patent's specification and prosecution history, asserting the patentee used several key terms in an idiosyncratic, non-standard manner.
  • "token": The proposed construction was "a piece of information associated with user identity." This broad construction was based on the specification's description and was important for mapping the access "keys" in the Roseman prior art to this claim limitation.
  • "channel": The proposed construction was "a group of users that can communicate with each other." This construction was derived from the patent's equation of a "channel list" with a "group list," which allowed Roseman's "virtual conference room" to meet the limitation.
  • "providing an API on the controller computer, the API multiplexing and demultiplexing API messages by type": Petitioner argued this entire phrase should be construed as "providing software functionality on the controller computer for sending and receiving messages of different types and communicating each message to software functionality based on the message type." This construction was critical, as it relied on a declaration submitted during prosecution that explicitly disavowed the standard technical meaning of "API" (Application Programming Interface) and defined "multiplexing/demultiplexing" as high-level software routing based on message type, rather than a physical layer process. This interpretation was essential to mapping the functionality to Roseman's host software.

5. Relief Requested

  • Petitioner requested the institution of an inter partes review and the cancellation of claims 1-9, 12, 14-28, 31, and 33-37 of the ’356 patent as unpatentable.