PTAB

IPR2019-00826

Apple Inc v. MPH Technologies Oy

Log In
Key Events
Petition
petition

1. Case Identification

2. Patent Overview

  • Title: Method and System for Sending a Message Through a Secure Connection
  • Brief Description: The ’362 patent discloses a method for securely forwarding messages between a first computer and a second computer via an intermediate computer. The technology purports to solve issues with standard Internet Protocol Security (IPSec) for mobile hosts by establishing a single, end-to-end secure connection that can be maintained even when a mobile host changes its network address.

3. Grounds for Unpatentability

Ground 1: Claims 1-6 and 9-15 are obvious over RFC3104 and Grabelsky.

  • Prior Art Relied Upon: RFC3104 (an Internet Engineering Task Force (IETF) standard for end-to-end IPSec) and Grabelsky (Patent 7,032,242).
  • Core Argument for this Ground:
    • Prior Art Mapping: Petitioner argued that RFC3104 discloses the core architecture of the ’362 patent. Specifically, RFC3104 describes a system where an intermediate computer (an RSIP server) receives secure IPSec packets from a second computer (host Y) and forwards them to a first computer (host X), where the hosts are in different address spaces. The RSIP server uses a "minimum tuple of demultiplexing fields" (including the Security Parameter Index (SPI), protocol, and destination address) from the packet header as a unique identity to find a matching mapping and tunnel the packet to the first computer. This process occurs without the intermediate computer needing the cryptographic key to decrypt the payload. Grabelsky was asserted to supply the conventional implementation details not explicit in RFC3104, such as specific packet header formats (IP, AH, ESP headers) and the use of a translation table to perform the mapping between the unique identity (SPI value) and the destination address.
    • Motivation to Combine: A POSITA implementing the system in RFC3104, which describes the high-level protocol, would naturally consult other references for standard implementation details. Petitioner contended a POSITA would combine Grabelsky because it provides exemplary packet formats and discloses using a translation table for mapping SPI values, which are necessary and well-known components for building the IPSec system described in RFC3104. The shared subject matter and a common inventor between the references further supported this motivation.
    • Expectation of Success: Combining a high-level protocol specification (RFC3104) with a reference disclosing standard, compatible implementation details (Grabelsky) was argued to be a straightforward task for a POSITA, leading to a predictable and functional secure communication system.

Ground 2: Claims 7, 8, and 16 are obvious over RFC3104, Grabelsky, and Wagner.

  • Prior Art Relied Upon: RFC3104, Grabelsky, and Wagner (a 1996 USENIX paper titled "Analysis of the SSL 3.0 Protocol").
  • Core Argument for this Ground:
    • Prior Art Mapping: This ground addresses dependent claims that add the requirement of using the Secure Sockets Layer (SSL) or Transport Layer Security (TLS) protocol. The base combination of RFC3104 and Grabelsky establishes the core system of forwarding secure packets via an intermediate computer. Petitioner argued that Wagner taught the use of SSL as a well-known, widely adopted, and practical protocol for securing client-server communications. Wagner also described SSL as a potential alternative to IPSec, highlighting advantages such as resistance to certain types of attacks ("cut-and-paste" attacks) where IPSec was known to be vulnerable.
    • Motivation to Combine: A POSITA designing a secure communication system as taught by RFC3104 and Grabelsky would have been aware of both IPSec and SSL/TLS as primary options for establishing secure channels. Petitioner asserted a POSITA would combine Wagner's teachings for several reasons: to use SSL as a complete alternative to IPSec to leverage its security advantages, or to use SSL in conjunction with IPSec (e.g., tunneling SSL within an IPSec packet) to provide layered, enhanced security. This was presented as a simple design choice between known, interchangeable security protocols to achieve predictable benefits.
    • Expectation of Success: Given that SSL was a de facto standard for securing communications at the time, a POSITA would have readily understood how to apply it to the network architecture of RFC3104 and would have had a high expectation of success in creating a secure connection.

4. Key Claim Construction Positions

  • "unique identity": Petitioner proposed this term should be construed as "one or more parameters that uniquely identify a secure connection." This construction was central to the obviousness arguments. Petitioner argued that the combination of parameters disclosed in the prior art—such as the "minimum tuple of demultiplexing fields" in RFC3104 (protocol, SPI, and destination IP address) or the packet headers shown in Grabelsky—inherently served as parameters that uniquely identify a specific secure connection (the IPSec security association). This construction allowed Petitioner to map the prior art's use of standard packet header information directly onto the claim limitation.

5. Relief Requested

  • Petitioner requests institution of an inter partes review and cancellation of claims 1-16 of the ’362 patent as unpatentable.