`UNITED STATES PATENT AND TRADEMARK OFFICE
`________________________
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`________________________
`
`VIPTELA, INC.,
`Petitioner,
`
`v.
`
`FATPIPE NETWORKS PRIVATE LIMITED,
`Patent Owner.
`______________
`
`Case IPR2017-00684
`
`U.S. Patent No. 6,775,235
`____________
`
`RESPONSE TO PETITION FOR INTER PARTES REVIEW
`
`
`
`
`
`
`
`
`
`
`
`
`

`

`
`
`
`
`TABLE OF CONTENTS
`
`Patent Owner’s Response
`Case IPR2017-00684
`U.S. Patent No. 6,775,235
`
`
`B. 
`
`C. 
`
`I. 
`Introduction .................................................................................................. 1 
`II.  The ’235 patent ............................................................................................ 1 
`III.  Person of ordinary skill in the art ........................................................... 6 
`IV.  Claim construction ...................................................................................... 7 
`V.  Overview of Karol ........................................................................................ 8 
`VI.  Claims 6 and 22-24 are not anticipated by Karol. ............................. 15 
`A. 
`The item to be modified is the final destination IP
`address in the incoming packet. .................................................. 15 
`Protocol and header conversions do not require
`modifications to the destination IP address ............................. 17 
`The actual destination IP address in the incoming
`packet in is not modified in the protocol conversion
`process of Karol. .............................................................................. 23 
`Petitioner and Petitioner’s Expert improperly construe
`claim 6 by failing to understand the ’235 patent
`specification. ..................................................................................... 34 
`VII.  Claims 6 and 22-24 are not obvious over Karol. ................................ 38 
`VIII.  Claim 6 is patentable over Karol in view of Stallings. ..................... 41 
`IX.  Claims 5-6 and 22-24 are not anticipated by Karol or obvious
`over Karol alone or in view of Stallings. .............................................. 44 
`A.  Claims 5 and 22 are patentable over Karol alone or in
`view of Stallings. ............................................................................. 44 
`1. 
`Karol does not anticipate claim 5 or 22. .......................... 45 
`2. 
`Karol does not render obvious claim 5. ............................ 48 
`3. 
`Karol in view of Stallings does not render obvious
`claims 5 and 22. ..................................................................... 51 
`X.  Conclusion ................................................................................................... 55 
`
`D. 
`
`
`
`
`i
`
`

`

`
`
`
`
`TABLE OF AUTHORITIES
`
`Statutes
`
`Patent Owner’s Response
`Case IPR2017-00684
`U.S. Patent No. 6,775,235
`
`
`35 U.S.C. § 102……………………………………………….. 2
`
`35 U.S.C. § 103………………………………………… …..2, 3
`
`35 U.S.C. § 325(d)…………………………………..1, 2, 9, 10
`
`
`
`Rules
`
`37 C.F.R. § 42.107…………………………………………….1
`
`37 C.F.R. § 42.1(b)……………………………………………9
`
`
`
`
`
`
`ii
`
`

`

`
`
`
`
`Pursuant to 37 C.F.R. § 42.120 Exclusive Licensee, FatPipe, Inc.
`
`Patent Owner’s Response
`Case IPR2017-00684
`U.S. Patent No. 6,775,235
`
`
`(“FatPipe” or “Patent Owner”), submits this Response to Petition for
`
`Inter Partes Review (“Response”) to the Petition for Inter Partes Review
`
`of United States Patent No. 6,775,235 filed by Petitioner, Viptela, Inc.
`
`(“Viptela” or “Petitioner”).
`
`I.
`
`Introduction
`The technologies described by the prior art relied upon by the
`
`Petitioner and the subject matter described by claims 6 and 22-24 of the
`
`’235 patent differ fundamentally both in their purpose and their result.
`
`The differences are clear based on the plain meaning of these claims
`
`when viewed in light of the specification such that there is a stark
`
`deficiency in Petitioner’s analysis. This Response demonstrates that
`
`Karol and the additional prior art do not render the challenged claims
`
`unpatentable.
`
`II. The ’235 patent
`The ’235 patent describes a system that dynamically load-balances
`
`over WAN paths on disparate networks. Specifically, the ’235 patent is
`
`directed to a controller that interfaces with a site and “two or more
`
`disparate networks in parallel” to “provide load balancing across
`
`
`
`1
`
`

