PTAB

IPR2014-01085

Cisco Systems Inc v. Constellation Technologies LLC

Log In
Key Events
Petition
petition

1. Case Identification

2. Patent Overview

  • Title: System and method for broadband multi-user communication sessions
  • Brief Description: The ’389 patent discloses a system for initiating and managing multi-user communication sessions, such as online gaming, over a network. The system uses known Internet Engineering Task Force (IETF) protocols like Session Initiation Protocol (SIP) and Session Description Protocol (SDP) to establish sessions between users and reserve network resources to meet Quality of Service (QoS) requirements.

3. Grounds for Unpatentability

Ground 1: Obviousness over the Rosenberg Combination - Claims 26-28 and 30-33 are obvious over RFC 2543, RFC 2205, RFC 2327, and Rosenberg.

  • Prior Art Relied Upon: RFC 2543 (“SIP: Session Initiation Protocol,” Mar. 1999), RFC 2205 (“Resource ReSerVation Protocol (RSVP),” Sep. 1997), RFC 2327 (“SDP: Session Description Protocol,” Apr. 1998), and Rosenberg (“Establishing QoS and Security Preconditions for SDP Sessions,” Jun. 1999).
  • Core Argument for this Ground:
    • Prior Art Mapping: Petitioner asserted that the combination of these four IETF references (the "Rosenberg Combination") teaches every element of the challenged claims. Independent claim 26 recites a local communication system with several means-plus-function elements for establishing a session with QoS guarantees. Petitioner argued that RFC 2543 (SIP) discloses the fundamental framework for session initiation (INVITE/OK/ACK messages) between users on local networks. RFC 2327 (SDP) provides the standard format for describing session parameters, including QoS needs, within SIP messages. RFC 2205 (RSVP) teaches the specific mechanisms for determining resource availability and reserving network bandwidth based on QoS requests. Finally, Rosenberg explicitly teaches combining these protocols, extending SDP to define specific QoS and security attributes as mandatory preconditions for establishing a SIP session using RSVP for resource reservation. Dependent claims 27-28 and 30-33 add limitations that Petitioner contended were also explicitly taught by the Rosenberg Combination, such as using specific SIP INVITE and SIP OK messages (RFC 2543), including extended SDP with QoS requirements (Rosenberg), and specifying session classifications (RFC 2543/2205).
    • Motivation to Combine: A POSITA would combine these references because they were part of the same IETF multimedia architecture and were expressly designed to work together. RFC 2543 itself states it was designed to incorporate protocols like RFC 2205 (RSVP) and RFC 2327 (SDP). Rosenberg provides the most direct motivation, as it is an IETF draft that explicitly proposes extending SDP (RFC 2327) to establish QoS preconditions for SIP (RFC 2543) sessions using reservation mechanisms like RSVP (RFC 2205). The combination addressed the known need to build reliable, high-quality multimedia sessions over IP networks.
    • Expectation of Success: A POSITA would have had a high expectation of success because the references were standard, interoperable IETF protocols intended for this precise purpose. Rosenberg provided a clear roadmap for the combination, and implementing standardized protocols to achieve their stated functions would have involved only ordinary skill and resulted in the predictable outcome of a session established with QoS guarantees.

Ground 2: Obviousness over the Rosenberg Combination in view of Leigh - Claim 29 is obvious over RFC 2543, RFC 2205, RFC 2327, and Rosenberg in view of Leigh.

  • Prior Art Relied Upon: The Rosenberg Combination and Leigh (“Issues in the design of a flexible distributed architecture for supporting persistence and interoperability in collaborative virtual environments,” 1997).
  • Core Argument for this Ground:
    • Prior Art Mapping: Claim 29 depends on claim 26 and adds the limitation that the SIP INVITE message includes an extended SDP "specifying a latency requirement." Petitioner argued the Rosenberg Combination already taught sending a SIP INVITE with extended SDP for QoS, as detailed in Ground 1. The Leigh reference, which addresses collaborative virtual environments, explicitly teaches the importance of specifying latency as a key QoS requirement to ensure system performance and a quality user experience.
    • Motivation to Combine: A POSITA seeking to improve the performance of a real-time communication system, such as for online gaming as contemplated by the ’389 patent, would have recognized that excessive latency degrades user experience. Leigh taught that specifying latency requirements was a known solution to this problem. A POSITA would combine Leigh’s teaching with the Rosenberg Combination’s framework by simply adding a latency parameter to the extensible SDP format. This would have been a simple and logical step to enhance the known system for a predictable improvement in performance.
    • Expectation of Success: The combination would have been straightforward. The SDP format taught by RFC 2327 was designed to be extensible, and adding a known QoS parameter like latency, as taught by Leigh, would have been a predictable application of the prior art.

4. Key Claim Construction Positions

Petitioner argued that several claim terms, including multiple means-plus-function limitations in independent claim 26, required specific construction.

  • "[negotiating/negotiation] message": Petitioner proposed this term means "a message specifying terms and sent in response to an invitation to a session," such as a SIP OK message that includes the responding user's QoS requirements. This construction was central to mapping RFC 2543's SIP OK message to the claims.
  • "latency requirement" (claim 29): Proposed as "a requirement that a certain delay time be less than, equal to, or greater than a specific value." This construction framed latency as a standard, specifiable QoS parameter, aligning it with the teachings of the Leigh reference.
  • "means for determining resource availability...and reserving resources": Petitioner identified the corresponding structure as a policy server, which RFC 2205 discloses as "policy control" and "admissions control" modules. These modules perform the claimed functions of checking permissions, determining if a network node has sufficient resources to supply a requested QoS, and reserving those resources. This construction was critical to mapping the resource reservation functions of RFC 2205 to the claims.

5. Relief Requested

  • Petitioner requested the institution of an inter partes review and cancellation of claims 26-33 of Patent 6,845,389 as unpatentable.