PTAB

IPR2019-00823

Apple Inc v. MPH Technologies Oy

Log In
Key Events
Petition

1. Case Identification

2. Patent Overview

  • Title: Method and System for Sending a Message Through a Secure Connection
  • Brief Description: The ’494 patent describes a method 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 that change network addresses, proposing a single end-to-end secure connection managed by the intermediate computer.

3. Grounds for Unpatentability

Ground 1: Claims 1-5 and 8-11 are obvious over RFC3104 and Grabelsky

  • Prior Art Relied Upon: RFC3104 (an Oct. 2001 Internet Society publication) and Grabelsky (Patent 7,032,242).
  • Core Argument for this Ground:
    • Prior Art Mapping: Petitioner argued that RFC3104, which discloses mechanisms for end-to-end IPSec in a Realm Specific IP (RSIP) context, teaches the core limitations of claim 1. RFC3104’s architecture, featuring an RSIP server (“intermediate computer”) forwarding packets between a host Y (“mobile computer”) and a host X (“destination address”) in different address spaces, was presented as the claimed system. Petitioner asserted that RFC3104 teaches receiving a secure message with an encrypted payload, as it describes establishing an IPSec Security Association (SA) and sending IPSec packets. The “unique identity” of the message, used for routing, was mapped to the “minimum tuple of demultiplexing fields” (including protocol, SPI, and destination IP address) that RFC3104’s intermediate server uses to find a matching mapping and tunnel the packet. Critically, this process does not require the intermediate computer to have the cryptographic key to decrypt the payload. Grabelsky was introduced to supply standard implementation details that a POSITA would have used to implement RFC3104. Specifically, Grabelsky provided exemplary IPSec packet formats (disclosing the precise location of fields like SPI and destination address) and taught the use of translation tables to map SPI values to local destination addresses, fulfilling the “translation table” limitation.
    • Motivation to Combine: A POSITA implementing the system of RFC3104 would combine it with Grabelsky to obtain well-known, standard implementation details for IPSec packet formats and efficient mapping mechanisms. Petitioner contended this combination involves applying known techniques to a known system to yield predictable results.
    • Expectation of Success: A POSITA would have a high expectation of success because Grabelsky’s disclosure of standard packet formats and translation tables represented common, compatible techniques for implementing the IPSec-based system described in RFC3104.

Ground 2: Claims 6-7 are obvious over RFC3104, Grabelsky, and Wagner

  • Prior Art Relied Upon: RFC3104, Grabelsky (Patent 7,032,242), and Wagner (a Nov. 1996 USENIX publication).
  • Core Argument for this Ground:
    • Prior Art Mapping: This ground built upon the RFC3104 and Grabelsky combination to address the limitations of dependent claims 6 and 7, which recite using an SSL or TLS protocol. Petitioner noted the ’494 patent itself provides no guidance on how to integrate SSL/TLS with the claimed IPSec-based method. Wagner was introduced as a reference that provides a detailed analysis of the SSL 3.0 protocol, its widespread adoption for secure communications, and its advantages compared to IPSec, such as improved resistance to certain attacks. Petitioner argued that a POSITA would have been aware of SSL as a prominent security protocol and would have understood how to apply it to the architecture of RFC3104 to establish a secure connection between the end hosts.
    • Motivation to Combine: A POSITA would combine Wagner’s teachings with the RFC3104/Grabelsky system for two primary reasons. First, a POSITA would have been motivated to implement SSL as a known and viable alternative to IPSec for data confidentiality, particularly given Wagner's discussion of SSL's advantages. Second, a POSITA would have been motivated to use SSL in conjunction with IPSec (e.g., tunneling SSL inside IPSec) to achieve layered, enhanced security for highly sensitive data, a known technique in the art.
    • Expectation of Success: A POSITA would have a reasonable expectation of success in implementing an SSL session within the RFC3104 architecture, as Wagner provided sufficient protocol details, and applying known security protocols like SSL to network communications was a common practice.

4. Key Claim Construction Positions

  • "unique identity": Petitioner argued this term should be construed as “one or more parameters that uniquely identify a secure connection.” This construction was central to the invalidity arguments because it allowed the “minimum tuple of demultiplexing fields” disclosed in RFC3104 (e.g., protocol, SPI, and destination IP address) to satisfy the “unique identity” limitation of the claims. Petitioner asserted that the ’494 patent specification supports this interpretation by providing examples where the unique identity includes the SPI value and other security parameters.

5. Relief Requested

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