`

`
`
`Patent Owner’s Response
`Case IPR2017-00684
`U.S. Patent No. 6,775,235
`
`network connections, greater reliability, and/or increased security.” (Ex.
`
`
`
`1001, Abstract). The ’235 patent’s claimed invention represented a
`
`major advancement in the field of computer networking. (See, e.g., Ex.
`
`2011, p. 2). Sanchaita Datta, the first-named inventor on the ’235
`
`patent, was honored as a “Women Innovator” by the Women Tech
`
`Council for her major impact on technology for, among other things, the
`
`innovations claimed in the ’235 patent. (Ex. 2007).
`
`Prior art approaches did not combine two or more disparate
`
`networks in parallel to provide benefits such as dynamic per-packet
`
`load-balancing. (Ex. 1001, col. 4:40–45). Prior art Fig. 2 (below), for
`
`example, used a primary network (the frame relay network 106) and
`
`only used the secondary network (the ISDN network 204) when the
`
`primary network failed. (Ex. 1001, col. 3:18–28). The primary network
`
`path is used for most or all of traffic while the other path is used only
`
`when the primary path fails. (Ex. 1001, col. 9:55–65). The prior art
`
`configuration of Fig. 2 does not consider load balancing on a packet-by-
`
`packet basis, or provide security by splitting and distributing pieces of
`
`messages between disparate networks. (Ex. 1001, col. 9:65–10:3).
`
`
`
`2
`
`

`

`
`
`
`
`Patent Owner’s Response
`Case IPR2017-00684
`U.S. Patent No. 6,775,235
`
`
`
`
`(Ex. 1001, Fig. 2).
`
`Nor did prior art approaches provide dynamic load balancing over
`
`multiple disparate networks. (Ex. 1001, col. 2:56–65). Prior art Fig. 1
`
`(below), for example, requires that networks agree upon factors relating
`
`to communications prior to traffic being sent. (Ex. 1001, col. 2:52–55).
`
`They can provide a rough balance by sending different types of traffic or
`
`flows through particular routers (e.g., router A or router B), but this
`
`does not balance router loads dynamically in response to actual traffic.
`
`(Ex. 1001, col. 2:56–65). The prior art approaches required set-up with
`
`broad granularity and did not load balance dynamically in response to
`
`actual traffic. (Ex. 1001, col. 9:4–9). Other prior art approaches, such as
`
`
`
`3
`
`

`

`
`
`
`
`those described in Figs. 3 and 4 of the ’235 patent, did not provide
`
`Patent Owner’s Response
`Case IPR2017-00684
`U.S. Patent No. 6,775,235
`
`
`networks in parallel (Ex. 1001, col. 3:29–4:4) and could not provide load-
`
`balancing or improve reliability (Ex. 1001, col. 3:63–4:4).
`
`
`
`(Ex. 1001, Fig. 1).
`
`Other parallel networks, such as those in Fig. 5, did not have the
`
`“fine grained packet routing of the present invention.” (Ex. 1001, col.
`
`5:24–28). These networks only had coarse routing of traffic or flows
`
`where “all packets from department X might be sent over the frame
`
`relay connection 106 while all packets from department Y are sent over
`
`the Internet 500. Or the architecture might send all traffic over the
`
`frame relay network unless that network fails ….” (Ex. 1001, col. 4:18–
`
`22). Such prior-art architectures did not provide dynamic packet-by-
`
`packet routing between disparate networks.
`
`
`
`4
`
`

`

`
`
`
`
`Patent Owner’s Response
`Case IPR2017-00684
`U.S. Patent No. 6,775,235
`
`
`
`
`(Ex. 1001, Fig. 5).
`
`The ’235 patent describes numerous parallel networks that can be
`
`of many different types (Ex. 1001, col. 7:6–20) where the networks are
`
`divided and routed by known address ranges. (Ex. 1001, col. 8:23–28).
`
`These ranges, for example, can include 192.168.x.x for a LAN, 200.x.x.x
`
`for the Internet, or 196.x.x.x for a Frame Relay. (Ex. 1001, col. 8:50–53).
`
`Packets can be re-routed to different networks by changing their
`
`destination address ranges. (Ex. 1001, col. 9:12–29, col. 13:39–57). For
`
`example, a packet bearing a destination address 10.0.x.x can be
`
`changed to 198.x.x x to route it through the frame relay network. (Ex.
`
`1001, col. 9:12–29). This provided for easy routing of packets between
`
`disparate networks. “Without the invention, . . . network devices are
`
`
`
`5
`
`

`

