Apple Inc v. Uniloc 2017 LLC

1. Case Identification

• Case #: IPR2019-00701
• Patent #: 8,018,877
• Filed: February 22, 2019
• Petitioner(s): Apple Inc.
• Patent Owner(s): Uniloc 2017 LLC
• Challenged Claims: 1-20

2. Patent Overview

• Title: Mobile Conferencing Method and System
• Brief Description: The ’877 patent discloses a method for establishing a data connection between mobile devices. An initiating device requests a network address and port from a server, receives them, sends this information to another mobile device via a page-mode messaging service (like SMS), and then both devices participate in a data exchange session intermediated by the server.

3. Grounds for Unpatentability

Ground 1: Claims 1-20 are obvious over Kirmse in view of Chambers.

• Prior Art Relied Upon: Kirmse (Patent 6,699,125) and Chambers (Application # 2003/0142654).
• Core Argument for this Ground:
  • Prior Art Mapping: Petitioner argued that Kirmse discloses the core server-based communication method. In Kirmse’s online gaming system, an initiating player’s device requests and receives connection details (the server’s IP address and a specific port number for the game instance) from a game server. The initiating device then sends an invitation with these details to other players, who use them to connect to the game server and participate in the multi-user session. Petitioner contended that this system teaches all elements of the independent claims except for the use of a page-mode messaging service like SMS for the invitation. Chambers was alleged to supply this missing element, as it explicitly teaches sending an SMS invitation containing an IP address to set up a multi-user chat session.
  • Motivation to Combine: A POSITA would combine Kirmse with Chambers to improve the reliability of session invitations. Kirmse’s primary invitation methods (e.g., Yahoo! Messenger) require the recipient to be online and logged into the service. Chambers teaches using SMS because it is always available and can reach devices that are offline or lack an active IP connection at the time of invitation. Therefore, a POSITA would be motivated to substitute or supplement Kirmse’s invitation method with the more robust SMS method taught by Chambers to ensure invitations are received.
  • Expectation of Success: A POSITA would have a high expectation of success, as combining the references amounted to the simple substitution of one known messaging service (SMS) for another (IM) to achieve the predictable result of improved invitation delivery.

Ground 2: Claims 1-20 are obvious over Chambers in view of RSIP.

• Prior Art Relied Upon: Chambers (Application # 2003/0142654) and RSIP (Request for Comment 3103).
• Core Argument for this Ground:
  • Prior Art Mapping: Petitioner asserted that Chambers discloses a multi-user chat system where an initiating device sends an SMS with a temporary IP address to other devices to establish a chat session. However, Petitioner argued that Chambers’s preferred embodiment assumes the use of globally unique IP addresses, a scenario that ignores the common problem of Network Address Translation (NAT) where devices have private, non-routable IP addresses. RSIP (Realm Specific IP) was presented as a well-known NAT traversal technique that solves this problem. RSIP describes a host requesting a public IP address and port from a gateway/server, which can then be shared with other devices to enable communication across NATs.
  • Motivation to Combine: A POSITA implementing Chambers’s system would recognize that mobile devices on cellular networks are typically assigned private IP addresses behind a NAT. An IP address from one private network is useless to a device on another. This would motivate the POSITA to incorporate a known NAT traversal solution to make the system functional. RSIP was a standardized solution for this exact problem, providing a mechanism to obtain a publicly accessible address and port from a server, which aligns with the server-based architecture of the ’877 patent.
  • Expectation of Success: Success would be expected because RSIP was specifically designed to enable the type of IP-based communication described in Chambers to work across different networks and NATs. The combination would predictably result in a functional cross-network communication system.

Ground 3: Claims 1-3, 5-10, and 12-20 are obvious over Cordenier in view of TURN.

• Prior Art Relied Upon: Cordenier (European Application # EP 1 385 323 A1) and TURN (Traversal Using Relay NAT, an IETF draft).
• Core Argument for this Ground:
  • Prior Art Mapping: Petitioner argued that Cordenier discloses a system nearly identical to the challenged claims, wherein a first mobile terminal sends an SMS message containing its IP address to a second terminal to initiate a data exchange over the internet. Cordenier, however, does not provide a robust solution for when the terminals are on different private networks separated by NAT. TURN was alleged to provide this solution. TURN is a relay-based NAT traversal protocol where a client requests a public IP address and port from a TURN server. The client sends these details to a peer, and the TURN server then relays all data between the client and peer, guaranteeing connectivity even through restrictive NATs.
  • Motivation to Combine: Cordenier expressly acknowledges that its terminals may be on different networks and separated by NAT. In such a scenario, the private IP address sent via SMS would be unusable by the receiving terminal. A POSITA would thus be motivated to find and implement a known NAT traversal technique. TURN would be an attractive solution because its relay mechanism ensures a connection can be established. The POSITA would modify Cordenier’s system for the initiating terminal to request a relayed address from a TURN server and include that address in the SMS invitation.
  • Expectation of Success: A POSITA would have a high expectation of success in combining the references, as TURN was a standardized and well-understood technique for enabling communications in the exact scenario Cordenier describes (devices separated by NAT).

4. Key Claim Construction Positions

• "page-mode messaging service": Petitioner contended this term requires no explicit construction beyond its ordinary meaning, which encompasses Short Message Service (SMS), as disclosed in the specification and used in the asserted prior art.
• Preambles: Petitioner argued that the preambles of the independent claims are not limiting because the body of each claim recites a complete invention.

5. Key Technical Contentions (Beyond Claim Construction)

• Effective Filing Date: Petitioner argued that no claim of the ’877 patent is entitled to a priority date earlier than March 28, 2005. The parent applications allegedly describe a fundamentally different, peer-to-peer architecture without an intermediating server. In contrast, the challenged claims require communication through a server, which Petitioner contended is new matter not supported by the parent applications. This later effective filing date allows more prior art to be asserted against the claims.

6. Arguments Regarding Discretionary Denial

• Petitioner argued that review is proper under §314(a) and §325(d) because none of the asserted prior art references or combinations (Kirmse, Chambers, Cordenier, RSIP, TURN) were considered during the original prosecution of the ’877 patent. The petition was therefore not cumulative of any art or arguments previously before the Office.

7. Relief Requested

• Petitioner requested institution of an inter partes review and cancellation of claims 1-20 of the ’877 patent as unpatentable.