PTAB

IPR2016-01180

Sony Mobile Communications Inc v. SSH Communications Security Oyj

Log In
Key Events
Petition
petition

1. Case Identification

2. Patent Overview

  • Title: Maintaining Network Address Translation in Packet-Based Communications
  • Brief Description: The ’578 patent describes methods and systems for maintaining a network address translation (NAT) mapping in an intermediate network device, such as a router or firewall. The core concept involves a device transmitting data packets frequently enough to prevent the NAT device's timer from expiring and deleting the corresponding address mapping from its cache.

3. Grounds for Unpatentability

Ground 1: Claims 1-15 are obvious over Mayes in view of RFC 1631 and the TFTP References.

  • Prior Art Relied Upon: Mayes (Patent 5,793,763), RFC 1631 (a 1994 IETF standard for NAT), and the TFTP References (RFC 783 and a Cisco guide describing the Trivial File Transfer Protocol).
  • Core Argument for this Ground:
    • Prior Art Mapping: Petitioner argued that Mayes disclosed a NAT system where address mappings, called "translation slots," are stored in a table and time out after a default period of 24 hours. Mayes explicitly taught that a timestamp for each slot is updated each time a packet passes through the NAT, which resets this timeout period. The TFTP References disclosed a widely used protocol for file transfers that sends frequent User Datagram Protocol (UDP) packets. Petitioner contended that using the standard TFTP protocol through the Mayes NAT would inherently result in packet transmissions far more frequent than the 24-hour timeout, thereby preventing the deletion of the mapping and rendering the claims obvious. The use of normal data packets for this purpose was argued to meet the limitations of dependent claims requiring "other packets than specific keepalive packets."
    • Motivation to Combine: A person of ordinary skill in the art (POSITA) would combine these references because TFTP was a standard, well-known protocol, and the NAT described in Mayes was designed to be transparent to such standard network traffic. A POSITA would have been motivated to use a common file transfer protocol with a conventional NAT device to achieve a common goal, making the combination a predictable application of known technologies.
    • Expectation of Success: The combination involved applying existing technologies for their intended purposes. A POSITA would have had a high expectation of success that using TFTP through the Mayes NAT would function correctly, with the predictable and inherent result that the frequent packets would maintain the NAT mapping by resetting its timeout timer.

Ground 2: Claims 1-15 are obvious over Fan in view of RFC 1631 and the Packet Sending References.

  • Prior Art Relied Upon: Fan (Patent 6,219,706), RFC 1631, and the Packet Sending References (encompassing the TFTP References, the H.323 communication standard, and a book on Microsoft NetMeeting).
  • Core Argument for this Ground:
    • Prior Art Mapping: Petitioner asserted that Fan disclosed a firewall/router system with NAT functionality that maintains communication session data in "State Information Structures" (SISs). These SISs, which contain the NAT mappings, were taught to time out and be deleted if no packets for the session are received within a configurable period (e.g., 30 seconds for UDP). Fan explicitly stated that its firewall "restarts the appropriate timer when the next packet for that session is received." The Packet Sending References, particularly the H.323 standard for voice and video conferencing, described applications that transmit packets at a very high frequency (e.g., 50 packets per second). Petitioner argued that using applications based on H.323 or TFTP with Fan's system would necessarily maintain the NAT mapping by sending packets far more frequently than Fan's short timeout period.
    • Motivation to Combine: Fan expressly taught the recognition and processing of both H.323 and TFTP traffic for security inspection purposes. A POSITA would have been directly motivated to use these common communication protocols in a network protected by the Fan device, as Fan was specifically designed to accommodate and analyze this traffic. The combination represented the intended use of the Fan firewall with the very protocols it was built to handle.
    • Expectation of Success: Since the Fan device was explicitly designed to be compatible with H.323 and TFTP, a POSITA would have had a very high expectation of success in combining them. The outcome of maintaining the NAT mapping was a direct and foreseeable consequence of the high packet rate of these protocols interacting with Fan's packet-based timeout reset mechanism.

4. Key Claim Construction Positions

  • "specific keepalive packets" (claims 2, 7, 12): Petitioner argued this term should be construed to mean "a packet that is transmitted for the sole purpose of maintaining an address mapping." This construction was asserted to be critical, as it strictly excludes ordinary data packets. This distinction allowed Petitioner to argue that the prior art systems, which use the flow of normal data traffic to reset NAT timers, satisfied the claim limitation requiring the use of "other packets than specific keepalive packets."
  • "any intermediate device" (claims 1, 6, 11): Petitioner proposed this phrase should be construed as "every NAT device that is found in the path traversed by a packet." This interpretation was important to the Petitioner's argument because it meant that a prior art system with only a single NAT device would still meet the limitation. In such a system, any transmitted packet would necessarily act on every NAT device in its path (i.e., the one and only NAT device), thereby satisfying the claim language as construed.

5. Relief Requested

  • Petitioner requested institution of an inter partes review and cancellation of claims 1-15 of Patent 9,071,578 as unpatentable under 35 U.S.C. §103.