`
`
`
`
`pre-configured … such that all such packets with [a given] destination
`
`Patent Owner’s Response
`Case IPR2017-00684
`U.S. Patent No. 6,775,235
`
`
`address must be sent to [the addressed network], even though there is
`
`[second network] connectivity between the two locations.” (Ex. 1001, col.
`
`8:55–63).
`
`III. Person of ordinary skill in the art
`The level of ordinary skill in the art is evidenced by the prior art,
`
`among other things. See In re GPAC Inc., 57 F.3d 1573, 1579 (Fed. Cir.
`
`1995). The prior art discussed herein, and in the declaration of Joel
`
`Williams (Ex. 2006), demonstrates that a person of ordinary skill in the
`
`art (“POSA”) would have been a person with at least a bachelor’s of
`
`science or equivalent degree in Computer Science or Electrical
`
`Engineering or related technical field with at least 2 years of experience
`
`in a technical field related to network design, administration,
`
`configuration, and/or diagnosis. (Ex. 2006 ¶¶ 35-36).
`
`This Response is supported by the declaration of Joel Williams, an
`
`expert in the field of computer networking. For 38 years, Mr. Williams
`
`has worked extensively in the networking industry, including working
`
`with many computer routing systems. Over the course of his career, Mr.
`
`Williams has developed extensive expertise in the specification, design,
`
`
`
`6
`
`

`

`
`
`
`
`and development of networking equipment and computer systems. (Ex.
`
`Patent Owner’s Response
`Case IPR2017-00684
`U.S. Patent No. 6,775,235
`
`
`2006 ¶¶ 7–18). Mr. Williams offers his opinion as to the skill level of
`
`POSA (¶¶ 35-36), the content and state of the prior art (¶¶ 42-58), the
`
`’235 patent (¶¶ 37-41), claim construction (¶¶ 30-34), and the teachings
`
`and suggestions that POSA would understand based on the alleged
`
`prior art presented in the Petition (¶¶ 59-110).
`
`IV. Claim construction
`In an inter partes review, claim terms in an unexpired patent are
`
`interpreted according to their broadest reasonable interpretation
`
`(“BRI”) in view of the specification in which they appear. 37 C.F.R.
`
`§42.100(b). Under BRI, claim terms receive their ordinary and
`
`customary meaning as would be understood by one of ordinary skill in
`
`the art in the context of the entire disclosure. In re Translogic Tech.,
`
`Inc., 504 F.3d 1249, 1257 (Fed. Cir. 2007). “While the Board must give
`
`the terms their broadest reasonable construction, the construction
`
`cannot be divorced from the specification and the record evidence.” In re
`
`NTP, Inc., 654 F.3d 1279, 1288 (Fed. Cir. 2011).
`
`FatPipe adopts the ordinary meaning of all terms, subject to the
`
`constraints imposed by the specification to inform a POSA “as to
`
`
`
`7
`
`

`

`
`
`
`
`precisely which ordinary definition the patentee was using.” PPC
`
`Patent Owner’s Response
`Case IPR2017-00684
`U.S. Patent No. 6,775,235
`
`
`Broadband Inc. v. Corning Optical Comm’cns. RF LLC, 815 F.3d 747,
`
`752 (Fed. Cir. 2016).
`
`
`
`V. Overview of Karol
`Karol is directed “to the internetworking of connectionless (e.g.
`
`Internet Protocol or “IP”) and connection oriented (e.g. ATM, MPLS,
`
`RSVP) networks ….” (Ex. 1006, Abstract). Karol’s system uses “nodes
`
`called CL-CO gateways, [which] are arranged to have connectivity to
`
`both the CL network and the CO network.” (Ex. 1006, col. 2:13–15).
`
`Karol’s CL-CO gateway uses standard routing techniques in making
`
`network path decisions. (Ex. 1006, col. 13:43–15:30). Karol touts its
`
`invention as a method for handling CO-network bound packets that
`
`arrive at the CL-CO gateway while a CO network connection is being
`
`established. (Ex. 1006, col. 2:13–62, col. 4:12–15).
`
`In Karol’s shortest-path system, a packet only ends up at a CL-CO
`
`gateway if it happens to be along the shortest path to the destination—
`
`the endpoints do not control which packets reach the gateway. For
`
`example, a packet from a source endpoint, “such as a personal
`
`
`
`8
`
`

`

