Ex Parte 7395349 et al

Patent Trial and Appeal Board

Sep 9, 2014

95001510 (P.T.A.B. Sep. 9, 2014)

UNITED STATES PATENT AND TRADEMARK OFFICE
UNITED STATES DEPARTMENT OF COMMERCE
United States Patent and Trademark Office
Address: COMMISSIONER FOR PATENTS
P.O. Box 1450
Alexandria, Virginia 22313-1450
www.uspto.gov
APPLICATION NO. FILING DATE FIRST NAMED INVENTOR ATTORNEY DOCKET NO. CONFIRMATION NO.
95/001,510 12/13/2010 7395349 11517.0003-00/10.0035C2R1 9489
38878 7590 09/09/2014
F5 Networks, Inc.
c/o Lowe Graham Jones PLLC
701 5th Avenue, Suite 4800
Seattle, WA 98104
EXAMINER
PROCTOR, JASON SCOTT
ART UNIT PAPER NUMBER
3992
MAIL DATE DELIVERY MODE
09/09/2014 PAPER
Please find below and/or attached an Office communication concerning this application or proceeding.
The time period for reply, if any, is set in the attached communication.
PTOL-90A (Rev. 04/07)

UNITED STATES PATENT AND TRADEMARK OFFICE
________________

BEFORE THE PATENT TRIAL AND APPEAL BOARD
________________

A10 NETWORKS, INC.
Requester

v.

F5 NETWORKS, INC.
Patent Owner and Appellant
________________

Appeal 2014-007352
Reexamination Control 95/001,510
Patent 7,395,349 B1
Technology Center 3900
________________

Before DENISE M. POTHIER, ANDREW J. DILLON, and
JEREMY J. CURCURI, Administrative Patent Judges.

CURCURI, Administrative Patent Judge.

DECISION ON APPEAL
Patent Owner appeals the Examiner’s decision to reject claims 11-13.
PO App. Br. 4. We have jurisdiction under 35 U.S.C. §§ 134 and 315.
Claims 11-13 are rejected on various grounds. RAN 3-34.
We affirm.
Appeal 2014-007352
Reexamination Control 95/001,510
Patent 7,395,349 B1

2

STATEMENT OF THE CASE
This proceeding arose from a request by A10 Networks, Inc. for an
inter partes reexamination of U.S. Patent 7,395,349, titled “Method and
System for Scaling Network Traffic Managers” (the ’349 patent). The ’349
patent relates to “distributing network traffic associated with traffic
management devices.” ’349 patent, col. 1, ll. 15-16. Claim 11 is illustrative,
and is reproduced below:
11. A method of routing packets between a first network device and
a second network device over a network, comprising:
receiving a packet;
if the received packet is from the first network device:
determining a target traffic manager based on first fields in the
received packet, by hashing the first fields in the received packet to obtain a
hash key and employing the hash key to select the target traffic manager to
which the received packet is forwarded, and
forwarding the received packet to the target traffic manager;
and
if the received packet is from the second network device:
determining the target traffic manager based on second fields in
the received packet, wherein the first fields are different from the second
fields; and
forwarding the received packet to the target traffic manager,
wherein the received packet from the second network device is forwarded to
Appeal 2014-007352
Reexamination Control 95/001,510
Patent 7,395,349 B1

3
the same target traffic manager as is the received packet from the first
network device.

SELECTED REFERENCES
 Application Note: Firewall Load Balancing With ServerIron, Foundry
Networks 1-4, March 3, 2000 (“Foundry Networks”).
 US 6,651,099 B1; issued Nov. 18, 2003 (“Dietz”).

ANALYSIS
THE ANTICIPATION REJECTION OF CLAIMS 11 AND 13 BY
FOUNDRY NETWORKS
Claims 11 and 13 are rejected under 35 U.S.C. § 102(e) as anticipated
by Foundry Networks. RAN 28-29 (incorporating Request 18-24). The
Examiner finds Foundry Networks describes all limitations of claim 11.
Request 18-22.
In making the rejection, the Examiner relies on Foundry Networks’s
load balancing by ServerIron-A and ServerIron-B across firewalls, including
the use of the same algorithm by both ServerIron-A and ServerIron-B to
ensure packets for a given Transmission Control Protocol (TCP) connection
flow through the same firewall. This algorithm uses a configurable hashing
algorithm to select a firewall based on source Internet Protocol (IP) address,
source port number, destination IP address, and destination port number.
Request 20-22 (citing Foundry Networks, p. 2).
Patent Owner presents the following principal arguments:
Appeal 2014-007352
Reexamination Control 95/001,510
Patent 7,395,349 B1

4
(i) “Because Foundry discloses using the same set of four (4)
fields to select a firewall whether the packet is from the ServerIron-A or
from ServerIron-B, Foundry fails to disclose that the first fields are different
from the second fields, as recited in claim 11.” PO App. Br. 9.
(ii)
Claim 11 clearly recites “if the received packet is from the first
network device .... hashing the first fields ...” and “if the
received packet is from the second network device…
determining the target traffic manager based on second fields,
wherein the first fields are different from the second fields ....”
That is, Claim 11 recites performing different actions based on
whether the packet is received from the first network device or
from the second network device. Foundry does not make this
distinction. Foundry discloses hashing in both directions always
using the same four fields, whether the packet is from its
Serverlron-A or from its ServerIron-B
PO App. Br. 10.
In response, the Examiner explains the recited first fields correspond
to Foundry Networks’s source IP address and source port number, and the
recited second fields correspond to Foundry Networks’s destination IP
address and destination port number. Ans. 2. The Examiner further explains
Foundry’s algorithm, in both directions, hashes both the first
fields in the packet and second fields in the packet to determine
a target traffic manager. There is no claim language to support
Patent Owner’s position that the claim requires, e.g., hashing
first fields in the packet but excludes also hashing second fields
in the packet. (Similarly, there is no language that excludes, in
the second direction, determining by hashing the second fields
in the packet.)
Ans. 2-3.
We are not persuaded of Examiner error.
Appeal 2014-007352
Reexamination Control 95/001,510
Patent 7,395,349 B1

