PTAB
IPR2019-00819
Apple Inc v. MPH Technologies Oy
Key Events
Petition
Table of Contents
petition
1. Case Identification
- Case #: IPR2019-00819
- Patent #: 7,620,810
- Filed: March 27, 2019
- Petitioner(s): Apple Inc.
- Patent Owner(s): MPH Technologies Oy
- Challenged Claims: 1-7
2. Patent Overview
- Title: Method and Network for Ensuring Secure Forwarding of Messages
- Brief Description: The ’810 patent discloses a method for maintaining a secure Internet Protocol Security (IPSec) connection for a mobile terminal as it changes IP addresses. The invention proposes that the mobile terminal sends a request to an "other terminal" or security gateway to update the address definition of the secure connection, thereby avoiding a full, computationally expensive re-negotiation of the Security Association (SA).
3. Grounds for Unpatentability
Ground 1: Claims 1, 4-5, and 7 are obvious over Ishiyama and Murakawa.
- Prior Art Relied Upon: Ishiyama (Patent 6,904,466) and Murakawa (Patent 7,028,337).
- Core Argument for this Ground:
- Prior Art Mapping: Petitioner argued that Ishiyama teaches almost every element of the independent claims. Ishiyama describes a mobile communication system where a mobile computer, upon changing its "Care-of address," sends a request to a "correspondent host" to update the endpoint address of an established IPSec tunnel. This maintains the secure connection without renegotiating the SA. Petitioner contended a person of ordinary skill in the art (POSITA) would understand Ishiyama's "correspondent host" to be a "security gateway" because Ishiyama explicitly states it utilizes IPSec "tunnel mode," which, as admitted in the ’810 patent, is used when one end of an SA is a security gateway. Murakawa was introduced to explicitly disclose the claimed "other terminal" residing behind the security gateway, illustrating a standard VPN configuration where an external mobile terminal communicates through a gateway to access internal network terminals.
- Motivation to Combine: A POSITA seeking to implement Ishiyama's address-updating technique, which relies on IPSec tunnel mode, would be motivated to consult references like Murakawa that show a conventional and well-understood implementation of that mode. Murakawa provides the necessary context of using a security gateway to tunnel communications to an "other terminal." Combining them would have been a predictable implementation to ensure the mobile terminal's session with the end terminal is not interrupted during roaming.
- Expectation of Success: The combination involved applying Ishiyama’s specific address-updating method to Murakawa’s standard security gateway architecture. Petitioner argued that since both systems use IPSec tunnel mode, a POSITA would have reasonably expected that integrating these known elements would successfully maintain a secure, uninterrupted session for a roaming device.
Ground 2: Claims 2 and 3 are obvious over Ishiyama, Murakawa, and Ahonen.
- Prior Art Relied Upon: Ishiyama (Patent 6,904,466), Murakawa (Patent 7,028,337), and Ahonen (Patent 6,976,177).
- Core Argument for this Ground:
- Prior Art Mapping: This ground builds on the combination in Ground 1 to address dependent claims 2 and 3, which add the limitation of the security gateway sending a "reply message" back to the mobile terminal to confirm the address change. Petitioner asserted that while Ishiyama and Murakawa provide the core system, they do not explicitly teach a confirmation message. Ahonen, which addresses the same problem of mobile hosts roaming between networks using IPSec, was introduced because it explicitly discloses this feature. In Ahonen, after a mobile host sends an address update request, a firewall (security gateway) sends back an "ACK" (acknowledgement) message to confirm the update was successful, after which the mobile host can resume sending traffic.
- Motivation to Combine: A POSITA implementing the system of Ishiyama and Murakawa would be motivated to add a confirmation mechanism for reliability. Standard network protocols frequently use acknowledgment messages to ensure requests are successfully processed. Ahonen provided a direct, off-the-shelf solution for adding such a reply message in the specific context of mobile IPSec address updates. This would ensure the mobile terminal does not attempt to transmit data from its new address before the gateway has updated its records, thus preventing data loss and improving session stability.
Ground 3: Claim 6 is obvious over Ishiyama, Murakawa, and Forslöw.
- Prior Art Relied Upon: Ishiyama (Patent 6,904,466), Murakawa (Patent 7,028,337), and Forslöw (Patent 6,954,790).
- Core Argument for this Ground:
- Prior Art Mapping: This ground targets dependent claim 6, which requires the "other terminal" to be a "mobile terminal." The primary combination of Ishiyama and Murakawa shows a mobile terminal communicating with a stationary terminal on a LAN. Forslöw was introduced because it describes a "mobile workgroup system" where multiple mobile client devices communicate with each other securely using IPSec-based VPN tunnels, sometimes through a central mobile service router. This explicitly teaches the mobile-to-mobile communication scenario recited in claim 6.
- Motivation to Combine: A POSITA would have been motivated to extend the functionality of the Ishiyama/Murakawa system to support mobile-to-mobile communications, a common and desirable use case. To broaden the system's capabilities, it would be obvious to allow the "other terminal" to be a mobile device instead of a fixed one. Forslöw demonstrated that such configurations were known and provided a blueprint for implementing secure, mobile-to-mobile connectivity using the same underlying IPSec technology.
4. Key Technical Contentions (Beyond Claim Construction)
- Misunderstanding of IPSec Tunnel Mode: A central contention was that the patent examiner during original prosecution fundamentally misunderstood the teachings of the prior art, particularly Ishiyama. Petitioner argued that Ishiyama’s explicit disclosure of using IPSec "tunnel mode" would have immediately signaled to a POSITA that a security gateway architecture was being used to provide access to another network or terminal. Petitioner asserted this understanding was common knowledge and even admitted in the ’810 patent’s background, and that the examiner’s failure to appreciate this is what led to the improper allowance of the claims.
5. Relief Requested
- Petitioner requests institution of an inter partes review and cancellation of claims 1-7 of the ’810 patent as unpatentable.
Analysis metadata