PTAB
IPR2021-00753
Hewlett Packard Enterprises Co v. Q3 Networking
Key Events
Petition
1. Case Identification
- Case #: IPR2021-00753
- Patent #: 7,457,627
- Filed: April 5, 2021
- Petitioner(s): Hewlett Packard Enterprise Co., Aruba Networks, LLC, Netgear, Inc., and Ruckus Wireless, Inc.
- Patent Owner(s): Q3 Networking LLC
- Challenged Claims: 1-4, 8, 9, 11, and 12
2. Patent Overview
- Title: Efficient and Secure Provision of Quality of Service (QoS)
- Brief Description: The ’627 patent discloses a method for securely managing QoS in communication networks. The system architecture separates a call control level (CCL), which verifies service requests, from a resource control level (RCL), which configures the network, using an encrypted token to communicate authorization between the levels.
3. Grounds for Unpatentability
Ground 1: Obviousness over Reeves and Rivest - Claims 1, 3, 4, 8, 9, 11, and 12 are obvious over Reeves in view of Rivest.
- Prior Art Relied Upon: Reeves (Patent 7,571,238) and Rivest (Patent 4,405,829).
- Core Argument for this Ground:
- Prior Art Mapping: Petitioner argued that Reeves disclosed all major elements of the challenged claims. Reeves taught a network with functionally separate control and resource planes: a "communication server" acted as the CCL to authorize service requests, and "edge routers" and "policy servers" acted as the RCL to manage network resources. Reeves’s system generated a "media authorization object" (MAO) containing QoS information, which Petitioner mapped to the claimed "encrypted token." While Reeves mentioned the MAO was digitally signed, it did not specify a method. Rivest, a foundational patent on public-key cryptography, supplied this missing element by teaching a well-known method for creating a secure digital signature using asymmetric encryption.
- Motivation to Combine: A POSITA would combine Rivest with Reeves to implement the digital signature for the MAO. Reeves’s goal was secure authorization, and Rivest provided a standard, widely known method to ensure the authenticity and privacy of the MAO. This combination was presented as an obvious implementation choice from a limited number of well-known alternatives.
- Expectation of Success: A POSITA would have a high expectation of success in applying Rivest's standard encryption technique to secure the data object (MAO) in Reeves's communication system.
Ground 2: Obviousness over Reeves, Rivest, and Chen - Claim 2 is obvious over Reeves in view of Rivest and Chen.
- Prior Art Relied Upon: Reeves (Patent 7,571,238), Rivest (Patent 4,405,829), and Chen (Patent 6,487,170).
- Core Argument for this Ground:
- Prior Art Mapping: This ground specifically targeted dependent claim 2, which added the limitation of repeatedly transferring the token. Petitioner asserted that the base combination of Reeves and Rivest taught the creation and single transfer of the encrypted token (MAO). Chen was introduced to teach the motivation for repeated transfers, as it disclosed using "repeated REQUEST messages" to accommodate for network changes (e.g., topology changes, link failures) or to dynamically alter connection parameters.
- Motivation to Combine: A POSITA would combine Chen's teaching with the Reeves/Rivest system to improve network performance and resilience. Repeatedly sending the MAO would allow the system to dynamically modify bandwidth allocations or re-establish service in response to network events, which was an obvious modification to enhance the system's efficiency.
- Expectation of Success: The modification was argued to be simple and predictable, as it involved merely repeating the transmission of a signal already designed to be sent at least once.
Ground 3: Obviousness over Gleichauf and Reeves - Claims 1, 3, 4, 8, 9, 11, and 12 are obvious over Gleichauf in view of Reeves.
- Prior Art Relied Upon: Gleichauf (Patent 7,412,598) and Reeves (Patent 7,571,238).
- Core Argument for this Ground:
- Prior Art Mapping: Petitioner contended that Gleichauf disclosed a system with a CCL (server 20) that authorizes service requests and issues an "authorization ticket" (the claimed token) to a client terminal. While Gleichauf mentioned using RSVP for QoS, it did not provide a detailed implementation of the RCL. Reeves was used to supply the missing details, teaching a specific RCL architecture (edge router and policy server) that provisions network resources based on an authorization object.
- Motivation to Combine: A POSITA would combine the teachings because both references address resource provisioning in packet-switched networks. To the extent Gleichauf’s disclosure on resource control was high-level, a POSITA would look to a reference like Reeves to provide a well-known and detailed implementation for the RCL. This would predictably complete Gleichauf’s system and allow it to provision resources securely using the authorization ticket.
- Expectation of Success: Combining Reeves's detailed RCL with Gleichauf's CCL was presented as a straightforward integration of known components in an analogous art field, leading to a predictable result.
- Additional Grounds: Petitioner asserted an additional obviousness challenge against claim 2 over Gleichauf, Reeves, and Chen, which relied on the same rationale for adding Chen as presented in Ground 2.
4. Key Claim Construction Positions
- "determining a QoS requirement ... and verified at [the] call control level": Petitioner argued, based on positions in a parallel ITC proceeding and the patent's specification, that this phrase is broad enough to encompass authenticating a user and authorizing their requested service. This construction was central to mapping the functions of Reeves's "communication server" and Gleichauf's "server 20" to the claimed CCL.
- "creating and transferring ... at least one encrypted token": Petitioner noted that the parties in the ITC proceeding had agreed on a construction for this term: "generating at least one encrypted token, which indicates the QoS requirement verified at the call control level, and transferring the at least one encrypted token to the terminal." This established that the MAO in Reeves and the authorization ticket in Gleichauf functioned as the claimed "token."
5. Arguments Regarding Discretionary Denial
- Petitioner argued against discretionary denial under 35 U.S.C. §325(d) because none of the asserted prior art was before the examiner during prosecution.
- Petitioner argued against discretionary denial under Fintiv because the parallel district court actions were stayed. Further, it was argued that this IPR raises issues distinct from a parallel ITC investigation, as claims 4, 9, 11, and 12 were challenged in the petition but not at issue in the ITC. Petitioner contended these differences, combined with the strong merits of the petition, weighed heavily in favor of institution.
6. Relief Requested
- Petitioner requested institution of an inter partes review (IPR) and cancellation of claims 1-4, 8, 9, 11, and 12 of the ’627 patent as unpatentable.