`
`IN THE UNITED STATES PATENT & TRADEMARK OFFICE
`______________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`______________________
`
`
`TALARI NETWORKS, INC.,
`
`Petitioner,
`
`v.
`
`FATPIPE NETWORKS PRIVATE LIMITED,
`
`Patent Owner.
`______________________
`
`Case IPR2016-00976
`Patent U.S. 6,775,235
`______________________
`
`
`PATENT OWNER’S REQUEST FOR REHEARING
`
`
`
`
`
`
`
`
`
`
`
`
`
`INTRODUCTION
`Pursuant to 37 C.F.R. § 42.71(d), Patent Owner FatPipe Networks
`
`Private Limited and exclusive licensee FatPipe, Inc. (collectively,
`
`“FatPipe” or “Patent Owner”), respectfully request rehearing of the
`
`Board’s Final Written Decision of November 1, 2017. (Paper 32,
`
`“Decision”) for the following matters relevant to claims 4 and 9:
`
`
`
`First, in determining “that it would have been obvious to modify
`
`Karol by limiting the routing decision to an analysis of the packet’s
`
`source address,” the Decision overlooks the fact that claim 4 of the ’235
`
`patent expressly requires “select[ion] between network interfaces on a
`
`per-packet basis according to at least: a destination of the packet.”
`
`(Decision, pp. 19-20, emphasis added).
`
`
`
`Second, in determining that dependent claim 9 is obvious for the
`
`same reason as claim 4, the Decision similarly overlooks that claim 9
`
`depends from claim 5, which requires analysis of the “destination
`
`location” and “destination address.”
`
`
`
`Third, the Decision overlooked or misapprehended the passages of
`
`the ’235 patent that describe path section based on the origin of the
`
`1
`
`
`
`packet as “coarse” and that distinguish such per-department and per-
`
`router methods from per-packet and per-session path selection. (See Ex.
`
`1001, col. 4:15-23, 7:38-42, 11:33-38).
`
`
`
`Fourth, the Decision overlooked and/or misapprehended that
`
`routing based on the source address will forward all packets from the
`
`same source to the same network, which is similar to the flow-based
`
`routing that the Board correctly distinguished from per-packet selection
`
`in claims 4 and 9. (Ex. 1001, col. 6:62–7:5, 7:38-42, 11:33-38).
`
`ARGUMENT
`
`A. If Karol is modified to analyze only the source address of
`a packet, then the modified system excludes the subject
`matter of claim 4, which requires selection based on “a
`destination address.”
`Patent Owner argued in its response that “Karol does not disclose
`
`or render obvious ‘a packet path selector which selects between network
`
`interfaces on a per-packet basis according to at least: a destination of
`
`the packet ….’” (PO Resp., pp. 23, 27, emphasis added). The Decision
`
`overlooked this limitation when it relied upon Petitioner’s assertion
`
`“that it would have been obvious to modify Karol by limiting the routing
`
`2
`
`
`
`decision to an analysis of the packet’s source address.” (Decision, pp.19-
`
`20, emphasis added).
`
`Claim 4 of the ’235 patent requires “a packet path selector which
`
`selects between network interfaces on a per-packet basis according to at
`
`least: a destination of the packet, an optional presence of alternate paths
`
`to that destination, and at least one specified criterion for selecting
`
`between alternate paths when such alternate paths are present.” The
`
`Board agreed with Patent Owner that “per-” packet means “selecting a
`
`network path/interface for each packet” (Decision, p. 9) and
`
`subsequently concluded that Karol does not disclose the per-packet
`
`selection required in claim 4 (Decision, p. 18-19). But, the Decision
`
`adopted Petitioner’s fallback position that “that it would have been
`
`obvious to modify Karol by limiting the routing decision to an analysis
`
`of the packet’s source address.” (Decision, pp. 19-20).
`
`This fallback position was conditioned on a claim construction
`
`that neither party advocated and that the Board did not adopt, namely,
`
`that per-packet basis means “regardless of the session with which the
`
`packet is associated.” (Petition, p. 45). Nonetheless, Patent Owner was
`
`concerned by that possibility and urged that, if such a claim
`
`3
`
`
`
`construction was adopted (which it wasn’t), a “POSITA would have
`
`found substituting [a] the packet-by-packet path selection process that
`
`considers multiple criteria including associated flows as explicitly
`
`disclosed in Karol with [b] a much simpler and known packet path
`
`selection process that considers only source address regardless of the
`
`session to yield a highly successful and predictable result” because it
`
`was an obvious substitution of one known element for another and
`
`obvious to try. (Petition, p. 46, citing Ex. 1005, ¶¶ 194-196, emphasis
`
`added). In any case, the Board didn’t adopt that construction, and thus,
`
`“a packet path selector which selects between network interfaces on a
`
`per-packet basis according to at least: a destination of the packet …”
`
`remains a limiting element of claim 4.
`
` Because claim 4 requires that the destination of the packet is
`
`used to select between network interfaces on a per-packet basis,
`
`modifying Karol to limit the routing decision to an analysis of the
`
`packet’s source address excludes the first of the three criteria specified
`
`in claim 4 for selecting a network—the destination of the packet.
`
`Neither the Petition nor the Decision addresses how this new deficiency
`
`4
`
`
`
`is cured if Karol’s routing decision is limited to an analysis of the
`
`packet’s source address.
`
`Thus, the Board should reconsider its findings and hold that claim
`
`4 is not unpatentable.
`
`B. If Karol is modified to analyze only the source address of a packet,
`then the modified system excludes the subject matter of claim 9,
`which depends from claim 5 and thus requires network selection
`based on “a destination address.”
`On the issue of network path selection, Patent Owner made the
`
`same arguments for claims 4 and 9: “Independent of the arguments
`
`above for claim 5, claim 9 is also patentable over Karol because Karol
`
`does not disclose or render obvious ‘repeated instances of the selecting
`
`step make network path selections on a packet-by-packet basis.’ ” (PO
`
`Resp., p. 51). In concluding that claim 9 is obvious, the Decision relied
`
`on the same rationale that it used for claim 4. (Decision, p. 31).
`
`As discussed above, this rationale—that it would have been
`
`obvious to modify Karol by limiting the routing decision to an analysis
`
`of the packet’s source address—was based on a claim construction that
`
`neither party advocated and that the Board did not adopt. In any event,
`
`a system that limits the routing decision to an analysis of the packet’s
`
`5
`
`
`
`source address excludes the method of claim 9 because of the following
`
`limitation in independent claim 5 that require analysis of the
`
`destination address/location:
`
` “obtaining topology information which specifies associated
`
`networks that provide, when working, connectivity between
`
`a current location and at least one destination location”;
`
` “receiving at the current location a packet which identifies a
`
`particular destination location by specifying a destination
`
`address for the destination location”;
`
` “determining whether the destination address lies within a
`
`known location address range”;
`
` “selecting a network path from among paths to disparate
`
`associated networks, said networks being in parallel at the
`
`current location, each of said networks specified in the
`
`topology information as capable of providing connectivity
`
`between the current location and the destination location”;
`
`The “known location address range” and “associated networks” are
`
`used in conjunction with the destination address or destination location,
`
`which are elements of the first step of claim 5. Thus, the proposed
`
`6
`
`
`
`modification of Karol to limit the routing decision to an analysis of the
`
`packet’s source address implicates every step of claim 5, which
`
`repeatedly relies upon the destination address or the destination
`
`location, neither of which is relevant to Karol’s system as modified.
`
`Neither the Petition nor the Decision addresses how this new
`
`deficiency is cured if Karol’s routing decision is limited to an analysis of
`
`the packet’s source address. Thus, the Board should reconsider its
`
`findings and hold that claim 4 is not unpatentable.
`
`C. The background art of the ’235 patent does not disclose
`selecting between networks on a “per-packet” (claim 4)
`or “packet-by-packet” (claim 9) basis.
`In its response, Patent Owner pointed out that the background art
`
`described in the ’235 patent at col. 4, lines 15-23, used coarse routing of
`
`traffic or flows between networks instead of per-packet or packet-by-
`
`packet routing. (PO Resp., pp. 4, 23). The Board misconstrued this
`
`portion of the ’235 patent to describe selecting between networks on a
`
`per-packet/packet-by-packet basis.
`
`In relying upon the conclusion, “that it would have been obvious to
`
`modify Karol by limiting the routing decision to an analysis of the
`
`packet’s source address,” (Decision, pp. 19-20), the Board specifically
`
`7
`
`
`
`relies upon Petitioner’s citation to column 4, lines 15-23 of the ’235
`
`patent, which describes the following:
`
`But better tools and techniques are needed for use in
`architectures such as that shown in FIG. 5. In particular,
`prior approaches for selecting which network to use for
`which packet(s) are coarse. For instance, 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, and then be manually reconfigured to send all traffic
`over a VPN 502. (Emphasis added).
`
`The Petition cites this passage in support of its statement that the
`
`“The ’235 Patent also discloses that a POSITA would have known that
`
`the prior art discloses routing decisions that are independent of the
`
`particular flows or sessions of particular packets.” (Petition, p. 45). But
`
`the Petition neglects to mention that, in fact, the ’235 patent criticizes
`
`this per-department or per-router approach as “coarse” to distinguish
`
`the way the invention selects network paths on a per-session or per-
`
`packet basis. (Col. 4:15-18). The ’235 patent describes that the more
`
`8
`
`
`
`“granular” techniques of per-packet and per-session network selection
`
`are distinct from, and preferred over, per-department selection:
`
`Load-balancing is preferably done on a per-packet basis for
`site-to-site data traffic over the Internet or frame relay net,
`or done on a TCP or UDP session basis for Internet traffic,
`as opposed to prior approaches that use a per-department
`and/or per-router basis for dividing traffic. (Col. 7:37-42).
`
`Therefore, the ’235 patent’s description of per-department network
`
`selection does not lend any teaching or rationale to modify Karol to
`
`make a decision on a per-packet basis.
`
`If anything, column 4, lines 15-23, of the ’235 patent shows that,
`
`even when using the source address or the origin of the packet as the
`
`basis for making a routing decision, there is still a problem that path
`
`selection is too coarse because a routing decision is broadly applied to
`
`all packets of a certain origin rather than making a new selection for
`
`each individual packet or session. Thus, the Board misapprehended the
`
`meaning of this passage of the ’235 patent in concluding that per-
`
`department routing is an example of per-packet selection, when in fact,
`
`this passage describes per-department routing to distinguish per-packet
`
`selection, as required by claims 4 and 9.
`
`9
`
`
`
`Therefore, the Board should reconsider and reverse its finding
`
`that at least claims 4 and 9 are obvious over Karol.
`
`D. The modification of Karol to analyze only the source
`address of a packet is inconsequential to achieving the
`feature of per-packet or packet-by-packet selection.
`Patent Owner’s response emphasized the difference between
`
`forwarding packets on pre-computed routes and selecting packets on a
`
`per-packet basis:
`
`Karol’s CL-CO gateway uses the forwarding database’s pre-
`computed routes to make network path decisions and,
`therefore, does not “select” a network when a packet arrives
`at the gateway. (P. 24).
`
`Accordingly, when a packet arrives at Karol’s CL-CO
`gateway there is no “select[ing]” process because the packet
`is simply routed to the network path that was pre-selected
`prior to the packet’s arrival…. (P. 26).
`
`The Decision overlooked or misapprehended this distinction and offers
`
`no explanation how the substitution of source routing into Karol could
`
`amount to per-packet or packet-by-packet selection, as required by
`
`claims 4 and 9.
`
`10
`
`
`
`If Karol’s system were modified to analyze only the source
`
`address, then there could be no per-packet path selection at the CL-CO
`
`gateway because the routing decisions would be predetermined, based
`
`on the source. For example, “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.” (Ex. 1001, col. 4:18-21).
`
`The Board correctly determined Karol’s routing decision, applied
`
`to a flow of packets, is not per-packet network path selection: “Thus, we
`
`determine that Karol’s routing decisions are made for a flow of packets
`
`and not for an individual packet.” (Decision, p. 18). In other words, if a
`
`routing table or flow database forwards all packets with a particular
`
`destination address to a particular network interface, there is no per-
`
`packet selection taking place. Similarly, if a routing table or flow
`
`database forwards all packets from a particular origin or source address
`
`to a particular network interface, there is no per-packet selection taking
`
`place because the selection is made for an entire group of packets
`
`having the same source address. This is exactly what the ’235 patent
`
`considers to be a coarse packet selection criteria because the selection is
`
`11
`
`
`
`broadly applied to all packets of a particular origin rather than
`
`separately making a network selection for each packet.
`
`For this reason, the Board should reconsider and reverse its
`
`finding that at least claims 4 and 9 is obvious over Karol.
`
`CONCLUSION
`For all the foregoing reasons, the Board should reconsider and
`
`reverse its finding that at least claims 4 and 9 are unpatentable.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Dated: December 1, 2017
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Respectfully submitted,
`
`Oblon, McClelland, Maier &
` Neustadt, LLP
`
`
`
`
`
`
`
`/Robert C. Mattson/
`Robert C. Mattson
`Reg. No. 42,850
`(703) 412-6466 (direct)
`
`
`12
`
`
`
`
`
`
`
`CERTIFICATE OF SERVICE
`
`Pursuant to 37 C.F.R. § 42.6(e), the undersigned certifies service
`
`of PATENT OWNER’S REQUEST FOR REHEARING on the counsel of
`
`record for the Petitioner by filing this document through the PTABE2E
`
`System as well as delivering a copy via electronic mail to the following
`
`address:
`
`
`
`
`Andy H. Chan (chana@pepperlaw.com)
`Charles F. Koch (kochc@pepperlaw.com)
`Thomas F. Fitzpatrick (fitzpatrickt@pepperlaw.com)
`Pepper Hamilton LLP
`
`Dated December 1, 2017
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`/Robert C. Mattson /
`Robert C. Mattson
`Reg. No. 42,850
`
`
`
`
`
`
`
`
`
`
`
`
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
