DCT
1:18-cv-00992
Uniloc 2017 LLC v. Apple Inc
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: Uniloc 2017 LLC (Delaware)
- Defendant: Apple Inc. (California)
- Plaintiff’s Counsel: Prince Lobel Tye LLP; Nelson Bumgardner Albritton P.C.
- Case Identification: 1:18-cv-00992, W.D. Tex., 11/17/2018
- Venue Allegations: Plaintiff alleges venue is proper in the Western District of Texas because Apple has regular and established places of business in Austin, Texas, and operates Apple Stores in the district where it offers for sale and sells the accused products.
- Core Dispute: Plaintiff alleges that Defendant’s FaceTime Servers, which enable FaceTime communications, infringe a patent related to network-based policy enforcement for features in IP telephony and multimedia networks.
- Technical Context: The technology concerns methods for network operators to control and authorize the use of specific features (e.g., call waiting, caller ID) initiated by intelligent client devices, thereby preventing unauthorized use of paid services over their networks.
- Key Procedural History: The asserted patent was the subject of an Inter Partes Review (IPR), IPR2018-00884. An IPR Certificate issued on January 24, 2022, cancelled claims 1-17 and 23-25. Claims 18-22 were found patentable. The complaint, filed in 2018, asserts claims 1, 5-9, 18-21, and 23. The cancellation of claims 1 and 5-9 and 23 post-filing significantly narrows the scope of the present litigation to the surviving asserted claims 18-21.
Case Timeline
| Date | Event |
|---|---|
| 2003-09-25 | ’552 Patent Priority Date |
| 2013-09-17 | ’552 Patent Issue Date |
| 2018-04-10 | IPR2018-00884 Petition Filed |
| 2018-11-17 | Complaint Filing Date |
| 2022-01-24 | IPR Certificate Issued, Cancelling Asserted Claims 1, 5-9, and 23 |
II. Technology and Patent(s)-in-Suit Analysis
U.S. Patent No. 8,539,552 - "SYSTEM AND METHOD FOR NETWORK BASED POLICY ENFORCEMENT OF INTELLIGENT-CLIENT FEATURES," issued September 17, 2013
The Invention Explained
- Problem Addressed: The patent describes a problem faced by network carriers where increasingly "intelligent end-user clients" (e.g., sophisticated IP phones or software) could implement advanced telephony services themselves. This created a risk that users could bypass the carrier's network services, using features for which they had not subscribed and for which the carrier could not generate revenue (’552 Patent, col. 1:36-58).
- The Patented Solution: The invention proposes a "network policy enforcement point," such as a firewall or gateway controlled by the network operator, that sits in the communication path. This entity intercepts signaling messages (e.g., call setup requests) from clients, determines if the client is authorized to use the requested service by checking a user profile, and then filters the message—either allowing, blocking, or altering it—based on that authorization (’552 Patent, Abstract; col. 2:60-col. 3:6). This allows the network to maintain control over service usage.
- Technical Importance: This architecture provided a mechanism for network operators to retain control over service authorization and billing in an ecosystem where service logic was migrating from centralized network servers to distributed end-user devices (’552 Patent, col. 1:46-58).
Key Claims at a Glance
The complaint asserts independent claims 1 and 18, and dependent claims 5-9, 19-21, and 23 (Compl. ¶15). As a result of IPR proceedings, claims 1, 5-9, and 23 have been cancelled. The analysis will focus on the surviving asserted independent claim, Claim 18.
- Independent Claim 18:
- a network entity intercepting a message associated with establishing an Internet Protocol (IP) telephony call between a sender...and an intended recipient..., the message configured according to a protocol;
- the network entity requesting a user profile of a user associated with the message, wherein the user profile specifies which of a plurality of services the user is authorized to use, including IP telephony services;
- the network entity determining from the user profile whether the user is authorized to invoke or receive the IP telephone services, wherein the IP telephone services comprise at least two of caller-ID, call waiting, multi-way calling, multi-line service, and codec specification; and
- the network entity filtering the message based on whether the user is authorized to invoke or receive the IP telephone services.
- The complaint reserves the right to assert dependent claims 19-21 (Compl. ¶15).
III. The Accused Instrumentality
Product Identification
The accused instrumentalities are Apple’s "FaceTime Server(s)" (Compl. ¶8).
Functionality and Market Context
The complaint alleges these servers are programmed to establish FaceTime communications between Apple devices such as iPhones, iPads, and MacBooks (Compl. ¶8). The described functionality involves a FaceTime-enabled device registering with a FaceTime Server upon receiving a network connection (Compl. ¶10). To initiate a call, the device sends a query to a server to indicate a session is desired and to get the IP address of the target device (Compl. ¶12). The server then "determines whether the intended target is a registered authorized FaceTime user" and, if authorized, sets up the connection for communication over networks like WiFi, 3G, or LTE (Compl. ¶¶13-14).
IV. Analysis of Infringement Allegations
No probative visual evidence provided in complaint. The complaint does not contain a claim chart. The following chart summarizes the infringement allegations for the sole surviving asserted independent claim by mapping the narrative allegations to the claim elements.
’552 Patent Infringement Allegations
| Claim Element (from Independent Claim 18) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| a network entity intercepting a message associated with establishing an Internet Protocol (IP) telephony call between a sender...and an intended recipient..., the message configured according to a protocol | A FaceTime Server receives an encrypted query from a FaceTime-enabled device, which indicates a FaceTime session is desired. | ¶12 | col. 19:37-41 |
| the network entity requesting a user profile of a user associated with the message, wherein the user profile specifies which of a plurality of services the user is authorized to use, including IP telephony services | When a FaceTime-enabled device connects to the network, it registers with a FaceTime Server, which stores caller IDs (e.g., phone number or Apple ID) and uses them to authenticate users. | ¶10 | col. 19:42-46 |
| the network entity determining from the user profile whether the user is authorized to invoke or receive the IP telephone services... | The FaceTime Server receiving the query determines whether the intended target is a registered authorized FaceTime user. | ¶13 | col. 19:47-51 |
| and the network entity filtering the message based on whether the user is authorized to invoke or receive the IP telephone services. | If the target is a registered authorized user, the FaceTime Server sets up the FaceTime connection, allowing the parties to communicate. | ¶13 | col. 19:52-55 |
- Identified Points of Contention:
- Scope Questions: Does the FaceTime server, which is the designated recipient of a client query, perform the function of "intercepting a message" as required by the claim? The court may need to determine if "intercepting" requires capturing a message in transit between two other endpoints, or if being the intended server-side endpoint for a client-server communication falls within the term's scope.
- Technical Questions: What evidence demonstrates that the FaceTime server's authentication process—checking if a target is a "registered authorized FaceTime user"—is equivalent to "requesting a user profile" that specifies a "plurality of services" like call waiting or codec specifications, as enumerated in the claim? The complaint alleges authentication but does not specify that a profile of distinct, granular services is checked.
V. Key Claim Terms for Construction
The Term: "intercepting a message"
- Context and Importance: This term is foundational to the infringement theory. The case may turn on whether a server that receives a direct request from a client can be said to be "intercepting" it. Practitioners may focus on this term because Apple's architecture is a standard client-server model, whereas the patent often describes the enforcement entity as a "border element" or "firewall" (’552 Patent, Fig. 5-7) that sits between other entities.
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The patent summary describes the method as "receiving signaling messages within a communication path between a sender and a recipient device," which could be argued to describe a server's role in a client-server architecture (’552 Patent, col. 2:60-63).
- Evidence for a Narrower Interpretation: The patent repeatedly describes the "policy enforcement point" as being "in the communications path of substantially each and every call control and signaling message between any end-user client and any call control and signaling entity of the network" (’552 Patent, col. 8:35-39). This language, along with figures depicting firewalls as intermediaries, may support a narrower definition that excludes the intended final recipient of a message.
The Term: "requesting a user profile...[that] specifies which of a plurality of services the user is authorized to use"
- Context and Importance: The infringement allegation relies on equating Apple's user authentication with the claim's requirement of checking a profile for authorization of multiple specific services. The viability of the infringement claim depends on whether the FaceTime server's function meets this specific limitation.
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The patent states that authorization could be determined according to a user profile that might simply list "services and features to which the user has subscribed, e.g., basic calls, call waiting, call forwarding, etc." (’552 Patent, col. 7:4-6). This could support an argument that a simple check for "authorized for FaceTime" is sufficient.
- Evidence for a Narrower Interpretation: Claim 18 explicitly requires the profile to specify authorization for services comprising "at least two of caller-ID, call waiting, multi-way calling, multi-line service, and codec specification." The detailed description explains that the profile contains a "list of authorized services and features" and ancillary information (’552 Patent, col. 14:45-50). This may support a narrower view that a simple binary check for service eligibility (e.g., "is a FaceTime user") is insufficient without a check against a list of multiple, distinct sub-features.
VI. Other Allegations
- Indirect Infringement: The complaint does not contain specific factual allegations or separate counts for induced or contributory infringement.
- Willful Infringement: The complaint does not allege willful infringement or provide facts related to pre-suit or post-suit knowledge of the patent by Apple.
VII. Analyst’s Conclusion: Key Questions for the Case
- Impact of IPR: The primary issue is the legal and procedural impact of the IPR certificate that cancelled the majority of the asserted claims post-filing. The case is now confined to the surviving asserted claims (18-21), fundamentally altering the scope of the dispute from what was originally pleaded.
- Definitional Scope: A central question for infringement will be one of claim construction: can the term "intercepting a message", which the patent often associates with an intermediary firewall, be construed to read on a server that is the designated recipient in a client-server communication model like FaceTime?
- Evidentiary Sufficiency: A key evidentiary question will be one of functional equivalence: does the complaint provide sufficient factual basis to suggest that the FaceTime server’s process for authenticating a user identity is the same as the claimed method of "requesting a user profile" to determine authorization for a "plurality of services" (e.g., call waiting, specific codecs), or is there a fundamental mismatch in the technical operation?