5
Foundry Networks’s hashing algorithm, used in both directions, to
select a firewall based on source IP address, source port number, destination
IP address, and destination port number describes both the recited
determining a target traffic manager based on first fields (source IP address
and source port number), and the recited determining the target traffic
manager based on second fields (destination IP address and destination port
number, which are different than the source IP address and source port
number). See Foundry Networks, p. 2
Regarding Patent Owner’s argument (i), we find this argument
unpersuasive because the claim language for both determining actions does
not exclude the consideration of additional fields. Thus, the broad claim
language does not preclude a finding that Foundry Networks describes the
argued limitations. See, e.g., Genentech, Inc. v. Chiron, Corp., 112 F.3d 495,
501 (Fed. Cir. 1997).
Regarding Patent Owner’s argument (ii), we find this argument
unpersuasive because the claim language for determining the target traffic
manager based on second fields does not exclude utilizing a hashing
algorithm. Thus, the broad claim language does not preclude a finding that
Foundry Networks describes the argued limitations.
We, therefore, sustain the Examiner’s rejection of claim 11 as
anticipated by Foundry Networks, as well as claim 13, which is not
separately argued with particularity.

Appeal 2014-007352
Reexamination Control 95/001,510
Patent 7,395,349 B1

6
THE OBVIOUSNESS REJECTION OF CLAIM 12 OVER FOUNDRY
NETWORKS AND DIETZ
Claim 12 is rejected under 35 U.S.C. § 103(a) as obvious over
Foundry Networks and Dietz. RAN 29 (incorporating Request 24-26). The
Examiner relies on Dietz for teaching the recited determining whether the
received packet is from the first network device based on a comparison of a
first packet header field to a second packet header field. Request 25-26.
In making the rejection, the Examiner relies on Dietz’s flow keys built
by placing the numerically lower address before the numerically higher
address. Request 25-26 (citing Dietz, col. 12, ll. 4-8, col. 20, ll. 16-20, col.
33, ll. 23-37).
Patent Owner presents the following principal argument: “Merely
making a comparison for the purpose of reordering addresses within a flow
key does not teach or suggest determining whether the received packet is
from the first network device based on the recited comparison.” PO App. Br.
12.
In response, the Examiner explains “[p]lacing the numerically lower
address before the numerically higher address requires knowing whether
‘source address < destination address’ for the received packet.” Ans. 7.
We are not persuaded of Examiner error.
Dietz (col. 12, ll. 4-8) describes
A flow is a stream of packets being exchanged between any two
addresses in the network. For each protocol there are known to
be several fields, such as the destination (recipient), the source
(the sender), and so forth, and these and other fields are used in
monitor 300 to identify the flow.
Appeal 2014-007352
Reexamination Control 95/001,510
Patent 7,395,349 B1

7
Dietz (col. 33, ll. 28-33) describes “the flow keys are built
consistently in a particular order no matter what the direction of
conversation. Several mechanisms may be used to achieve this. In the
particular embodiment, the numerically lower address is always placed
before the numerically higher address.”
By defining each network device by its sent flow, a first network
device sends a first flow to a second network device, and the second network
device sends a second flow to the first network device. Dietz teaches the
same flow key is constructed for flow in either direction. In order to assure
that the flow in either direction results in the same flow key, Dietz compares
the source address to the destination address, and this comparison identifies
the flow, which by definition, identifies the sending network device for the
flow. See Dietz, col. 12, ll. 4-8; col. 33, ll. 28-33.
Thus, Dietz teaches the recited determining whether the received
packet is from the first network device based on a comparison of a first
packet header field to a second packet header field. The broad claim
language does not preclude a finding that Dietz teaches the argued
limitations.
We, therefore, sustain the Examiner’s rejection of claim 12 as obvious
over Foundry Networks and Dietz.

THE REMAINING REJECTIONS OVER THE PRIOR ART
Review of alternative prior art bases for rejection to claims, which
have already been determined to be appropriately rejected over the prior art,
is discretionary. See, e.g., In re Gleave, 560 F.3d 1331, 1338 (Fed. Cir.
Appeal 2014-007352
Reexamination Control 95/001,510
Patent 7,395,349 B1

8
2009) (not reaching rejections based on obviousness when claims already
rejected as anticipated). We exercise our discretion and decline to reach the
merits of the remaining rejections over the prior art.

ORDER
The Examiner’s decision rejecting claims 11-13 is affirmed.
Requests for extensions of time in this inter partes reexamination
proceeding are governed by 37 C.F.R. § 1.956. See 37 C.F.R. § 41.79.
In the event neither party files a request for rehearing within the time
provided in 37 C.F.R. § 41.79, and this decision becomes final and
appealable under 37 C.F.R. § 41.81, a party seeking judicial review must
timely serve notice on the Director of the United States Patent and
Trademark Office. See 37 C.F.R. §§ 90.1 and 1.983.

AFFIRMED

Appeal 2014-007352
Reexamination Control 95/001,510
Patent 7,395,349 B1

9
PATENT OWNER:

F5 NETWORKS, INC.
C/O LOWE GRAHAM JONES PLLC
701 5th Avenue, Suite 4800
Seattle, WA 98104

THIRD PARTY REQUESTER:

FINNEGAN, HENDERSON, FARABOW
GARRETT & DUNNER LLP
901 New York Avenue, N.W.
Washington, DC 20001-4413