PTAB

IPR2019-00824

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 ’502 patent discloses techniques for securely forwarding messages from a first computer to a second computer via an intermediate computer. The technology purports to solve alleged operability issues with standard Internet Protocol Security (IPSec) protocols for mobile hosts, which the patent asserts were designed for static connections.

3. Grounds for Unpatentability

Ground 1: Claims 1-9 are obvious over RFC3104 in view of Grabelsky.

  • Prior Art Relied Upon: RFC3104 (an Internet Engineering Task Force publication from Oct. 2001) and Grabelsky (Patent 7,032,242).
  • Core Argument for this Ground:
    • Prior Art Mapping: Petitioner argued that RFC3104 teaches the core invention: establishing an end-to-end secure IPSec connection between two hosts (a first computer and a recipient computer) through an intermediate server. RFC3104 describes a system where a mobile host in a "Roadwarrior scenario" can connect to a corporate network, establishing a Security Association (SA) using the Internet Key Exchange (IKE) protocol. The intermediate server in RFC3104 uses a defined set of "demultiplexing fields" (including protocol, Security Parameter Index (SPI), and destination IP address) to forward encrypted packets without inspecting the payload. Petitioner asserted that Grabelsky, which shares an author with RFC3104, provides the specific implementation details that RFC3104 describes at a higher level. Grabelsky discloses standard IPSec packet formats (including IP, Authentication Header (AH), and Encapsulating Security Payload (ESP) headers) and the use of translation tables to map SPI values to internal network addresses, thereby supplying the remaining details needed to practice the claimed invention.
    • Motivation to Combine: A Person of Ordinary Skill in the Art (POSITA) seeking to implement the end-to-end IPSec system described in RFC3104 would require concrete details on packet formats and mapping mechanisms. Petitioner contended that since RFC3104 lacks these specific implementation details, a POSITA would combine its teachings with a reference like Grabelsky, which provides standard and well-known solutions for these very elements in a similar context (distributed network address translation with IPSec).
    • Expectation of Success: The combination involved applying standard, well-documented IPSec packet structures and mapping techniques (Grabelsky) to the network architecture of RFC3104. Petitioner argued this would yield predictable results with a high expectation of success.

Ground 2: Claim 10 is obvious over RFC3104, Grabelsky, and Wagner.

  • Prior Art Relied Upon: RFC3104, Grabelsky (’242 patent), 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 claim 10, which adds the limitation of using the Secure Sockets Layer (SSL) or Transport Layer Security (TLS) protocol. The base combination of RFC3104 and Grabelsky establishes the secure messaging framework as described in Ground 1. Wagner provides a detailed technical analysis of the SSL 3.0 protocol, its advantages, and its implementation details.
    • Motivation to Combine: Petitioner asserted two primary motivations for a POSITA to incorporate Wagner’s teachings. First, a POSITA seeking an alternative to IPSec for data confidentiality would be motivated to implement SSL, a well-known and widely adopted security protocol. Wagner highlights specific advantages of SSL over IPSec, such as improved resistance to certain cryptographic attacks, which would motivate its use. Second, for applications requiring maximum security, a POSITA would be motivated to use SSL in conjunction with IPSec by tunneling the SSL-encrypted payload within an IPSec packet. This layered approach, known in the art, would use SSL to protect the application data and IPSec to protect the network headers, offering enhanced security.
    • Expectation of Success: Given that SSL was a de facto standard for web traffic security, a POSITA would have readily understood how to apply it to the network architecture of RFC3104, either as a replacement for or as a supplement to IPSec, with a high expectation of success.

4. Key Claim Construction Positions

  • "secure connection": Petitioner proposed this term be construed as "one or more security associations." This construction was based on the patent specification, which describes IPSec as the basis for secure communication, and the prosecution history of a parent patent, where the applicant explicitly equated the term "security association" with a "secure connection."
  • "unique identity": Petitioner proposed this term be construed as "one or more parameters that uniquely identify a secure connection." This was argued to be consistent with the patent's examples, which identify the "unique identity" as comprising one or more SPI values and other security parameters. The core function of the identity, as claimed, is its capability to be used by an intermediate computer to find the recipient's address.

5. Relief Requested

  • Petitioner requested the institution of an inter partes review and the cancellation of claims 1-10 of Patent 9,712,502 as unpatentable under 35 U.S.C. §103.