`
`
`
`
`computer, workstation, or other processor attached to any information
`
`Patent Owner’s Response
`Case IPR2017-00684
`U.S. Patent No. 6,775,235
`
`
`source,” is directed to a CL network. (Ex. 1006, col. 4:36–40). The packet
`
`is then routed through the CL network using the standard IP routing
`
`mechanism, which may be controlled by the well-known Open Shortest
`
`Path First (OSPF) routing protocol. (Ex. 1006, col. 4:45–67, col. 13:43–
`
`15:30). The packet’s route to the destination will result in the packet
`
`arriving at one of the CL-CO gateways only if it is part of the shortest
`
`path according to the other IP routers’ routing tables: “Packets only
`
`appear at a CL-CO gateway if it is part of the shortest path according to
`
`the IP routing tables.” (Ex. 1006, col. 14:52–54, see also col. 4:45–67, col.
`
`14:36–43, col. 13:43–15:30).
`
`Once at the CL-CO gateway, the gateway consults the forwarding
`
`database—which is a routing table—to find the packet’s predetermined
`
`“shortest” path to the destination. (Ex. 1006, col. 13:43–15:30). The
`
`determination of the shortest path is the first step (step 503) in Karol’s
`
`packet-handling process as follows.
`
`
`
`9
`
`

`

`
`
`
`
`Patent Owner’s Response
`Case IPR2017-00684
`U.S. Patent No. 6,775,235
`
`
`
`(Ex. 1006, Fig. 5, cropped). If the shortest path is over the CL network,
`
`the result of step 503 is “NO.” If the shortest path is over the CO
`
`network, the result of step 503 is “YES.”
`
`Karol describes two techniques for creating the forwarding
`
`database, which is an OSPF-based routing table: (1) representing the
`
`CO network as a “non-broadcast network” (a well-known technique used
`
`in OSPF) or (2) not broadcasting the CO network and creating an
`
`integrated routing table. (Ex. 1006, col. 13:43–50). Using the first
`
`technique, Karol explains that the CO network path is only chosen if it
`
`is the shortest:
`
`Routing tables constructed in the IP routers 911–917
`(including the CL-CO gateways 960–962) take into account
`the presence of the non-broadcast network, and enable
`traffic to flow from CL network 901 to CO network 950 and
`
`
`
`10
`
`

`

