`
`
`
`
`Case IPR2019-00821
`Patent 8,037,302
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`APPLE INC.,
`Petitioner,
`
`v.
`
`MPH TECHNOLOGIES OY,
`Patent Owner.
`____________
`
`Case IPR2019-00821
`Patent 8,037,302
`____________
`
`
`PATENT OWNER’S RESPONSE
`TO PETITION FOR INTER PARTES REVIEW
`
`
`
`
`
`
`
`TABLE OF CONTENTS
`
`Case IPR2019-00821
`Patent 8,037,302
`
`Page
`
`I.
`II.
`
`INTRODUCTION ........................................................................................ 1
`OVERVIEW OF THE ’302 PATENT AND THE STATE OF THE
`ART AT THE TIME OF THE INVENTION ............................................ 4
`A. Technical Background ........................................................................... 5
`B. The Mobility Problem Addressed by the ’302 Patent ......................... 10
`C. The ’302 Patent’s Solution to the Mobility Problem .......................... 15
`III. CLAIM CONSTRUCTION ....................................................................... 18
`A.
`Secure Connection ............................................................................... 19
`B. Establishing ......................................................................................... 22
`IV. CLAIMS 1-13 AND 16 ARE PATENTABLE OVER THE
`COMBINATION OF AHONEN AND ISHIYAMA (GROUND 1) ...... 23
`A. Overview of Ahonen .......................................................................... 23
`B. Overview of Ishiyama ....................................................................... 27
`C. The Petition Fails to Establish That The Asserted References
`Teach “Establishing A Second Secure Connection Extending
`Between A Second Network Address Of The First Terminal
`And The Original Network Address Of The Second Terminal” .. 31
`1.
`The Petition Fails To Establish That Ahonen Teaches
`“Establishing A Second Secure Connection Extending
`Between A Second Network Address Of The First Terminal
`And The Original Network Address Of The Second
`Terminal” .................................................................................. 32
`Ahonen’s Mobile Host Pre-Creates Security Associations
`from a Fixed Address ................................................................ 38
`i
`
`2.
`
`
`
`
`
`Case IPR2019-00821
`Patent 8,037,302
`
`D. The Petition Fails to Establish that the Asserted References
`Teach the “First Terminal Checking Whether the Second
`Secure Connection Already Exists” ................................................. 43
`E. The Petition Fails to Establish that the Asserted References
`Teach “Establishing A First Secure Connection As Being An
`Active Connection”............................................................................ 48
`F. The Petition Fails to Establish that the Asserted References
`Teach the Inventions Defined by Dependent Claims 2-13 and
`16 ......................................................................................................... 53
`CLAIMS 14 AND 15 ARE PATENTABLE OVER THE
`COMBINATION OF AHONEN, ISHIYAMA AND GUPTA
`(GROUND 2) ............................................................................................... 53
`VI. CONCLUSION ........................................................................................... 54
`
`
`V.
`
`
`
`
`
`
`
`
`
`ii
`
`
`
`
`
`COURT DECISIONS
`
`Case IPR2019-00821
`Patent 8,037,302
`
`TABLE OF AUTHORITIES
`
`Page(s)
`
`Intamin Ltd. v. Magnetar Techs., Corp.,
`483 F.3d 1328 (Fed. Cir. 2007) .......................................................................... 21
`Phillips v. AWH Corp.,
`415 F.3d 1303 (Fed. Cir. 2005) (en banc) .......................................................... 49
`Ventana Med. Sys., Inc. v. BioGenex Labs., Inc.,
`473 F.3d 1173 (Fed. Cir. 2006) .......................................................................... 20
`Williamson v. Citrix Online, LLC,
`792 F.3d 1339 (Fed. Cir. 2015) .......................................................................... 20
`
`AGENCY DECISIONS
`
`Bright House Networks, LLC et al, v. Focal IP, LLC,
`IPR2016-01261, Paper 71 (PTAB Dec. 28, 2017) ............................................. 20
`
`
`
`
`
`
`
`
`
`iii
`
`
`
`
`
`Case IPR2019-00821
`Patent 8,037,302
`
`EXHIBIT LIST
`
`2001 U.S. Patent App. Pub. 2001/0009025 A1 (“Ahonen U.S. Pat. App. Pub.”)
`
`2002 Declaration of George N. Rouskas
`
`2003 CV of George N. Rouskas
`
`2004 The TCP/IP Guide – IPSec Security Associates and the Security
`Association Database, available at
`www.tcpipguide.com/free/t_IPSecSecurityAssociationsandtheSecurityAss
`ociation.htm (accessed January 7, 2020)
`
`
`
`iv
`
`
`
`
`
`Case IPR2019-00821
`Patent 8,037,302
`
`I.
`
`INTRODUCTION
`At the time of the claimed invention at issue in this case, communication
`
`over the Internet and other networks was well established. For example, a first user
`
`of a desktop computer could communicate messages made up of packets to a
`
`second user at his/her desktop computer. The security of communications between
`
`computers (and other devices such as mobile phones) was, however, a significant
`
`issue. For example, users wanted to prevent third parties from accessing or
`
`altering the content of their communications.
`
`One approach to providing security was to deliver packets by a secure
`
`connection using the “Internet Protocol Security” (IPSec) protocols. IPSec allowed
`
`user devices to securely communicate packets over networks in a manner designed
`
`to prevent third parties from accessing and tampering with the content, and that
`
`could even protect the anonymity of the users. An IPSec secure connection could
`
`extend through multiple networks and could pass through intermediary devices
`
`connecting networks such as routers or gateways.
`
`Such an IPSec connection is created using a “Security Association” (SA)
`
`that defines the nature of the secure connection, such as the encryption/decryption
`
`keys, encryption/decryption algorithms, authentication algorithms, and other
`
`security parameters. SAs are also tied to a specific destination network address (IP
`
`1
`
`
`
`
`
`Case IPR2019-00821
`Patent 8,037,302
`
`address). Therefore, a first terminal seeking to establish an IPSec secure
`
`connection with a second terminal at address X would need an SA specifying
`
`address X as the destination.
`
`At the time of the invention, the existence of mobile terminals—terminals
`
`that could change networks and acquire new IP addresses—was well known. But,
`
`such terminals presented an obstacle to using IPSec secure connections because
`
`they were tied to a specific IP address. If a mobile terminal communicating with a
`
`second terminal over an IPSec connection changed its IP address from X to Y, the
`
`existing SA could no longer be used. This would then require the negotiation of a
`
`new SA for the IPSec connection, a process which is both time-consuming and
`
`computationally demanding. The challenge of using IPSec where terminals change
`
`IP addresses was sometimes referred to as the “mobility problem.” See infra
`
`§ II-B.
`
`The invention provides a solution that allows a first terminal to switch from
`
`a first network address to a second network address without having to reestablish a
`
`secure connection. A first secure connection is established between a first network
`
`address of the first terminal and an address of a second terminal. A second secure
`
`connection is also established between a second network address of the first
`
`terminal and the address of a second terminal. After the first terminal changes to
`
`2
`
`
`
`
`
`Case IPR2019-00821
`Patent 8,037,302
`
`the second network address, it checks whether the second secure connection
`
`already exists. If the second secure connection already exists, the second terminal
`
`registers the already established second connection as being the active connection
`
`without having to reestablish the second secure connection.
`
`The Petition asserts in Ground 1 that independent claim 1 is obvious based
`
`on Ahonen (Ex. 1004) and Ishiyama (Ex. 1005). The Petition’s arguments
`
`regarding the remaining challenged claims, claims 2-16, each of which depend
`
`from claim 1, rely on the Petition’s arguments regarding claim 1. The Petition,
`
`however, fails to demonstrate by a preponderance of the evidence that claim 1, or
`
`any of its challenged dependent claims, are unpatentable for at least three
`
`independent reasons.
`
`First, the Petition fails to demonstrate, and Ahonen fails to disclose,
`
`establishing secure connections from different addresses of a first terminal, as
`
`required by the claims. See infra Section IV.C.1. In fact, a POSITA would
`
`understand that Ahonen’s alleged establishing secure connections occurs using the
`
`same address of the alleged first terminal. See infra Section IV.C.2.
`
`Second, the Petition fails to demonstrate that the asserted Ahonen/Ishiyama
`
`combination teaches a first terminal checking whether a second secure connection
`
`already exists, as required by the claims. See infra Section IV.D.
`
`3
`
`
`
`
`
`Case IPR2019-00821
`Patent 8,037,302
`
`Third, the Petition fails to demonstrate that Ahonen teaches establishing a
`
`first secure connection as an active connection, as required by the claims. See infra
`
`Section IV.E.
`
`For each of these three, independent reasons, discussed further below, the
`
`Petition fails to demonstrate by a preponderance of the evidence that any of the
`
`challenged claims 1-16 are unpatentable.
`
`II.
`
`OVERVIEW OF THE ’302 PATENT AND THE STATE OF THE ART
`AT THE TIME OF THE INVENTION
`For clarity to the reader, citations will adhere to these formats:
`
` Petitions and other papers filed by the parties will be abbreviated.
`
`Example: Pet., at 10, 12 refers to the Petition at pages 10 and 12.
`
` Patents will be cited by their exhibit number, bates stamped page and
`
`specific column and line numbers. Example: Ex. 1005 [Ishiyama]
`
`0011 (1:10-12) refers to the Ishiyama patent at page 0011 and Col. 1,
`
`lines 10-12.
`
` Articles and other publications will be cited by their exhibit number,
`
`bates stamped page and their original page number (and line numbers
`
`or paragraph numbers, if appropriate). Ex. 1007 [RFC 2401] 5.
`
`4
`
`
`
`
`
`A. Technical Background
`
`Case IPR2019-00821
`Patent 8,037,302
`
`In order to orient the Board regarding the issues in this response, some
`
`highly pertinent background of the claimed invention is next discussed with as
`
`much brevity as possible in light of the arguments to be addressed.
`
`Telecommunications networks can encompass a vast array of components
`
`including local area networks (LANs), wide area networks (WANs) and various
`
`computing devices all interconnected using intermediary networking devices.
`
`Intermediary networking devices such as routers enable different networks to be
`
`interconnected so as to function as an “internetwork,” that is, as an internet. Such
`
`interconnected networks can allow geographically dispersed users to communicate.
`
`Ex. 1001 [’302 Patent] 0004 (1:20-24).
`
`Normally, a person who mails a sealed letter does not want and does not
`
`expect that the contents of the letter will be read by a third party while the letter is
`
`en route to the intended recipient. In a similar manner, those parties who exchange
`
`communications between a first terminal and a second terminal want to protect the
`
`confidentiality and integrity of the information they are exchanging. The patented
`
`inventions help permit similar security expectations to be satisfied in new,
`
`complex, and challenging computer functionality contexts.
`
`5
`
`
`
`
`
`Case IPR2019-00821
`Patent 8,037,302
`
`The ’302 Patent explains that IPSec is a technology to secure the
`
`communications of messages across networks:
`
`The IP security protocols (IPSec) provides the capability to secure
`communications across a LAN, across private and public wide area
`networks (WANs) and across the internet. IPSec can be used in
`different ways, such as for building secure virtual private networks, to
`gain a secure access to a company network (as remote access IPSec
`use), or to secure communication with other organisations, ensuring
`authentication and confidentiality and providing a key exchange
`mechanism. Even if some applications already have built in security
`protocols, the use of IPSec further enhances the security. Ex. 1001
`[’302 Patent] 0004 (1:38-48).
`
`At the time of the invention, IPSec was described in “Security Architecture
`
`for the Internet Protocol,” issued by the Internet Engineering Task Force (IETF)
`
`Network Working Group as RFC 2401. See Ex. 1007 [Security Architecture for the
`
`Internet Protocol] (November 1998).
`
`RFC 2401 describes the fundamental features and processes of IPSec secure
`
`connections:
`
`This memo specifies the base architecture for IPsec compliant systems.
`The goal of the architecture is to provide various security services for
`traffic at the IP layer . . . The following fundamental components of the
`
`6
`
`
`
`
`
`Case IPR2019-00821
`Patent 8,037,302
`
`IPsec security architecture are discussed in terms of their underlying,
`required functionality . . .
`
`a. Security Protocols -- Authentication Header (AH) and
`Encapsulating Security Payload (ESP)
`
`b. Security Associations -- what they are and how they work,
`how they are managed, associated processing
`
`
`
`c. Key Management -- manual and automatic (The Internet Key
`Exchange (IKE))
`
`d. Algorithms for authentication and encryption
`
`Id., [Section 1.1: Summary of Contents of Document] 3.
`
`RFC 2401 is cited in the ’302 Patent. Ex. 1001 [’302 Patent] 0006 (6:14-16).
`
`The ’302 Patent provides a detailed explanation of the features of IPSec:
`
`IPSec can encrypt and/or authenticate traffic at IP level. Traffic going
`in to a WAN is typically encrypted and/or authenticated and traffic
`coming from a WAN is decrypted and/or authenticated. . . . Two
`protocols are used to provide security at the IP layer, an authentication
`protocol designated by the header of the protocol, Authentication
`Header (AH), and a combined encryption/authentication protocol
`designated by the format of the packet for that protocol, Encapsulating
`Security Payload (ESP). Both AH and ESP are vehicles for access
`control based on the distribution of cryptographic keys and the
`management of traffic flows related to these security protocols.
`
`Ex. 1001 [’302 Patent] 0004 (1:49-61).
`
`7
`
`
`
`
`
`Case IPR2019-00821
`Patent 8,037,302
`
`The ’302 Patent describes fundamental concepts of IPSec secure
`
`connections. For example, Security Associations (SAs) are data structures that are
`
`fundamental to IPSec processing. Ex. 1001 [’302 Patent] (1:62-2:19). RFC 2401
`
`also discloses SAs as fundamental to IPSec processing. Ex. 1007 [RFC 2401] 3.
`
`The ’302 Patent explains that a SA defines a one-way security relationship
`
`that protects the message traffic sent from sender to a receiver. If a two-way secure
`
`connection between the sender and receiver is desired, then two SA definitions are
`
`required. In some cases multiple SAs, referred to as an “SA bundle,” are used in
`
`IPSec to protect a data packet being sent from one address to another. In the ’302
`
`Patent, the term “IPsec connection” encompasses an IPSec bundle or IPSec
`
`bundles (e.g., one for each direction) of SAs that define the security protocols that
`
`will be employed for message traffic between two host devices, for example. Ex.
`
`1001 [’302 Patent] 0004 (1:62-2:8).
`
`The ’302 Patent discloses that an SA is uniquely defined by three
`
`parameters: (1) the Security Parameters Index (SPI), (2) the IP destination address
`
`(Dst), and (3) the IPSec security protocol type (which can be an AH
`
`[Authentication Header] or an ESP [Encapsulated Security Payload]). Ex. 1001
`
`[’302 Patent] 0004 (2:9-19). For each IPSec connection, a Security Association
`
`Database (SADB) stores the information for each SA, including items (1)-(3)
`
`8
`
`
`
`
`
`Case IPR2019-00821
`Patent 8,037,302
`
`above, as well as information defining the authentication algorithms, encryption
`
`algorithms, keys and related parameters that are used to cryptographically protect
`
`the message traffic over the IPSec secure connection. Id., 0007 (7:45-53); see also
`
`Ex. 2002 [Rouskas Decl.], ¶47.
`
`The ’302 Patent explains that IPSec secure connections support two modes:
`
`transport mode and tunnel mode. Transport mode protection protects the IP packet
`
`payload, not the entire IP packet including header information. Tunnel mode
`
`provides more complete protection by creating an outer packet with a new IP
`
`header that protects everything within it, which is effectively treated as a payload
`
`of the outer packet. For the tunnel mode, the original packet can be represented as
`
`an IP datagram in the form of IP|payload. Next, a new IP header is added to the
`
`original packet, yielding IP|IP|payload. The original packet is then secured using
`
`either IPSec AH protocol or ESP protocol. If ESP is applied, the resulting packet is
`
`IP|ESP|IP|payload. Notably, the IP header of the outer packet can have source and
`
`destination addresses that are completely different from the source and destination
`
`addresses of the encapsulated inner packet. For example, if the outer packet source
`
`is A and its destination is B, the inner packet travels within a tunnel from A to B
`
`without its contents being exposed along the way by intervening routers that
`
`9
`
`
`
`
`
`Case IPR2019-00821
`Patent 8,037,302
`
`eventually forward the packet to its outer packet destination of B. See Ex. 1001
`
`[’302 Patent] 0004 (2:20-54).
`
`As explained in the ’302 Patent, the tunnel mode is often used if one or both
`
`of the IPSec secure connection endpoints is a security gateway (SG), i.e., if the
`
`connection is SG-SG or SG-host (SG-terminal). Tunnel mode is also often used for
`
`end-to-end communication between a host and a mobile terminal without the use
`
`of a security gateway. An SG encompasses intermediary devices implementing
`
`IPSec such as firewalls and routers. IPSec’s transport mode may be used if the
`
`ends of the SA connection are host-host. Ex. 1001 [’302 Patent] 0004 (2:22-38).
`
`As referenced in RFC 2401 (see Ex. 1007, 3), an essential aspect of IPSec is
`
`key management. Key management includes the determination and distribution of
`
`secret keys that are used for IPSec secure connections. The default key
`
`management protocol for IPSec is Internet Key Management (IKE), which is an
`
`extensible protocol that supports the Diffie-Hellman algorithm for shared secret
`
`keys, the RSA algorithm for signature authentication, and other security modes.
`
`Ex. 1001 [’302 Patent] 0005 (3:8-18).
`
`B.
`
`The Mobility Problem Addressed by the ’302 Patent
`
`As described in the ’302 Patent, one of the drawbacks of conventional IPSec
`
`security processing is that it is intended to work with static network topology
`
`10
`
`
`
`
`
`Case IPR2019-00821
`Patent 8,037,302
`
`where the IPSec secure connection has fixed endpoints. Indeed, an SA that defines
`
`a secure connection in IPSec is tied to specific IP addresses, and, if an address of
`
`one endpoint changes, a new SA must be negotiated. Ex. 1001 [’302 Patent] 0005
`
`(3:19-30).
`
`The challenge of IP mobility, i.e., how to enable terminals to securely
`
`communicate even when one terminal changes to a new address, is described in the
`
`’302 Patent:
`
`The fundamental problem with IP mobility is the fact that IP routing is
`based on fixed addresses. The address space has been divided into
`subnetworks, that reside in practically fixed locations with respect to
`network topology (the routing can be changed, but that is a slow
`process, possibly in the order of minutes). When a mobile host moves
`away from its home network (where its IP address is proper), there is a
`problem with the routing of the packets to the new location if the IP
`network in question does not support such movement. Ex. 1001 [’302
`Patent] 0005 (3:42-50).
`
`The IPSec protocol solves the known security problems of the Internet
`Protocol (IP) in a satisfactory manner. However, it is designed for a
`static Internet, where the hosts using IPSec are relatively static. Thus,
`IPSec does not work well with mobile devices. For instance, if a mobile
`terminal moves from one network to another, an IPSec connection set
`up is required, typically using the IKE key exchange protocol. Such a
`set up is expensive in terms of latency, since IKE may require several
`11
`
`
`
`
`
`Case IPR2019-00821
`Patent 8,037,302
`
`seconds to complete. It is also expensive in terms of computation,
`because the Diffie-Hellman and authentication-related calculations of
`IKE are extremely time consuming. Ex. 1001 [’302 Patent] 0005 (4:52-
`63).
`
`This issue, sometimes referred to as the “mobility problem,” most often
`
`arises when an endpoint is a mobile host that leaves one network and attaches to a
`
`second network with a new IP address. Ex. 2002 [Rouskas Decl.] ¶ 53. In that case,
`
`the mobile host can no longer sustain its IPSec secure connection because the
`
`previously used SA is no longer valid. Ex. 1001, [’302 Patent] 0008 (Col. 4:12-39).
`
`In that instance, the mobile host changing addresses would require the negotiation
`
`of a new SA for the IPSec connection, a process which is both time-consuming and
`
`computationally demanding.
`
`The ’302 Patent describes that the mobility issue can be addressed using
`
`Mobile IP as follows:
`
`In IP-IP tunnelling, an IP address (the so called co-located care-of
`address) is borrowed from a network being visited. This address is
`topologically correct, i.e. routable from other parts of the network.
`When a mobile terminal needs to send a packet to a given target
`computer, it first constructs an IP packet, whose source address is
`its home address, i.e. the address that is not topologically correct in the
`new network, and whose destination address is the target computer.
`Since this packet may not be directly routable, it is encapsulated into
`12
`
`
`
`
`
`Case IPR2019-00821
`Patent 8,037,302
`
`another IP packet (by so called IP-IP encapsulation, or IP-IP
`tunnelling). The source address of this IP packet is the care-of
`address, and the target address is the so called home server of the
`mobile terminal. Upon receiving such an encapsulated packet, the
`home server unwraps the IP-IP tunnel, and proceeds to route the packet,
`which was inside the encapsulation.
`
`Ex. 1001 [’302 Patent] 0005 (4:4-20) (emph. added). Furthermore:
`
`Reverse packets from the target computer to the mobile terminal are
`handled similarly; the packet is first routed to the home server, then
`encapsulated in IP-IP and delivered to the current network the mobile
`terminal is in. The current mobility binding determines which current
`care-of address matches a given home address.
`
`Ex. 1001 [’302 Patent] 0005 (4:21-29).
`
`When the mobile terminal moves to a new network, an authenticated
`signalling message exchange is done between the mobile terminal
`and the home server. A Registration Request is sent by the mobile
`terminal to the home server, requesting an update of the current
`mobility binding. The server responds using a Registration Reply that
`may either accept or deny the request. When the Foreign Agent mode
`of operation is used, the registration messages go through the Foreign
`Agent.
`
`Ex. 1001 [’302 Patent] 0005 (4:30-38) (emph. added).
`
`13
`
`
`
`
`
`Case IPR2019-00821
`Patent 8,037,302
`
`The Mobile IP approach using IP-IP tunneling described above is depicted in
`
`Figure 1 of the ’302 Patent:
`
`
`
`Ex. 1001 [’302 Patent] 0002 (Fig. 1) (annotated). Step 5 of Figure 1 is a request
`
`IP|RREQ for the home server to change the care-of address of the mobile terminal
`
`(e.g., from CoA1 to CoA2). Step 6 is a response IP|RREP that indicates whether
`
`the new care-of address was accepted. Ex. 1 [’302 Patent] 0002 (Fig. 1), 0005
`
`(4:30-38).
`
`The ’302 Patent explains some of the drawbacks associated with using then-
`
`existing Mobile IP to address the mobility issue. “The standard Mobile IP protocol
`
`14
`
`
`
`
`
`Case IPR2019-00821
`Patent 8,037,302
`
`provides a mobile terminal with a mobile connection, and defines mechanisms for
`
`performing efficient handovers from one network to another. However, Mobile IP
`
`has several disadvantages” (Ex. 1001 [’302 Patent] 0006 (5:1-4)) as described
`
`below:
`
`The security of Mobile IP is very limited. The mobility signalling
`messages are authenticated, but not encrypted, and user data traffic is
`completely unprotected. Also, there is no key exchange mechanism for
`establishing the cryptographic keys required for authenticating the
`mobility signalling. Such keys need to be typically distributed
`manually. In the manual prior art key management, the signalling
`authentication mechanism requires the mobile host and the home server
`to share a secret authentication key and the distribution of that key,
`which is carried out manually, is not very practical. Finally, the current
`Mobile IP protocol does not define a method for working through
`Network Address Translation (NAT) devices.
`
`Ex. 1004 [’302 Patent] 0006 (5:4-18).
`C. The ’302 Patent’s Solution to the Mobility Problem
`
`As described in connection with Figure 2, the ’302 Patent discloses a novel,
`
`innovative method for supporting mobile terminal communications:
`
`The method of the invention for ensuring secure forwarding of a
`message is performed in a telecommunication network, comprising at
`least one terminal from which the message is sent and at least one other
`terminal to which the message is sent. In the method, one or more
`
`15
`
`
`
`
`
`Case IPR2019-00821
`Patent 8,037,302
`
`secure connections are established between different addresses of
`the first terminal and [the] address of the other terminal, the
`connections defining at least said addresses of the two terminals. When
`the first terminal moves from one address to another address, a secure
`connection, whose endpoints are the new address of the first
`terminal and the address of the other terminal, is registered to be at
`least one of the active connections.
`
`Ex. 1001 [’302 Patent] 0007 (7:9-20) (emph. added).
`
`“The invention can be used for direct end-to-end communication, in which
`
`case the secure tunnel is established between these end computers,” and where
`
`“[i]n the preferred embodiment, IPSec security associations are used as secure
`
`connections.” Ex. 1001 [’302 Patent] 0007 (7:54-55). The secure connections that
`
`are created do not have to be IPSec SAs because “the secure connections are
`
`preferably established” with SAs using IPSec protocols. Ex. 1001 [’302 Patent]
`
`0007 (7:39-41). “If applied to IPSec, this could correspond to either an IPSec
`
`transport mode or tunnel mode SA” Ex. 1001 [’302 Patent] 0007 (8:37-40). “A
`
`secure connection, preferably an IPSec security association (SA) or more
`
`specifically one IPsec SA bundle for each direction of communication is
`
`established . . .” Ex. 1001 [’302 Patent] 0008 (10:13-15) [all emph. added].
`
`When secure connections are established between the first terminal and the
`
`second terminal they are registered for immediate and/or later use. Registration of
`16
`
`
`
`
`
`Case IPR2019-00821
`Patent 8,037,302
`
`secure connections for later use are preferably stored as IPSec SAs stored in a
`
`connection table which can be an SA database (SADB). “Thus, the connection
`
`table has a list of secure connections each defining a specific address of the first
`
`terminal and an address of the other terminal. The secure connection to be used,
`
`i.e., registered as the active connection, is determined using a signaling message
`
`request from the first terminal to the second terminal. There may also be a reply
`
`from the other terminal. Ex. 1001 [’302 Patent] 0007 (7:39-63); 0003 (Fig. 2).
`
`One benefit of the invention is that “[t]he IPSec symmetric encryption and
`
`authentication methods can be used to protect both signalling and data traffic.” Ex.
`
`1001 [’302 Patent] 0007 (8:55-56). Additionally, the authenticated traffic can also
`
`be “used as an implicit registration request.” Id., 0009 (11:31-33).
`
`Claim 1 of the ’302 Patent is directed to a method for ensuring secure
`
`forwarding of a message in a telecommunication network. Ex. 1001 [’302 Patent]
`
`0009 (12:15-43). This includes steps for establishing and registering secure
`
`connections between different address locations of a “first terminal” and an
`
`original address of a “second terminal.”
`
`Claim 1 requires establishing first and second secure connections between
`
`different network addresses of a first terminal and an original address of the second
`
`terminal. Ex. 1001 [’302 Patent] 0009 (12:19-25). In claim 1, the first secure
`
`17
`
`
`
`
`
`Case IPR2019-00821
`Patent 8,037,302
`
`connection is established as being an active connection between a first network
`
`address of the first terminal and an original address of the second terminal, and the
`
`second secure connection is established between the second network address of the
`
`first terminal and the original network address of the second terminal. Ex. 1001
`
`[’302 Patent] 0009 (12:19-25).
`
`The first terminal then moves from the first network address to the second
`
`network address, and it checks whether a secure connection (e.g., an IPSec security
`
`association in the preferred embodiment) already exists between the second
`
`address and the original network address of the second terminal. Ex. 1001 [’302
`
`Patent] 0008 (10:39-43). If an IPSec security association already exists between
`
`the new address of the first terminal and the second terminal, this security
`
`association is registered to be the actual security association to be used. Ex. 1001
`
`[’302 Patent] 0008 (10:51-56).
`
`III.
`
`CLAIM CONSTRUCTION
`Prior to institution, the Parties submitted arguments regarding the
`
`construction of the claim terms “secure connection,” and “establishing.” In its
`
`Institution Decision in this case on behalf of the Director, the Board found that it
`
`“need not decide whether a ‘secure connection’ should be limited to one or more
`
`SAs. Rather, it is sufficient that the parties do not dispute that a secure connection
`
`18
`
`
`
`
`
`Case IPR2019-00821
`Patent 8,037,302
`
`covers one or more SAs.” Instn., at 9. The Board similarly ruled that it “need not
`
`construe ‘establishing,’ as the manner in which Petitioner relies on the prior art is
`
`consistent with Patent Owner’s proposed construction of ‘forming a new.’” Id., at
`
`10.
`
`Patent Owner agrees that to the extent Petitioner’s positions do not conflict
`
`with Patent Owner’s proposed definitions of these terms, the terms need not be
`
`construed. Out of an abundance of caution, Patent Owner provides the following
`
`proposed constructions of these terms, “secure connection” and “establishing,” to
`
`be considered by the Board in the event that Petitioner attempts to take a new
`
`position in its Reply.
`
`A.
`
`Secure Connection
`
`Petitioner argues that “the terms ‘establishing a first secure connection’/
`
`‘establishing a second secure connection’ should be construed broadly enough to
`
`respectively include ‘establishing one or more first security associations’ and
`
`‘establishing one or more second security associations.’” To the extent that
`
`Petitioner provides new arguments in its reply, attempting to limit the term “secure
`
`connection” to only mean IPSec security associations would be improper.
`
`The Board and the Courts have recognized that while claims should be
`
`understood in light of the specification, they should not be limited to preferred
`
`19
`
`
`
`
`
`Case IPR2019-00821
`Patent 8,037,302
`
`embodiments in the specification. Bright House Networks, LLC et al, v. Focal IP,
`
`LLC, IPR2016-01261, Paper 71, 14 (PTAB Dec. 28, 2017) (“the court ‘has
`
`repeatedly cautioned against limiting the claimed invention to preferred
`
`embodiments or specific examples in the specification.’”) (quoting Williamson v.
`
`Citrix Online, LLC, 792 F.3d 1339, 1346–47 (Fed. Cir. 2015)); see also id. (“each
`
`claim does not necessarily cover every feature disclosed in the specification,” and
`
`“it is improper to limit the claim to other, unclaimed features.”) (quoting Ventana
`
`Med. Sys., Inc. v. BioGenex Labs., Inc., 473 F.3d 1173, 1181 (Fed. Cir. 2006). The
`
`claim limitations reciting “establishing a first secure connection” and “establishing
`
`a second secure connection” make no reference to security associations or IPSec.
`
`Furthermore, the specification repeatedly indicates that the secure connections of
`
`the invention do not have to be created using IPSec SAs, although it may be
`
`preferable in som
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
Still Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.
This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.
Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.
Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.
One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.
Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.
Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site