`
`
`
`
`back to the CL network if paths through the CO network are
`“shorter” according to some measure of interest. (Ex. 1006,
`col. 14:12–17).
`
`Patent Owner’s Response
`Case IPR2017-00684
`U.S. Patent No. 6,775,235
`
`
`Likewise, using the second technique, Karol explains that CO
`
`network path is only chosen if it is the shortest:
`
`Each CL-CO gateway 960–962 determines shortest paths to
`IP destinations by comparing its path on the two networks
`for each destination. The shorter of the two paths is
`maintained at the CL-CO gateway in an integrated IP-CO
`routing table for each destination address. (Ex. 1006, col.
`14:57–62).
`
`When a packet arrives at the CL-CO gateway, the predetermined
`
`routes in the forwarding database will dictate the network path for the
`
`packet.
`
`Karol’s forwarding database can also include user-specific
`
`information. Karol states that user-specific routing information can be
`
`integrated into the forwarding database to advantageously allow the
`
`user to request and receive a guaranteed quality of service. (Ex. 1006,
`
`col. 13:50–54, col. 17:20–22). Implicitly, the CL network cannot provide
`
`
`
`11
`
`

`

`
`
`
`
`such benefits, which is why Karol seeks to take advantage of the CO
`
`Patent Owner’s Response
`Case IPR2017-00684
`U.S. Patent No. 6,775,235
`
`
`network whenever possible. (Ex. 2006 ¶51).
`
`Karol’s forwarding database can be updated “from time to time”
`
`using standard Link State Advertisements (LSAs). Karol further
`
`explains that the link weights used to construct the forwarding
`
`database can be updated using standard Link State Advertisements
`
`(LSAs) (Ex. 1006, col. 14:23–36, col. 17:53–55, col. 17:63–18:2). While
`
`Karol states that these adjustments are made “dynamically,” the OSPF
`
`protocol only sends LSAs “from time to time.” (Ex. 1011, p. 557) (See
`
`also Ex. 1007, p. 111, “The routing table … is updated much less
`
`frequently by a routing daemon (possibly once every 30 seconds).”). This
`
`is too infrequent to continually update the routing table in response to
`
`actual traffic.
`
`Only after a determination has been made that the packet flow
`
`should be routed over the CO network does Karol’s method dictate how
`
`that packet is handled; at that point, a preferred network has been
`
`selected. Karol explains that “the present invention solves the problem
`
`of how to handle traffic (user-plane data) arriving at the CL-CO
`
`
`
`12
`
`

`

`
`
`
`
`gateways until the desired connection is established in the CO
`
`Patent Owner’s Response
`Case IPR2017-00684
`U.S. Patent No. 6,775,235
`
`
`network.” (Ex. 1006, col. 4:12–15). Karol’s method of handling such
`
`packets is shown in detail in Figs. 5 and 6. Karol describes the following
`
`process for handling packets that are received before a CO network
`
`connection can be established:
`
`[E]ither (a) “turning around” a few packets, and continuing
`to route such packets through the CL network using, for
`example, source routing until the connection is set up, or (b)
`generating and transmitting to the source of the datagrams,
`a signal requesting the source to slow down or stop
`transmission of datagrams during the time period when the
`gateway is establishing a path through the CO network. (Ex.
`1006, col. 4:16–23).
`
`As such, a small number of packets may be allowed to go through the
`
`CL network and subsequently all packets are required to go through the
`
`CO network until a routing table change occurs. This network selection
`
`is relatively coarse because the flow can only switch networks once—
`
`when the CO connection is established.
`
`In discussing Fig. 4, Karol explains that when traversing between
`
`networks, a protocol conversion is necessary: “[p]rotocol converter 450 is
`
`
`
`13
`
`

`

`
`Patent Ownner’s Resp
`onse
`
`
`Case IPPR2017-000684
`U.S. Patent
`
`No. 6,7755,235
`
`
`
`
`
`
`
`
`
`
`
`
`extractted from aan IP dattagram, aand conveerted to thhe CO forrmat, so tthat
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`it can bbe carriedd directlyy on conneections inn the CO nnetwork.”” (Ex. 10006,
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`col. 7:114-17).
`
`
`
`
`
`
`
`
`
`(Ex. 10006, Fig. 44, cropped).
`
`
`
`Kaarol furthher describbes protoocol conveersion andd header conversioon
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`when tthe CO neetwork is an ATM network
`
`
`
`
`
`
`
`
`
`: “For exaample, if
`
`the CO
`
`
`
`networrk is an AATM netwwork, thenn applicattion dataa needs too be
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`converted to thee AAL5 foormat so that it caan be carrried throuugh the AATM
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`networrk. Since AAL5 perrforms trransport-llayer funcctions, thhe TCP
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`14
`
`P U
`
`
`
`
`
`
`
`
`
`
`
`a typiccally a sofftware immplementeed processs in whicch the useer payloadd is
`
`

`

`
`
`
`
`header can also be converted to an AAL5 header in a switched (rather
`
`Patent Owner’s Response
`Case IPR2017-00684
`U.S. Patent No. 6,775,235
`
`
`than provisioned) ATM network. In other words, TCP/IP headers are
`
`converted into AAL5 /ATM headers. By doing this, it appears that TCP
`
`connections are terminated at the CL-CO gateways from each endpoint
`
`of the communication, and a connection of the type supported by the CO
`
`network is set up between the CL-CO gateways, such as
`
`gateways 140 and 150 of FIG. 1.” (Ex. 1006, col. 7:18-29).
`
`Although such protocol conversion and header conversion occurs at
`
`the CL-CO gateway, Karol does not describe that any modification
`
`occurs to the original destination IP address included in an incoming
`
`packet. (Ex. 2006 ¶58).
`
`VI. Claims 6 and 22-24 are not anticipated by Karol.
`Claims 6 and 22-24 are patentable over Karol because Karol does
`
`not disclose “modifying the packet destination address to lie within a
`
`known location address range” as required by the claims.
`
`A. The item to be modified is the final destination IP
`address in the incoming packet.
`As an initial matter, the Petition maps the claimed “packet
`
`destination address” to Karol’s destination IP address of an incoming
`
`
`
`15
`
`

`

`
`
`
`
`packet at the CL-CO gateway. Independent claim 5, from which claim 6
`
`Patent Owner’s Response
`Case IPR2017-00684
`U.S. Patent No. 6,775,235
`
`
`depends, recites “receiving at the current location a packet which
`
`identifies a particular destination location by specifying a destination
`
`address for the destination location.” (Ex. 1001, col. 17:65-67; Ex. 2006
`
`¶60).
`
`For the recitation of “a destination address” in claim 5, the
`
`Petition points to Karol’s description of “the destination address in each
`
`datagram received at the input line card of the CL-CO gateway.” (Pet.
`
`at 19). Likewise, for the claim 5 recitation “determining whether the
`
`destination address lies within a known location address range,” the
`
`Petition points to the “destination IP address in each packet received at
`
`the CL-CO gateway.” (Pet., p. 20). Thus, Petitioner identifies the final
`
`destination IP address in the incoming packet as the item to be
`
`modified. (Ex. 2006 ¶61)
`
`Moreover, Dr. Forys confirmed in his deposition testimony that he
`
`interpreted the destination IP address on an incoming IP datagram,
`
`which represents the final destination of the packet, at the gateway in
`
`
`
`16
`
`

`

`
`
`
`
`Karol as corresponding to the “packet destination address” of claim 6.
`
`Patent Owner’s Response
`Case IPR2017-00684
`U.S. Patent No. 6,775,235
`
`
`(Ex. 2004 at 20:13–21:4; and 21:24–22:7; Ex. 2006 ¶62).
`
`B. Protocol and header conversions do not require
`modifications to the destination IP address
`With the destination IP address of an incoming datagram in Karol
`
`being firmly established as Petitioner’s alleged “packet destination
`
`address” in claim 6, the Petition never actually shows that the
`
`destination IP address of the incoming datagram to the CL-CO gateway
`
`is modified. (Ex. 2006 ¶63).
`
`Instead, the Petition relies completely on Karol’s description of
`
`“protocol conversion” that is performed by the protocol converter 450 in
`
`the CL-CO Gateway of Karol. The cited portion of Karol describes that
`
`“[p]rotocol converter 450 is a typically a software implemented process
`
`in which the user payload is extracted from an IP datagram, and
`
`converted to the CO format, so that it can be carried directly on
`
`connections in the CO network.” (Ex. 1006, col. 7:14-17). The Petition
`
`then jumps to the sweeping conclusion that “[t]his conversion process
`
`includes converting the headers containing the address information.”
`
`(Pet., p. 21).
`
`
`
`17
`
`

`

`
`Patent Ownner’s Resp
`onse
`
`
`Case IPPR2017-000684
`U.S. Patent
`
`No. 6,7755,235
`
`
`
`
`
`
`
`
`
`
`
`
`occur in Karol is meaninngless witth regard to claimss 6 and 222 of the ’2235
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`patent
`
`
`
`
` without a separatte teachinng of an aactual moodificationn to the
`
`
`
`
`
`
`
`
`
`
`
`destinaation IP aaddress of the incooming paccket at thhe CL-COO gatewayy.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`(Ex. 20006 ¶65).
`
`
`
`
`
`
`
`
`
`
`
`WWe need look no fuurther thaan Fig. 144.10 of St
`
`
`
`
`
`allings (EEx. 1011) to
`
`
`
`
`
`see thaat there aare many differentt protocolss simultaaneously bbeing useed
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`when ddata is traansmittedd over a nnetwork. (Ex. 20066 ¶66)
`
`
`
`
`
`
`
`
`
`
`
`
`
`(Ex. 10011 – Parrt 2, p. 110).
`
`
`
`
`
`
`
`18
`
`
`
`P U
`
`
`
`
`
`
`
`
`
`
`
`HHowever, any protoocol conveersion or header cconversionn that maay
`
`

`

`
`
`
`
`
`
`FFig. 15.10 shows thhat in thee well-knoown Openn Systems
`
`
`Patent Ownner’s Resp
`onse
`
`
`Case IPPR2017-000684
`U.S. Patent
`
`No. 6,7755,235
`
`
`P U
`
`
`
`
`
`
`
`
`
`
`
`Interconnnection (OOSI) archiitecture, when datta is beinng sent beetween ennd
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`user syystems ovver a netwwork, therre are maany protoocols invollved and
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`while llower-layer protocools (physiical, dataa link, andd networkk) may
`
`
`
`
`
`
`
`changee throughhout the eend-to-endd transmiission proocess, thee protocolls
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`and daata contaiined in thhe upper llayers maay remainn the samme until thhe
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`final destinationn is reachhed. (Ex. 2006 ¶677).
`
`
`
`
`
`WWith regaard to heaaders, theere may b
`
`
`
`
`
`
`
`
`
`e multiplle differennt headerrs
`
`
`
`
`
`
`
`appendded to thee data in a corollarry fashionn as the pprotocol laayers in tthe
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`OSI moodel as shhown in FFig. 15.111 of Stalli
`
`
`
`
`
`
`
`
`
`ngs beloww. (Ex. 20006 ¶68)
`
`
`
`
`
`
`
`(Ex. 10011 – Parrt 2, p. 115).
`
`
`
`
`
`
`
`19
`
`

`

`
`
`
`
`Therefore, the IP address in the IP layer is preserved when
`
`Patent Owner’s Response
`Case IPR2017-00684
`U.S. Patent No. 6,775,235
`
`
`encapsulated within a network packet (or segmented into ATM cells) by
`
`the Network-Level. (Ex. 2006 ¶69).
`
`Further, the concept of addressing separate from the concept of
`
`protocols and headers. (Ex. 1011 – Part 2, p. 97; Ex. 2006 ¶70). Stallings
`
`explains that addresses are used to identify network entities:
`
`“Addressing level refers to the level in the communications architecture
`
`at which an entity is named. Typically, a unique address is associated
`
`with each end system (e.g. host or terminal) and each intermediate
`
`system (e.g., router) in a configuration.” (Ex. 1011 – Part 2, p. 97). As
`
`shown in Fig. 15.4 of Stallings, the IP address for a host system is a
`
`global network address. (Ex. 2006 ¶70).
`
`
`
`20
`
`

`

`P U
`
`
`Patent Ownner’s Resp
`onse
`
`
`Case IPPR2017-000684
`U.S. Patent
`
`No. 6,7755,235
`
`
`
`
`
`
`
`
`). rt 2, p. 98)(Ex. 10011 – Par
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`EEven Petitioner’s eexpert admmits thatt modificaation of a packet
`
`
`
`
`
`
`
`destinaation adddress is noot necessaarily the
`
`
`
`
`
`
`
`
`
`same as pprotocol cconversioon .
`
`
`
`
`
`
`
`(Ex. 20004, p. 32:6-14)). Inn one viviid exampple, Dr. Foorys clearrly indicaates
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`that thhe IP addrress remaains fixedd when a
`
`
`
`
`
`
`
`
`
`lower-layyer protoccol is
`
`
`
`
`
`changeed:
`
`Q u
`
`
`
`
`
`
`
`Q. Okay. NNow, if a packet iss transmiitted acrooss the neetwork
`
`
`
`
`
`
`using a MMAC addreess, for exxample, aand the MMAC addrress
`
`
`
`21
`
`

`

`
`
`
`
`Patent Owner’s Response
`Case IPR2017-00684
`U.S. Patent No. 6,775,235
`
`
`changes or it gets -- does it get deleted at the end of that --
`that transmission?
`
`A. It changes link by link. So, in other words, you would
`start off, you may have 10 link things. So you would -- the
`MAC address would be the MAC address of the next router,
`and that gets transformed now into a new MAC address,
`because this is done at the link layer. So you’re routing link
`by link by link. Okay. That’s how that’s done. So the MAC
`address at the end can be completely different than the first
`hop.
`
`Q. Is it required that the IP address changes along with the
`MAC address if the MAC address changes at some point or if
`it gets discarded at some point?
`A. No, that would be an unusual occurrence. I mean,
`normally, the -- the IP address contains the information
`necessary to route the packet throughout the whole network,
`and it -- it stays fixed. (Ex. 2004, p. 28:21–29:15, emphasis
`added).
`
`Therefore, according to the Petitioner’s own expert, protocol
`
`conversion does not imply modification of the IP address, and it would
`
`
`
`22
`
`

`

`
`
`
`
`be “an unusual occurrence” for the IP address to change even if a lower-
`
`Patent Owner’s Response
`Case IPR2017-00684
`U.S. Patent No. 6,775,235
`
`
`layer protocol is changed.
`
`Thus, when data is transmitted through a network, protocol
`
`conversion and even header conversion does not inherently include a
`
`modification or change to the destination address for the final
`
`destination device. (Ex. 2006 ¶71).
`
`C. The actual destination IP address in the incoming
`packet in is not modified in the protocol conversion
`process of Karol.
` As fully admitted by Petitioner’s expert, the type of protocol
`
`conversion described in Karol and relied upon in the Petition, does not
`
`result in a modification of the final destination IP address included in
`
`the incoming packet. (Ex. 2004, p. 23:2-5, 24:3-7; Ex. 2006 ¶72)
`
`The protocol conversion in Karol, cited by the Petition, is a
`
`conversion from a connectionless environment to a connection-oriented
`
`environment over, for instance, an Asynchronous Transfer Mode (ATM)
`
`connection (Pet., p. 21-22). However, this conversion does not result in
`
`any modification to the global destination IP address that is included in
`
`the incoming datagram. (Ex. 2006 ¶73).
`
`
`
`23
`
`

`

`
`
`
`
`First, Karol describes two types of ways to send the data received
`
`Patent Owner’s Response
`Case IPR2017-00684
`U.S. Patent No. 6,775,235
`
`
`at the CL-CO gateway over a CO network: (1) protocol conversion and
`
`(2) protocol encapsulation (Ex. 1006, col. 16:30-31; Ex. 2006 ¶74). Karol
`
`describes that “[w]ith protocol conversion, the user payload is extracted
`
`from the IP datagram and carried directly on connections in the CO
`
`network. For example, if the CO network is an ATM network, then
`
`application data is carried in an [AAL5] frame through the ATM
`
`network. Since AAL5 performs transport-layer functions, the TCP
`
`header can also be converted to an [AAL5] header in a switched (rather
`
`than provisioned) ATM network. In other words, TCP/IP headers are
`
`converted into [AAL5] /ATM headers. By doing this, it appears that
`
`TCP connections are terminated at the CL-CO gateways from each
`
`endpoint of the communication, and a connection of the type supported
`
`by the CO network is set up between the CL-CO gateways.” (Ex. 1006,
`
`col. 16:50-62).
`
`Karol further states: “[p]rotocol conversion is typically used when
`
`one endpoint of the communication is on one network and the other is
`
`on the second network. This is illustrated by path 1110 between
`
`
`
`24
`
`

`

`
`
`
`
`endpoints 1101 and 1102 in FIG. 11, which shows the same networks,
`
`Patent Owner’s Response
`Case IPR2017-00684
`U.S. Patent No. 6,775,235
`
`
`nodes and gateways that were depicted in FIG. 9. For example, if a user
`
`with an Internet telephony PC connected to the Internet via an
`
`Ethernet link is communicating with a user that has a telephone, then
`
`voice signals sent by the Internet user are extracted from the IP
`
`datagrams in the CL-CO gateway node (CL-CO gateway 960 in FIG. 11)
`
`and carried directly on a DS0 circuit in the CO network 950, which is
`
`illustratively an STM network.” (Ex. 1006, col. 16:63 to 17:7) This is
`
`similar to converting Voice over IP (VoIP) to PSTN (traditional analog phones) or
`
`ISDN (digital telephony). (Ex. 2006 ¶75).
`
`Below is an annotated version of Fig. 11 of Karol based on this
`
`description of when “protocol conversion” is used instead of “protocol
`
`encapsulation.” (Ex. 2006 ¶75). In this situation, a destination IP
`
`address and therefore the destination IP address for the IP datagrams
`
`is actually the CL-CO gateway itself which acts a termination point for
`
`the IP protocol. (Ex. 2006 ¶75).
`
`
`
`25
`
`

`

`P U
`
`
`Patent Ownner’s Resp
`onse
`
`
`Case IPPR2017-000684
`U.S. Patent
`
`No. 6,7755,235
`
`
`
`
`
`
`TThus, therre is no mmodification of the destinatiion IP adddress in tthis
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`case since the uuse of the IP protoccol ceasess and the original
`
`
`
`
`
`
`
`
`
`
`
`
`
`destinatiion
`
`
`
`IP adddress is diiscarded. (Ex. 20006 ¶76). AA POSA wwould nott construee
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`item to b
`“modiffying” an
`
`
`
`
`
`
`
`
`
`
`
`e the samme as disccarding orr deletingg an itemm
`
`
`
`
`
`accordiing to eithher the pplain and ordinary meaningg of “modiify” (Ex.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`2005, pp. 3), or inn view of the speciification.
`
`
`
`
`
`
`
`
`
` (Ex. 20006 ¶76).
`
`
`
`TThe speciffication off the ’2355 patent ddescribes “[f]or ins
`
`
`
`
`
`
`
`
`
`
`
`
`
`tance, wiith
`
`
`
`referennce to thee illustrattive netwoork topoloogy of FIGG. 10, if tthe invenntive
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`26
`
`

`

`
`
`Patent Owner’s Response
`Case IPR2017-00684
`U.S. Patent No. 6,775,235
`
`module 602 at location A receives a packet with a destination address in
`
`
`
`the 10.0.x.x range and the Internet router X is either down or over-
`
`loaded, then the inventive module 602 can change the destination
`
`address so that it is in the 198.x.x.x range (the rest of the address may
`
`be kept) and then send the modified packet to the frame relay router Y.”
`
`(Ex. 1001, col. 9:17-25). Furthermore, the phrase “the rest of the
`
`address may be kept” indicates that this modification is made to the
`
`actual address itself and it includes at least a partial change to the
`
`original destination IP address. (Ex. 2006 ¶76). Therefore, claims 6
`
`and 22 require that a modification is made to