Ex Parte 7756965US et al

Patent Trial and Appeal Board

Dec 16, 2014

95001827 (P.T.A.B. Dec. 16, 2014)

UNITED STATES PATENT AND TRADEMARKOFFICE
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,827 11/18/2011 7756965US 11517.0015-01000 4287
65761 7590 12/16/2014
SAN FRANCISCO OFFICE OF
NOVAK DRUCE CONNOLLY BOVE + QUIGG LLP
1000 LOUISIANA STREET
FIFTY-THIRD FLOOR
HOUSTON, TX 77002
EXAMINER
RIMELL, SAMUEL G
ART UNIT PAPER NUMBER
3992
MAIL DATE DELIVERY MODE
12/16/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)
1

UNITED STATES PATENT AND TRADEMARK OFFICE
_____________

BEFORE THE PATENT TRIAL AND APPEAL BOARD
______________

BROCADE COMMUNICATIONS SYSTEMS, INC.,
Patent Owner and Appellant

v.

A10 NETWORKS, INC.,
Requester
______________

Appeal 2014-006854
Reexamination Control No. 95/001,827
United States Patent 7,756,965 B21
Technology Center 3900
______________

Before JOHN C. MARTIN, JAMES T. MOORE, and
MAHSHID D. SAADAT, Administrative Patent Judges.

MARTIN, Administrative Patent Judge.

1 This patent (hereinafter “’965 patent”) is based on Application
12/353,701, filed on January 14, 2009, as a continuation of Application
10/840,496, filed on May 6, 2004 (now Patent 7,496,651). Claims 6 and 12
of the ’965 patent have been modified by a Certificate of Correction dated
November 2, 2010. Claims 1, 12, 13, 15, 17, and 18 of the ’965 patent have
been canceled by Ex Parte Reexamination Certificate US 7,756,965 C1
(discussed infra), which issued on May 9, 2014, in ex parte reexamination
proceeding 90/011,761.
Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

2

DECISION ON APPEAL
Brocade Communications Systems, Inc. (hereinafter “Patent Owner”)
appeals the Examiner’s rejections of original claims 1-13, 15-21, and 23 of
the ’965 patent. See Appellant’s Appeal Brief Pursuant to 37 C.F.R. § 41.67
(hereinafter “Brief”), filed on December 17, 2013, at 3. Requester
(hereinafter “A10 Networks”) withdrew from further participation in this
proceeding on June 13, 2013, and therefore did not file a respondent brief.2
We have jurisdiction under 35 U.S.C. §§ 6, 134, and 315.
Because claims 1, 12, 13, 15, 17, and 18 have been canceled by the
aforementioned Ex Parte Reexamination Certificate US 7,756,965 C1, this
appeal is dismissed with respect to these claims, thereby leaving the
rejections of only dependent claims 2-11, 16, 19-21, and 23 for our
consideration.
We AFFIRM.

2 Specifically, the “Notice of Withdrawal of Third Party Requester A10
Networks, Inc.,” filed on June 13, 2013, states (at page 1):
Third Party Requester, A10 Networks, Inc. (‘A10’), has
entered into a settlement agreement with the Patent Owner,
Brocade Communications Systems, Inc., and as such is
withdrawing from this proceeding. A10 will make no further
comment or otherwise participate in the proceeding and further
withdraws any pending petition and/or opposition A10 filed.
Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

3

I. STATEMENT OF THE CASE
A. Related Litigation and Reexamination Proceedings
The ’965 patent is the subject of litigation (now concluded) styled:
Brocade Communications Systems, Inc. v. A10 Networks, Inc., Case No. 10-
CV-03428-LHK (N.D. Cal). Br. 2.
The ’965 patent was also involved in ex parte reexamination
proceeding 90/011,761, which was initiated by a Request for Ex Parte
Reexamination (“Ex parte Request”) filed by A10 Networks on June 27,
2011.3 The Ex parte Request asserted that claims 1, 12, 13, 15, 17, and 18
(of which claims 1, 12, and 18 are all of the independent claims of the ’965
patent) are unpatentable under 35 U.S.C. § 102(b) for anticipation by
Foundry ServerIron Installation and Configuration Guide (May 2000)
(hereinafter “ServerIron”), which is one of the references relied on in the
rejections before us in this appeal.4 The cover page of ServerIron shows a
copyright date of 1997-2000 by Foundry Networks. Ms. Prajakta S. Joshi,
identified in the ’965 patent as the sole inventor, testified that Foundry
Networks was acquired by (Patent Owner) Brocade Communications

3 As noted above, the “Request for Inter Partes Reexamination” that
initiated this inter partes reexamination proceeding is referred to herein as
the “Request.”
4 ServerIron is cited in the Brief in this inter partes proceeding as “Foundry
ServerIron Guide” (Br. 3, 1st para.), “Foundry Server Iron” (id. at 6, sec. VI;
quoting RAN 3-5), and “Conf. Guide” (id. at 14, sec. D). ServerIron is cited
(Continued on next page.)
Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

4

Systems, Inc. after April 2002. Declaration of Prajakta S. Joshi under
37 C.F.R. 1.132 (hereinafter “Joshi Declaration”) (Br. Ex. 2), para. 3.5
In a Final Office action mailed in the ex parte proceeding on
March 26, 2012, the Examiner (at page 2) rejected claims 1, 12, 13, 15, 17,
and 18 under 35 U.S.C. § 102(b) for anticipation by ServerIron.
This rejection was sustained by the Patent Trial and Appeal Board
(“Board”) with respect to all of the rejected claims at page 45 of a Decision
on Appeal mailed on December 19, 2013 (hereinafter “’750 Appeal
Decision”), which (e.g., at page 2, footnote 2) refers to ServerIron as “Conf.
Guide.” Patent Owner did not request rehearing by the Board or seek
judicial review.
Claims 1, 12, 13, 15, 17, and 18 accordingly were canceled by Ex
Parte Reexamination Certificate US 7,756,965 C1, which issued on May 9,
2014 (hereinafter “Ex Parte Reexamination Certificate”).
The following reexamination proceedings, also initiated by
A10 Networks, involve Patent US 7,899,899 B2, of which the ’965 patent is
the parent:

by Requester as “Conf. Guide” (e.g., Request 4).
5 This Joshi Declaration (executed on May 5, 2012) was filed in this inter
partes proceeding on May 14, 2014, and in the ex parte reexamination
proceeding on May 25, 2012. A second declaration (executed on August 16,
2012) by Ms. Joshi was filed on August 24, 2012, in the ex parte proceeding
but was not filed in this inter partes proceeding.
Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

5

(i) Inter partes proceeding 95/001,826, which concluded on April 22,
2014, with the issuance of Inter Partes Reexamination Certificate
US 7,899,899 C1, canceling all of the patent claims (viz., claims 1-12); and
(ii) Ex parte proceeding 90/011,760, which was terminated on
September 19, 2014, in view of the cancelation of all patent claims by Inter
Partes Reexamination Certificate US 7,899,899 C1.

B. The Invention Described in the ’965 Patent
The invention described in the ’965 patent relates generally to load
balancing among servers and more particularly to load balancing based on
identifying a geographically optimum server to receive a client request.
’965 patent 1:17-23.
Figure 1 of the ’965 patent is reproduced below.
Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

6

Figure 1 illustrates an example of a GSLB (global server load balancing6)
system with which an embodiment of the invention can be implemented.

6 ’965 patent 1:57.
Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

7

Id. at 3:11-12. A GSLB switch 12 acts as a proxy for an authoritative
Domain Name System (DNS) server 16 for a domain, such as
“foundrynet.com.” Id. at 4:21-24. GSLB switch 12 communicates via
Internet 14 with site switches 18A and 18B at site 20 and with site switches
22A and 22B at site 24. Id. at 4:30-33. Site switches 18A, 18B, 22A and
22B connect routers 19 and 21 to servers 26A to 26N. Id. at 4:34-36.
Although the authoritative DNS server 16 provides the actual DNS service,
the IP address known to the rest of Internet 14 for the authoritative DNS
server 16 of domain “foundrynet.com” is a virtual IP (VIP) address
configured on GSLB switch 12. Id. at 4:24-29.
The ’965 patent describes the conventional steps involved in
identifying an optimal server for a client request at column 4, lines 55 to 65.
These steps correspond to the numbered steps in Figure 7.1 in ServerIron’s
Chapter 7 (“Configuring Global Server Load Balancing”), which consists of
pages 7-1 to 7-70. Figure 7.1, which appears at page 7-2, is reproduced
below.

Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

8

Figure 7.1 shows an example of a GSLB configuration in which a “GSLB
ServerIron” (i.e., a ServerIron configured for GSLB) is connected to an
authoritative DNS for a specific domain. ServerIron 7-2. The numbered
operational steps 1-5 that appear in this figure are reproduced below:
Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

9

1. The client’s local DNS sends a recursive query for
foundrynet.com.
2. The GSLB ServerIron, as proxy for the authoritative DNS,
forwards the lookup request from the client’s local DNS to the
authoritative DNS. . . .
3. The authoritative DNS for foundrynet.com answers the
client’s query (forwarded by the GSLB ServerIron) by sending
a list of IP addresses for the sites that correspond to the
requested host.
4. The GSLB ServerIron assesses each IP address in the DNS
reply to determine the optimal site for the client, and moves the
address for that site to the top of the list.
5. The client receives a reordered list of IP addresses. Typical
clients use the first address in the list. Since the ServerIron has
optimized the list for the client, the first address is the best
address.
Id. (emphasis added).
The invention described in the ’965 patent specifically is directed to
step 4, i.e., identifying the optimal server for responding to a client request.
More particularly, the invention is an improvement of the prior art technique
of using geographic proximity to select the optimal server. See ’965 patent
2:6-10 (“A criterion that is sometimes used for load balancing purposes is
geographic location. That is, where there are multiple geographically
located servers, load balancing systems attempt to direct client requests to a
server that is geographically the closest to the client.”). The ’965 patent
Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

10

refers to this geographic proximity technique as a “geographic metric.” Id.
at 6:37-39. The geographic locations of clients and servers typically are
determined using a static table containing Internet Assigned Numbers
Authority (IANA)-allocated IP address prefixes and their associated
geographic locations. ’965 patent 2:10-14. However, load balancing
systems based on static mappings between the IP address prefixes and the
geographic locations have drawbacks that can lead to less than optimum
performance. Id. at 2:14-17. One such drawback is described as follows:
[A] prefix 149.204.0.0/16 may be specified as being in the
geographic region EUROPE in a load balancing switch’s
internal static geographic prefix database. If the user has a
client with an address of 149.204.11.1, which actually resides
in ASIA, there is currently no suitable technique in which the
user can override the geographic region for the prefix specified
in the database. This means that the load balancing switch will
always treat the client at 149.204.11.1 as being in the
geographic region EUROPE, even though the user wants the
prefix to be associated with ASIA.
Id. at 2:39-50 (emphasis added).
The Brief refers to the geographic region that is stored in the static
geographic prefix database (i.e., Europe in this example) as “the geographic
region that a device using the claimed network address is perceived to be
originating from or reside at.” Br. 11 (emphasis added).
The invention described in the ’965 patent solves the above-identified
problem by providing a user-configurable geographic prefix feature that
Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

11

permits a user to associate a prefix (or other address portion) with a
geographic region that can be “a continent, country, state, city, or other user
defined area.” ’965 patent 3:49-56. The user-configured geographic prefix
information is stored in a user-configurable geographic prefix database. Id.
at 8:50-53. As explained below, the ’965 patent describes this user-
configured geographic region as the geographic region in which a device
having the corresponding address prefix is “deemed to reside.”
Patent Owner uses the phrase “deemed to reside” to describe the
inaccurate relationship recorded in the static geographic prefix database and
also to describe the accurate relationship recorded in the user-configurable
geographic prefix database. See Br. 13 (“[T]he specification of the ‘965
patent consistently explains that the associated/corresponding geographic
region is where the device having the address prefix or address is deemed to
reside.”) (quoting Declaration of Brian D’Andrade Under 37 C.F.R. 1.132
(hereinafter “D’Andrade Declaration”) (Br. Ex. 1) para. 12).7
If the address prefix configured by the user also exists in the static
internal geographic database maintained by the load balancing switch, the
geographic region stored in the internal static geographic database will be
overridden by the user-configured geographic region. Id. at 3:61-63. For

7 This declaration, which was also considered in the ex parte proceeding, is
misidentified at Brief page 36 as the “Devarapalli Declaration.” Dr.
D’Andrade’s testimony regarding claim interpretation was accorded no
(Continued on next page.)
Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

12

example, if the address prefix 200.0.0.0/8 represents South America in the
internal static geographic database, and if the user configures the same to be
in the region North America, the user-configured entry will “override” the
earlier (i.e., static) entry, with the result that any IP address that “matches”
the prefix 200.0.0.0/8 will be “deemed to reside” in North America. Id.
at 3:61-4:2.
This geographic override feature is applied to address prefixes in
client addresses and host (i.e., server) addresses. See id. at Abstract (“The
geographic settings in the second database can override the information in
the first database. These geographic entries help determine the geographic
location of a client and host IP addresses, and aid in directing the client to a
host server that is geographically the closest to that client.”).
Figure 2 of the ’965 patent is reproduced below.

weight in the ex parte proceeding. ’750 Appeal Dec. 28-31.
Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

13

Figure 2 is a block diagram showing the functional modules of an
embodiment of GSLB switch 12 and site switch 18A (for example) that are
relevant to the global server load balancing function, including functions and
features associated with geographic data. Id. at 5:40-44. In GSLB switch
12, a GSLB switch controller 201 is coupled to (i) a first storage unit 212
that contains “IANA-allocated geographic prefixes and associated
geographic designation, or default geographic-related settings” and (ii) a
second storage unit 210 that contains user-configured geographic settings.
Id. at 6:17-24.
Figure 4 of the ’965 patent is reproduced below.
Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

14

Figure 4 is a flowchart 400 illustrating the configuration of geographic
prefix data according to an embodiment of the GSLB system described in
Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

15

the ’965 patent. Id. at 8:44-45. At block 402, the user (e.g., a system
administrator) uses switch controller 201 of GSLB switch 12 to configure a
geographic prefix, such as by setting the geographic region for the prefix
149.204.0.0/16 to be Europe. Id. at 8:45-49.
At block 404, GSLB switch 12 maintains the user-configured
geographic region for the prefix in a user-configurable geographic prefix
database (“DY-GEO-DB”). Id. at 8:50-53. This database is maintained in
second storage unit 210. Id. at 8:53-56.
As shown in block 406, if the above prefix already exists in the static
internal geographic database (“ST-GEO-DB”) maintained in first storage
unit 212, the user configuration takes precedence over that static entry. Id.
at 8:57-61.
Block 408 shows application of the user-configured geographic
information to domain (i.e., server) addresses. Specifically, “[a]t block 408,
the GSLB switch 12 updates the geographic region for all the IP addresses
(for the domains for which the GSLB switch 12 is providing GSLB) that
match the above IP address prefix so as to reflect the new geographic region
configured by the user.” Id. at 8:61-66. Block 408 is shown in further
detail in Figure 5. Id. at 8:66-67.
Figure 5 is reproduced below.
Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

16

Figure 5 is a flowchart 500 that depicts the updating of the geographic
region of domain (i.e., server) IP addresses with the user-configured
geographic prefix according to an embodiment. Id. at 9:1-3. That is,
“[w]hen the user configures a geographic prefix at the block 402 of FIG. 4,
then the GSLB switch 12 updates the geographic [region of the] prefix for
Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

17

each IP address in the domain for which the GSLB switch 12 is providing
GSLB.” Id. at 9:4-7.
As explained below, the flowchart depicted in Figure 6 (consisting of
Figures 6A and 6B) shows the application of a user-configured geographic
location to client IP addresses. Figure 6A is reproduced below.
Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

18

Figures 6A and 6B show a flowchart 600 that depicts operation of the GSLB
system of Figure 1 to use geographic settings, including user-configured
settings, to perform load balancing according to an embodiment. Id. at
9:44-47. At block 602, a client program 28, located at a client IP address
Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

19

(CIP), makes a DNS query for a domain for which GSLB switch 12 is
providing GSLB. Id. at 9:47-50. GSLB switch 12 then (at block 604)
checks its user-configured geographic prefix database (“DY-GEO-DB”) to
determine if any prefix configured therein matches the CIP. Id. at 9:51-54.
If a match is found (at block 606), and if the user-configured prefix has a
geographic region G1, the CIP (at block 608) is “deemed to be” in
geographic region G1. Id. at 9:54-57.
GSLB switch 12 next (at block 610) makes a selection of the best IP
address to provide to the client program 28 based at least in part on the
geographic metric. Id. at 9:57-59.

C. Claim 1
Claim 1 (now canceled) reads as follows:
1. A method, comprising:
storing first address prefix information and corresponding first
geographic region information;
storing second address prefix information and corresponding
second geographic region information; and
for network addresses that have first address prefix information
that matches the second address prefix information,
associating these network addresses to the second

Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

20

geographic region information, which is different from
said corresponding first geographic region information.
’965 patent col. 11.8
The Brief, comparing claim 1 to the embodiment described in the ’965
patent, reads the recited “first geographic region information” and “second
geographic region information” on that embodiment as follows:
“[T]the claimed invention allows a system administrator to store an
association of address prefix information with second region information
that is different than first region information originally assigned to that
prefix by the IANA.” Br. 5.

D. This Inter Partes Reexamination Proceeding
As explained at page 97 of the “Request for Inter Partes
Reexamination” (hereinafter “Request”), filed on November 18, 2011, the
proposed rejection for anticipation by ServerIron is directed to only
dependent claims 2-5, 8, 10, 11, 16, 19-21, and 23 and thus does not apply to
any of the claims rejected on this ground in the ex parte proceeding (viz.,
claims 1, 12, 13, 15, 17, and 18). The Request further explains the claim
charts used to describe the proposed rejection of claims 1, 15, and 18 in the

8 The claims as reproduced in the Claim Appendix (Br. 31-32) lack the
paragraph structure employed in the ’965 patent.
Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

21

ex parte proceeding are reproduced in the Request “simply for the
Examiner’s convenience.” Id.
However, the claims rejected by the Examiner for anticipation by
ServerIron in this inter partes proceeding include independent claims 1 and
18 because claims 2-5, 8, 10, and 11 depend therefrom. RAN 3-4, Issue #3.
Regarding this ground of rejection, the Examiner declined to enter the
proposed rejection of claim 16, which depends on independent claim 12
(though claim 15), because “[i]n the Order for Reexamination at page 5, an
indication was made that no reasonable likelihood to prevail would exist for
this issue [as to claim 16].” RAN 3-4, Issue #3. Specifically, as explained at
page 5 (Issue #3) of the “Order Granting/Denying Request for Inter Partes
Reexamination”: “The claim charts at pages 97-135 in the request do not
provide correlation to claim 12, so the proposed issue for claim[] 12 and its
dependent claim 16 will not have [a] reasonable likelihood to prevail, since a
dependent claim cannot be rejected unless the same applied rejection is
demonstrated for the independent claim.”
For the above reasons, the claims rejected by the Examiner for
anticipation by ServerIron consist of claims 1-5, 8, 10, 11, 18-21, and 23.
RAN 4, Issue #3.
Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

22

The Request (at page 136) proposes to reject only claims 2, 3, 6, 19,
and 20 for obviousness over ServerIron in view of AAPA.9 The Examiner’s
rejection additionally includes independent claims 1 and 18 because claims
2, 3, 6, 19, and 20 are dependent thereon and because “the claim[] charts at
pages 136-159 provide the appropriate additional mapping to claims 1 and
18.” RAN 4, Issue #4. The claims rejected on this ground therefore consist
of claims 1-3, 6, and 18-20. Id. at 5, Issue #4.
The proposed rejections for anticipation by 3-DNS10 (Request 10-55)
and Skene11 (id. at 55-97) were adopted by the Examiner without changing
the identification of the proposed rejected claims. RAN 2-3, Issues #1-#2.
A Non-Final Office Action entering the above-identified rejections
was mailed on February 13, 2012.
Patent Owner’s May 14, 2012, “Office Action Response” (hereinafter
“PO Non-Final Action Resp.”), filed on February 11, 2012, was
accompanied by the aforementioned Joshi Declaration and D’Andrade
Declaration.

9 Applicant’s Admitted Prior Art, identified at Request page 9 as the subject
matter described in the ’965 patent at “1:56-60,” “2:6-14,” “2:18-24,” and
“2:39-450 [sic, 2:39-50],” all found under the heading “Background
Information.” The Request at page 149 (discussing claim 6) additionally
identifies “1:45-48” of the ’965 patent as part of the AAPA.
10 3-DNS Ref. Guide, version 4.2 (date addressed infra).
11 Bryan D. Skene, et al., US 7,441,045 B2, issued on October 21, 2008.
Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

23

Requester on June 13, 2012, filed “Third Party Requester’s Comments
Under 35 U.S.C. § 314(B)(2) and 37 C.F.R. § 1.947” (hereinafter cited as
“Req. Non-Final Action Comments”).
All of the grounds of rejection were maintained at pages 2-5 of the
Action Closing Prosecution (ACP), mailed March 30, 2013, and again at
pages 2-5 of the Right of Appeal Notice (RAN), mailed on September 18,
2013.
A petition12 by Patent Owner to terminate this inter partes
reexamination proceeding as a result of a final decision in the above-
identified litigation was dismissed in a USPTO decision mailed on
August 30, 2013.13
The Brief was filed on December 17, 2013, which is two days prior to
the mailing date of the ’750 Appeal Decision.
The Examiner’s Answer, mailed on February 19, 2014, incorporates
the RAN by reference without providing any additional comments.
Patent Owner did not file a rebuttal brief (as authorized by 37 C.F.R.
§ 41.71).
The aforementioned Ex Parte Reexamination Certificate (canceling
claims 1, 12, 13, 15, 17, and 18) issued on May 9, 2014.

12 “Patent Owner’s Petition Under 37 C.F.R. § 1.182 To Terminate the
Reexamination Proceedings,” filed July 10, 2013.
13 “Decision Dismissing Petition To Terminate Inter Partes Reexamination
(Continued on next page.)
Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

24

E. The Rejections
The RAN applies the grounds of rejection to the claims (including
now canceled claims 1, 12, 13, 15, 17, and 18) as follows:
Claims ServerIron
under
35 U.S.C.
§ 102

(RAN 4,
Issue #3)
ServerIron + AAPA
under 35 U.S.C. §103(a)

(RAN 4-5, Issue #4)
3-DNS
under
35 U.S.C.
§ 10214

(RAN 2-3,
Issue #1)
Skene
under
35 U.S.C.
§ 10215

(RAN 3,
Issue #2)
1-3 X X X X
4-5 X X X
6 X
7 X X
8 X X X
9 X
10-11 X X X
12-13
and 15-
17
X X
18-19 X X X X
20 X X X
21 and 23 X X X

Proceeding.”
14 The claims rejected on this ground are incorrectly identified at Brief
page 22 (heading F and succeeding sentence) as claims “1-5, 8, 10, 11, 18-
21, and 23,” which are the claims the Examiner rejected for anticipation by
ServerIron.
15 The claims rejected on this ground likewise are incorrectly identified at
Brief page 27 (heading G) as claims “1-5, 8, 10, 11, 18-21, and 23.”
Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

25

The Request did not propose, and the Examiner did not enter, a
rejection of dependent claims 14 and 22.

II. DISCUSSION
A. Claim Interpretation in the ’750 Appeal Decision
In this inter partes reexamination proceeding, Patent Owner repeats
the claim interpretation arguments that were addressed in the ’750 Appeal
Decision, which is incorporated by reference in its entirety in this opinion.
One argument is directed to the meaning of “corresponding” in
claim 1’s first step (“storing first address prefix information and
corresponding first geographic region information”) and second step
(“storing second address prefix information and corresponding second
geographic region information”). Patent Owner argues: “A person of
ordinary skill in the art reading the ‘965 patent would therefore only
understand that the associated/corresponding geographic region in the claims
of the ‘965 patent is where a device having the address prefix is deemed to
be residing.” Br. 13 (quoting D’Andrade Decl. para. 12) (emphasis added).
In the ’750 Appeal Decision, we concluded that claim 1’s first and
second steps do not require a “deemed to reside” interpretation. ’750 Appeal
Decision 5-6, 20-33. Specifically, we concluded that a “deemed to reside”
claim interpretation violates the principle that “[i]t is . . . improper, when
giving claims their broadest reasonable interpretation, to read limitations
Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

26

from the specification into the claims.” Id. at 20 (quoting Phillips v. AWH
Corp., 415 F.3d 1303, 1323 (Fed. Cir. 2005) (en banc)).
We therefore also disagreed (id. at 20-21) with Patent Owner’s
argument that neither of claim 1’s first and second steps can be read on a
source-to-destination relationship between a client request and a destination
server. This argument is stated as follows in this inter partes proceeding:
A primary point of disagreement between the Appellant
and the Examiner is whether a person of ordinary skill in the art
would understand whether claim 1 (and similarly claims 12
and 18) can be unreasonably interpreted to be so broad as to
encompass the disclosure within a reference that instructs a
switch to route received requests coming from a device that has
a particular address prefix to a particular site switch2 (which as
the Examiner notes, must be in a geographic region). Appellant
contends that such an interpretation of the claims is not
reasonable in light of the specification as no embodiment within
the specification supports such an interpretation.
Br. 7-8. Footnote 2 of the above-quoted passage reads as follows:
“Throughout the proceeding the Appellant refers to technologies of this type
as ‘source-to-destination’ technologies because network equipment
identifies a source of a DNS request and directs the source to a specified
destination to access the network resource.” Id. at 7 n.2.
We found this “source-to-destination” preclusion argument
unpersuasive because claim 1 does not restrict the manner in which the
recited “first address prefix information” corresponds to the “first
geographic region information” or the manner in which the “second address
Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

27

prefix information” corresponds to the “second geographic region
information.” ’750 Appeal Dec. 20-21. Thus, as explained in greater detail
infra in the discussion of ServerIron, we further found that both of claim 1’s
first and second steps read on the source-to-destination relationships
described by ServerIron’s affinity definitions. Id. at 33-45.
Patent Owner also describes claim 1 as “limited to overriding the
geographic region information that a device using the claimed network
address is perceived to be originating from or reside at”). Br. 12 (emphasis
added). This “override” interpretation is unpersuasive for the reasons given
at pages 28 and 32 of the ’750 Appeal Decision. However, we found that
claim 1 is anticipated by ServerIron’s affinity definitions even if Patent
Owner’s “override” interpretation is assumed to be correct. Id. at 38.

B. Review of the Sustained Rejection of (Now Canceled) Claim 1 for
Anticipation by ServerIron
The Ex Parte Request did not propose to read claim 1’s first step
(“storing first address prefix information and corresponding first geographic
region information”) on ServerIron’s affinity feature. Instead, the Ex parte
Request reads this step on ServerIron’s description of “storing AINA
(geographic) allocated address prefixes with corresponding geographic
region information (ASIA, EUROPE, etc.).” Ex parte Request 6,
limitation 1.1 (reproduced at Request 98, limitation 1.1).
Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

28

The Ex parte Request reads only claim 1’s second step (“storing
second address prefix information and corresponding second geographic
region information”) on ServerIron’s affinity feature. Request 8, limitation
1.2. The affinity feature “configures the GSLB ServerIron to always prefer
a specific site ServerIron for queries from clients whose addresses are within
a given IP prefix,” such as “[w]hen you want to use a site located near
clients within a private network for all queries from the private network.”
ServerIron 7-38.
ServerIron’s Figure 7.10 (appearing at ServerIron page 7-39 and
reproduced at ’750 Appeal Dec. 34) is reproduced below.
Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

29

As stated in its caption, Figure 7.10 shows an example of the affinity feature.
Step 4 in this figure reads as follows:

Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

30

4. The GSLB ServerIron checks for an affinity configuration
that has an IP prefix that contains the client’s IP address.
If one exists, and if the DNS reply contains a VIP configured on
the ServerIron associated with the IP prefix, the ServerIron
checks the health of the VIP.

If the VIP passes the health checks, the ServerIron places the
VIP at the top of the list in the DNS reply.
Id. at 7-39 (emphasis added).
As explained at page 36 of the ’750 Appeal Decision, the Examiner’s
rejection of claim 1 in the ex parte proceeding read claim 1’s first and
second steps on ServerIron’s following description of using two different
affinity definitions to associate client prefixes with site ServerIrons located
in Sunnyvale and Atlanta, respectively:
ServerIron(config) # gslb affinity
ServerIron(config-gslb-affinity) # prefer sunnyvale slb-1 for
0.0.0.0/0
ServerIron(config-gslb-affinity) # prefer atlanta slb-1 for
192.108.22.0/22
These commands configure a default affinity definition (using
the 0.0.0.0/0) prefix and an affinity definition that uses prefix
192.108.22.0/22. For clients that are not within the prefix in the
second affinity definition, the ServerIron uses the default
affinity definition. The ServerIron sends clients whose IP
addresses are within the 192.108.22.0/22 prefix to a VIP on
slb-1 at the “atlanta” site, when available. The ServerIron sends
Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

31

all other clients to a VIP on slb-1 at the “sunnyvale” site when
available.
’750 Appeal Dec. 36 (quoting ServerIron 7-40) (emphasis added). These
two affinity definitions are described as “default” and “specific” affinity
definitions at page 36 of the ’750 Appeal Decision.
As noted above, we disagreed with Patent Owner’s “deemed to
reside” interpretation of claim 1’s first and second steps and the argument
that neither of these claim steps can be read on a source-to destination
relationship. We accordingly found that claim 1’s first step reads on either
one of the default and specific affinity definitions and that the second claim
step reads on the other one of these affinity definitions. ’750 Appeal Dec.
37-38. We further found that claim 1’s third step is satisfied even assuming
Patent Owner is correct to interpret it as reciting an “override” function.
Specifically, we stated:
[A]ssuming for the sake of argument [as argued by Patent
Owner] that an override operation is required by the claim
language, this requirement can be accommodated by reading the
claimed “second address prefix information and corresponding
second geographic region information” on the specific affinity
definition, which effectively overrides the default definition for
client addresses that match the address prefixes given in both
affinity definitions.
Id. at 38.

Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

32

C. The Rejection for Anticipation by ServerIron (Claims 1-5, 8, 10, 11, 18-
21, and 23, of Which Claims 1 and 18 Have Been Canceled)
Patent Owner, in addressing this ground of rejection, treats dependent
claims 2-5, 8, 10, 11, 19-21, and 23 as standing or falling with (now
canceled) independent claims 1 and 18. See Br. 19 (“[B]y virtue of being
dependent on patentable base claims, all rejected dependent claims should
also be considered patentable over [ServerIron].”).
We therefore summarily sustain the rejection of dependent claims 2-5,
8, 10, 11, 19-21, and 23 under 35 U.S.C. § 102(b) for anticipation by
ServerIron for the same reasons that we sustained the rejection of claims 1
and 18 on this ground in the ’750 Appeal Decision, which resulted in
cancelation of these (and other) claims by the Ex Parte Reexamination
Certificate.

D. The Rejection for Obviousness over ServerIron View of AAPA (Claims 1-
3, 6, and 18-20, of Which Claims 1 and 18 Have Been Canceled)
Because claims 1 and 18 have been canceled and because we
summarily have sustained the rejection of claims 2, 3, 19, and 20 for
anticipation by ServerIron, it is not necessary to address the rejection of any
of these claims for obviousness over ServerIron in view of AAPA. This
leaves only claim 6, which is dependent upon canceled claim 1, for our
consideration on this ground.
Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

33

Claim 6 is not reproduced below, because both of Patent Owner’s
arguments against this ground of rejection are limited to (now canceled)
independent claims 1 and 18, which were determined in the ’750 Appeal
Decision to be anticipated by ServerIron. The first of these arguments faults
the claim charts at Request pages 136-41 and 150-54 for failing to explain
how the alleged AAPA is being applied to claims 1 and 18:
[W]hile independent claims 1 and 18 are rejected for being
obvious in view of ServerIron Conf. Guide and alleged AAPA,
neither the Request nor the Office Action specifically identified
the particular passage of the ‘965 patent that is being applied as
alleged AAPA for the rejection of claims 1 and 18. It is
respectfully submitted that such failure to identify the alleged
AAPA and how such alleged AAPA is being applied to reject
claims 1 and 18 amounts to a failure to articulate why a person
skilled in the art would combine the teachings, as required by
KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 418 (2007).
Br. 19, sec. E (footnote omitted). This argument clearly does not apply to
claim 6, whose corresponding claim chart explains (at Request page 149)
how the proposed rejection is based on the alleged AAPA.
As an alternative to the first argument, the second argument assumes
that the rejection of claims 1 and 18 is based on the alleged AAPA passages
relied on in the proposed rejection of claim 6 (at Request 149). Specifically,
Patent Owner argues:
[P]age 149 of the Request points to a passage in column 2,
lines 39-50 [sic, 39-47] in the background section of the ‘965
patent for being alleged AAPA, to support the rejection of
Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

34

dependent claim 6. Assuming arguendo and hypothetically that
this passage is the non-specified alleged AAPA that is being
combined with ServerIron Conf. Guide to reject independent
claims 1 and 18, then the obviousness rejection of claims 1 and
18 should nevertheless still be withdrawn.
Br. 20. Patent Owner does not argue the merits of claim 6 separately from
the merits of parent claim 1.
We therefore find that Patent Owner has not demonstrated error in the
Examiner’s conclusion that the subject matter of claim 6 prima facie would
have been obvious from ServerIron in view of AAPA.
Patent Owner contends that nonobviousness nevertheless is
demonstrated by the evidence offered to show copying. Br. 22. In support,
Patent Owner cites Diamond Rubber Co. v. Consol Rubber Tire Co., 220
U.S. 428, 440-41 (1911) for the proposition that “copying by an infringer is
evidence of nonobviousness because it reflects the infringer’s belief in the
nonobviousness of the claimed invention.” Br. 22.
According to Patent Owner (id.), copying is demonstrated by the
following documents from the above-identified litigation:
(1) Paragraphs 23-39 of the “Third Amended Complaint for Patent
Infringement, Copyright Infringement, Trade Secret Misappropriation . . .”
(Br. Ex. 5) (hereinafter “Exhibit 5”);16 and

16 Incorrectly identified at Brief page 22 as pertaining to Patent 7,899,899.
Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

35

(2) “Exhibit J: Brocade’s Infringement Claim Chart For U.S. Patent
7,756,965” (Br. Ex. 6) (hereinafter “Exhibit 6”), which is described as
“presenting text from manuals for A10 Networks’ products evidencing
infringement and copying of the ‘965 patent invention.” Br. 22.
This evidence is entitled to no consideration with respect to the
subject matter recited in parent claim 1, because that subject matter has been
determined to unpatentable for anticipation by ServerIron, whereas
“secondary considerations” are relevant to only obviousness. See Cohesive
Technologies Inc. v. Waters Corp., 543 F.2d 1351, 1364 (Fed. Cir. 2008)
(“[O]bviousness requires analysis of secondary considerations of
nonobviousness, while secondary considerations are not an element of a
claim of anticipation.”).
Although claim 6 stands rejected for obviousness, the foregoing
evidence is unpersuasive because it fails to demonstrate copying of the
features recited in this claim. Instead, Exhibit 5 when discussing (at
paragraphs 156-64) the ’965 claims broadly alleges (at paras. 159-60) direct
or indirect infringement of “one or more claims of the ‘965 Patent,” and
Exhibit 6 discusses only claims 1, 12, 13, 17, and 18 of the ’965 patent.
Therefore, we sustain the rejection of claim 6 under 35 U.S.C.
§ 103(a) for obviousness over ServerIron in view of AAPA.

Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

36

E. The Rejection for Anticipation by 3-DNS (Claims 1-5, 7, 8, 10-13, 15-19,
21, and 23, of Which Claims 1, 12, 13, 15, 17, and 18 Have Been
Canceled)
The Examiner’s rejection for anticipation by 3-DNS in this inter
partes proceeding is based on Chapter 13 (“Topology”). As explained
below, we additionally rely on Chapter 8 (“Load Balancing”). The rejection
is under 35 U.S.C. § 102(a) and the ’965 patent has an effective filing date
of May 6, 2004.
Patent Owner states: “Appellant maintains its position with respect to
3-DNS not being publicly available as set out in the response to the Action
Closing Prosecution.” Br. 27 (presumably referring to PO ACP Resp. 18-
22).
The same argument by Patent Owner was addressed and found
unpersuasive at pages 17-26 of the Board’s December 23, 2013, Decision on
Appeal in Appeal 2013-008244 (hereinafter “’244 Appeal Decision”), which
hereby is incorporated by reference in this opinion. That was an appeal in ex
parte reexamination proceeding 90/011,765 for reexamination of Patent
7,584,301 B1 (“’301 patent”), which is owned by Patent Owner, has a May
6, 2004, (actual) filing date, and names Ms. Joshi as the sole inventor. The
Board found that the evidence relied on in the ex parte appeal proceeding is
sufficient to establish that the subject matter relied in Chapters 8 and 13 of
3-DNS was publically available prior to the May 6, 2004, filing date of the
’301 patent. ’244 Appeal Dec. 24-26. The Board then affirmed a rejection
Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

37

of claims 1, 2, 9, 15, 24, and 28 of the ’301 patent for anticipation by 3-
DNS. ’244 Appeal Dec. 43. These claims accordingly were canceled by Ex
Parte Reexamination Certificate 7,584,301 C1, which issued on April 25,
2014.
Of the claims rejected for anticipation by 3-DNS in this inter partes
proceeding, claims 1, 12, 13, 15, 17, and 18 have been canceled by Ex Parte
Reexamination Certificate 7,756,965 C1 and we summarily have sustained
the rejection of claims 2-5, 8, 10, 11, 19, 21, and 23 for anticipation by
ServerIron. This leaves only claims 7 and 16 for our consideration.
Patent Owner’s discussion of this ground of rejection treats claims 7
and 16 standing or falling with their respective independent claims (viz.,
claims 1 and 12): “Appellant respectfully requests the rejection of claim 1
be withdrawn. Further 3-DNS also does not anticipate the other independent
claims 12 and 18, which recite substantially similar limitations. Further, by
virtue of being dependent on patentable base claims, all rejected dependent
claims should also be considered patentable over 3-DNS.” Br. 27.
Consequently, we will sustain the rejection of claims 7 and 16 if we find that
claim 1 is anticipated by 3-DNS.
3-DNS describes the features of the “3-DNS System®” (hereinafter
“3-DNS system”). 3-DNS 1-1 (i.e., Chapter 1, page 1, “Getting Started”).
The proposed rejection of claim 1 (Request 10-13), which relies on Chapter
Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

38

13, has been adopted by the Examiner. RAN 3. Before addressing Chapter
13, we will briefly review Chapter 8 (“Load Balancing”) for background.
When a name resolution request is received from a local DNS server,
the 3-DNS system uses a load balancing mode to select the best available
virtual server from a “wide IP pool” (i.e., a pool of a wide IP). Id. at 8-1.
“A wide IP is a mapping of a fully-qualified domain name (FQDN) to a set
of virtual servers that host the domain’s content, such as a web site, an e-
commerce site, or a CDN [content delivery network17].” Id. at 8-10. A wide
IP contains one or more pool definitions. Id. A pool is a group of virtual
servers that the 3-DNS load balances. Id.
The 3-DNS system uses load balancing in two different ways:
♦ Load balancing among multiple pools
The 3-DNS supports multiple pools. Configurations that
contain two or more pools use a load balancing mode first to
select a pool. Once the 3-DNS selects a pool, the system
then uses a load balancing mode to choose a virtual server
within the selected pool. . . .

♦ Load balancing within a pool
Within each pool, you specify three different load balancing
modes that the system uses in sequential order: preferred
method, alternate method, and fallback method. The
preferred method is the first load balancing mode that the 3-
DNS uses for load balancing. If the preferred method fails,
the system then uses the alternate method for load balancing.

17 3-DNS, Glossary 2.
Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

39

If this load balancing mode fails, the system uses the
fallback

load balancing mode. If the fallback method fails, the 3-
DNS returns the client to standard DNS for resolution.
Id. at 8-1.
Table 8.1 (id. at 8-2) of 3-DNS is reproduced below.18

18 We downloaded the 3-DNS tables and figures reproduced herein, which
have better clarity than the tables and figures in the record copy of 3-DNS,
from http://support.f5.com/content/kb/en-us/archived_products/3-dns/
manuals/product/3dns4_2ref/_jcr_content/pdfAttach/download/file.res/3-
DNS_Reference_Guide%2c_version_4.2.pdf.
Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

40

Table 8.1 shows a complete list of the supported load balancing modes and
indicates where each mode can be used in the 3-DNS system configuration.
Id. at 8-2. The first column (“Load Balancing mode”) lists sixteen balancing
modes available to the 3-DNS system, including “Topology.” These sixteen
load balancing modes are described at pages 8-3 to 8-5. The second column
(“Use for pool load balancing”) identifies “Topology” as one of five
balancing modes (the others are Global Availability, Random, Ratio, and
Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

41

Round Robin) that can be used for pool selection when the wide IP
comprises a plurality of pools. The remaining three columns identify the
balancing modes that can be used in the “preferred,” “alternate,” and
“fallback” methods to identify the appropriate server in the selected pool.
Chapter 8 explains that “topology records” can be used to provide
“proximity-based” (i.e., geographic) load balancing:
The Topology load balancing mode allows you to direct or
restrict traffic flow by adding topology records to a topology
statement in the configuration file. When you use the Topology
load balancing mode, you can develop proximity-based load
balancing. For example, a client request in a particular
geographic region can be directed to a data center or server
within that same region. The 3-DNS determines the proximity
of servers by comparing location information derived from the
DNS message to the topology records.
This load balancing mode requires you to do some advanced
configuration planning, such as gathering the information you
need to define the topology records. The 3-DNS contains an IP
classifier that accurately maps local DNS servers, so when you
create topology records, you can refer to continents and
countries, instead of IP subnets.
Id. at 8-5 (emphasis added).

1. Claim 1’s First Step (“Storing First Address Prefix Information
And Corresponding First Geographic Region Information”)
The mapping mentioned in the second paragraph of the above-quoted
passage from page 8-5 is performed by a database: “The crypto 3-DNS
Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

42

includes a database that maps IP addresses to geographic locations. With
this database, the system can use the geographic attributes of local DNS
servers (LDNS) to direct traffic.” 3 DNS 13-1 (emphasis added) (quoted in
Request 10, limitation 1.1).
The Request (at 10, limitation 1.1) describes the database as “stor[ing]
geographic information corresponding to address prefixes in a database” and
asserts that the database satisfies claim 1’s first step. Patent Owner does not
contend otherwise, instead merely acknowledging that “[t]he rejection first
cites to passages that disclose that the 3-DNS network device is endowed
with a database that maps IP addresses to geographic locations.” Br. 23.
We note that although claim 1’s first step does not require Patent
Owner’s asserted “deemed to reside” interpretation, the database satisfies
such an interpretation.

2. Claim 1’s Second Step (“Storing Second Address Prefix
Information And Corresponding Second Geographic Region
Information”)
The Request reads claim 1’s second step on 3-DNS’s topology
records, which are described as follows:
A topology record has three elements: an LDNS location
endpoint, a virtual server location endpoint, and a relative
weight. The location endpoints can be one of the following:
Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

43

• A[n] IP subnet (CIDR [Classless Interdomain Routing19]
definition)
• A wide IP pool (managed by the 3-DNS)
• A data center (managed by the 3-DNS)

• A country (based on the ISO 3166 top-level domain codes, as
specified by IANA, the Internet Assigned Numbers
Authority)
• A continent
• An Internet service provider (ISP) (for LDNS location
endpoints only)
• A user-defined region
The relative weight, or topology score, for the topology record
allows the 3-DNS to evaluate the best resolution option for a
DNS request. The not (!) operator, when used in a topology
record, indicates location endpoints not equal to the specified
value.
Request 10-11, limitation 1.1 (quoting 3-DNS 13-1) (underlining added by
Request).
Table 13.1 of 3-DNS is reproduced below,

19 ServerIron 2-6.
Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

44

Table 13.1, as stated in the caption, describes the variables used in a
topology statement. This table restricts the “pool” and “datacenter”
variables to servers and restricts the “continent,” “country,” and “isp”
variables to LDNS’s. This table also lists and describes a “user” variable
(for a user-defined region, discussed below) without placing any restriction
on its use.
Figure 13.1 is reproduced below.
Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

45

Figure 13.1 is an example of a topology statement having two topology
records, as it appears in the configuration utility. Id. at 13-1. A wide IP
pool named “origin” manages the virtual servers that are returned for DNS
requests sent by local DNS servers located in North America. Id. at 13-2. A
wide IP pool named “cache_farm” manages the virtual servers that are
returned for DNS requests sent by local DNS servers located anywhere
except North America. Id. Thus, each of these topology records describes a
source-to-destination type of association, i.e., association of (i) a destination
location endpoint in the form of a wide IP pool with (ii) an LDNS location
endpoint in the form of a geographic region (i.e., a continent).
Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

46

The Request does not read claim 1’s second step on either of the
topology records shown in Figure 13.1. Instead, the Request reads this step
on a topology record that includes a user-defined geographic region as one
of the two location endpoints. See Request 11, limitation 1.2 (“3-DNS Ref
Guide discloses that the 3-DNS also uses topology records to associate
address prefixes with user-defined geographic regions.”).
A “user-defined region,” which is the last of the different types of
location endpoints listed at page 13-1, is described by 3-DNS as follows:
To further refine the topology load balancing capabilities of the
3-DNS, you can create custom topology regions. By adding
user-defined regions to the topology statement, the 3-DNS can
route traffic (client requests) to the best data center or wide IP
based on the characteristics of your specific network.
You create a custom region by adding one or more region
member types to the region member list. The region member
types are: Continent, Country, Data Center, IP Subnet, ISP,
User-Defined Region, and Wide IP Pool. . . .
Id. at 13-5 (italics added).
Figure 13.4, which appears page 13-6 and is reproduced at Request
page 12, limitation 1.3, is reproduced below.
Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

47

Figure 13.4, as indicated in its caption, shows the syntax for user-defined
regions. The Request (at page 12, limitation 1.3) describes Figure 13.4 as
“disclos[ing] a user-defined region named ‘US_no_AOL_or_STUFF’” and
reads the claimed “second geographic region information” on this user-
defined geographic region.
The Request more particularly reads claim 1’s second step on a
topology record that is used to associate an IP Subnet with a user-defined
geographic region. See Request 12, limitation 1.2 (“[A] topology record
may associate an IP subnet (a claimed ‘second address prefix’) with a user-
defined [geographic] region (a claimed ‘second geographic region’).”).
Requester more particularly explains that such a topology record causes a
client request that originates in the IP Subnet to be routed to a host (i.e.,
server) in the user-defined geographic region:
When an address matches the prefix stored in a topology
statement, it will be associated with the region stored in that
same statement. See, e.g., 3-DNS Ref. Guide at 13-1 to 13-2.
This association is formed so that load balancing may be
achieved by sending client requests to hosts that are
geographically nearby. Id. at 8-5. Thus, 3-DNS Ref. Guide
Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

48

unmistakably discloses “associating” an address that matches
the prefix in a topology statement with a “second geographic
region,” as claimed.
Req. ACP Comments 20 (emphasis added). We therefore understand
Requester’s position to be that 3-DNS describes a topology record that can
have an IP Subnet as its LDNS location endpoint and a user-defined
geographic region as its virtual server endpoint.
Patent Owner does not agree that 3-DNS describes such a topology
record. According to Patent Owner, 3-DNS describes using a “custom”
region, which can take the form of an IP Subnet or a user-defined region,
only as a LDNS location endpoint:
The above passage [at 3-DNS page 13-5, describing user-
defined regions] explains that an administrator can create a
custom region so that any requests coming from an LDNS
within that custom region will be directed to a specified group
of virtual servers. The fact that a custom region can be defined
by an actual [i.e., geographic] region, or by an IP Subnet does
not store [sic; does not mean that a topology record can store?]
an IP address prefix and corresponding geographic region
information. Rather, a made[-]up region can be a collection of
IP Subnets, where the devices using that IP Subnet could be
anywhere. The IP Subnet is the region. Thus the above
passages are not disclosing that the IP Subnet is stored along
with its corresponding second geographic region information.
Once the new “region” has been defined - say by defining the
region as IP Subnet, a topology record can be created that will
Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

49

direct any request from and LDNS having that IP Subnet to a
specified virtual server. 3-DNS at pp. 13-2, 13-5.
Br. 25 (emphasis added; footnote omitted).
We do not agree that 3-DNS describes using a user-defined region
only as an LDNS location endpoint. Although the page 13-5 passage quoted
above and relied on by Patent Owner describes using a user-defined
geographic region as an LDNS location endpoint, we find that this passage
would have been understood to be describing a non-limiting example of how
to use a user-defined geographic region. User-defined regions are not
restricted to LDNS location endpoints in the description of user-defined
regions at page 13-1 or in the description of topology variables in Table 13.1
(at page 13-7). In contrast, page 13-1 and Table 13.1 restrict continents or
countries to LDNS location endpoints and restrict wide IP pools and
datacenters to server location endpoints. We also note that IP Subnets,
which--like user-defined regions--are not restricted to use as one or the other
of LDNS location endpoints and server location endpoints, are depicted as
selectable for use in either manner in the “Add Topology Records” box in
Figure 13.1.

Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

50

3. Claim 1’s Third Step (“For Network Addresses That Have First
Address Prefix Information That Matches The Second Address
Prefix Information, Associating These Network Addresses To The
Second Geographic Region Information, Which Is Different From
Said Corresponding First Geographic Region Information”).
The Request reads claim 1’s third step on 3-DNS as follows:
The above figure [13.4] discloses a user-defined region named
“US_no_AOL_or_STUFF.” In this example, the “second
prefix” corresponds to the set of prefixes that match the “North
America” prefix but do not also match the [second] prefixes for
“Mexico,” “Canada,” or the internet service provider AOL.
Any [network] address with a prefix that matches this “second
prefix” will be associated with this user-defined region (claimed
“second geographic region”) instead of its original region,
“North America” (the claimed “first geographic region”).

Request 12, limitation 1.3, 3d para.
We understand the above-quoted passage to mean that 3-DNS
describes a client network address that:
(a) can match (i.e., satisfy) “first address prefix information” that is
stored in the database as corresponding (in a “deemed to reside” sense) to
the “first geographic region” of “North America”; and
(b) also can match (i.e., satisfy) “second address prefix information”
of an IP Subnet identified in a topology record as corresponding (in a
source-to-destination sense) with the user-defined “second geographic
region” of “US no AOL or STUFF” (which includes North America while
excluding Mexico and Canada).
Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

51

Patent Owner makes two arguments regarding claim 1’s third step.
The first argument, reproduced below, essentially repeats Patent Owner’s
above-discussed, unpersuasive argument that 3-DNS does not describe using
a topology record to associate an IP Subnet with a user-defined geographic
region:
As explained above, 3-DNS uses its topology statement
to establish a relationship of a region to a specific virtual
server(s). However, such a configuration does not anticipate the
independent claims because establishing a relationship between
a region and a virtual server is not the same as associating an
address prefix with second geographic region information.
A virtual server(s) is not the same as the claimed
geographic region information. While a virtual server(s) must
inherently be located in some location, associating the IP
address prefix with a virtual server(s) is not the same as
associating it with a geographic location. Many virtual servers
could be present in one location, but they can be moved to
another location. Association with a virtual server(s) cannot be
considered the same as association with geographic region
information.
Br. 26, sec. i (emphasis added).
Patent Owner’s second argument, reproduced below, is unpersuasive
because it incorrectly assumes that claim 1’s third step must be given an
“override” interpretation:
[T]he proper interpretation of the claims requires
overriding a first geographic region associated with a first
network prefix with a second geographic region that is the
region a device having the address prefix is perceived to be
Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

52

originating from or reside at. The topology statement does not
override the region a device having the address prefix is
perceived to be originating from or reside at. Rather it merely
directs a request for a network resource to a particular virtual
server according to the location of the LDNS which is referring
the request.
Id. at 26, sec. ii (emphasis added).
For the above reasons, we are not persuaded of any error in the
Examiner’s conclusion that claim 1 (now canceled) is anticipated by 3-DNS.
We accordingly sustain the rejection of claims 7 and 16, which Patent
Owner treats as standing or falling with the rejection of claim 1 on this
ground.

F. The Rejection for Anticipation by Skene (Claims 1-5, 7-13, 15-21,
and 23, of Which Claims 1, 12, 13, 15, 17, and 18 Have Been Canceled)
Of the claims rejected for anticipation by Skene, claims 1, 12, 13, 15,
17, and 18 have been canceled by the Ex Parte Reexamination Certificate
and we summarily have sustained the rejection of claims 2-5, 7, 8, 10, 11,
19-21, and 23 for anticipation by ServerIron. Therefore, we will not address
the rejection of any of these claims for anticipation by Skene, which leaves
the rejection of only dependent claims 7, 9, and 16 for our consideration.
Patent Owner’s discussion of the rejection for anticipation by Skene
specifically discusses only claim 1 and thus effectively treats the rejection of
Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

53

claims 7, 9, and 16 as standing or falling with the rejection of claim 1.
Br. 27-29. Consequently, we will sustain the rejection of claims 7, 9, and 16
if we find that claim 1 (discussed at Request pages 55-59) is anticipated by
Skene.
Skene’s invention “relates generally to distributing the load demand
between servers on a network, and, more specifically, to bridging content
delivery across multiple CDNs [content delivery networks20].” Skene
1:17-19.
Geographic criteria metric information is collected and stored for use
in segmenting IP addresses into physical locations. Id. at 1:51-53. For
example, local DNS (Domain Name System21) servers can be classified to
the continent or country level, such as by segmenting North American traffic
and non-North American traffic. Id. at 1:53-56.
Figure 1 is reproduced below.

20 Skene 3:56-57.
21 Skene 4:7.
Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

54

Figure 1 illustrates an overview 100A of an embodiment of a WAN (Wide
Area Network22) architecture in which Skene’s invention has been added to
a network that includes a Primary DNS server for resolving IP address
associated with a domain name request. Id. at 6:16-19. At least one separate

22 Skene 3:28.
Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

55

Primary EDNS (Extended Domain Name System23) server may be used as
the authoritative source for a sub-domain name. Id. at 6:19-21.
The EDNS server identifies the proximity of the resolution request
and directs the request to the closest identified geographic CONTENT-
SERVER, the best quality path, or the best performing CONTENT-
SERVER. Id. at 19:31-34. According to one embodiment, “best guess”
predefined topological maps are generated based on comparing local DNS
server addresses against public resources such as ASN, network, DNS
registration tables, and “last hops.” Id. at 19:40-44. As explained below, the
rejection reads the recited “second geographic region” on the location of the
IP address of the “last hop.”24
Skene’s Figure 16 (discussed at Request page 55) is reproduced
below.

23 Skene 4:11.
24 Skene describes “hops” as follows:
Hops--An intermediate connection in a string of
connections linking two network devices. On the Internet, for
example, most data packets go through several intermediate
systems (routers, Host machines, switches, or layer 3 network
device) before they reach their final destination. A hop is
defined as a stop at an intermediate system (IS) for evaluation
and then forwarded on to the next IS known to the current IS.
Skene 5:60-66.

Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

56

Figure 16 shows a diagram of an internal repository to store metric
information. Id. at 19:47-48. The reference information stored in the
internal repository is bound together to determine “[in] what location an IP
address resides.” Id. at 19:51-53. For example, the location may be a
country, city, postal code, and the like. Id. at 19:53-54.
Specifically, Internet Database of Figure 16 stores and collects metric
information, including, but not limited to: “last hop” proximity data; location
information for whomever registered an internet address (“whois”
Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

57

information); IANA data (asn.txt and networks.txt); and Wide IP data. Id. at
19:64-20:1.
The data are extracted from the database to create “region definitions”
for Internet addresses. Id. at 20:3-4. “[T]he region definitions may be
exported into a table mapping IP subnets to geographic and other region
attributes, such as in TABLE 6.” Id. at 20:7-9 (emphasis added). Skene’s
Table 6, which appears at Request page 56, is reproduced below.

Skene col. 20. As already noted, Table 6 is described as “mapping IP
subnets to geographic and other region attributes.” Id. at 20:7-10. For
example, the second entry in this table maps IP Subnet 22.0.0.0/8 to the
continent of “North America,” the country of “US,” and the state of
“Arizona.” Thus, we find that the region definitions set forth in Table 6
provide an association (i.e., in a “deemed to reside” sense that is not required
by claim 1) between IP Subnets and geographic regions. The “mapping”
provided by the region definitions therefore differs from Skene’s “topology
mapping,” described below, which provides associations of the source-to-
destination type.
Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

58

The Request explains that another example of a region definition is
shown in Table 7:
According to one embodiment of the present invention, a region
definition is created that attempts to “best” define the state of
the database in clear-cut regions. Regions consist of a name,
geographic attributes, and CIDR definitions that make up the IP
addresses that could reside in that location. Regions may also
contain regions to form a hierarchy of regions. For example,
TABLE 7 shows an exemplary region definition.
Request 56, limitation 1.1 (quoting Skene 20:45-51).
Table 7, which appears at Request page 57, is reproduced below.

Id. at 20:53-63. As already noted, Table 7 shows an exemplary region
definition. Id. at 20:51. The name of the region described in Table 7 is
identified therein as “Japan.”
As noted above, Skene also describes “topology mapping,” which
provides associations of the source-to-destination type. Specifically, Skene
explains that “[a] topology mapping is created between Wide IP pools and
regions, continents, countries, or IP subnets, such that traffic can be guided
Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

59

to that region when a requesting IP address is identified.” Skene 20:64-67
(quoted in Request 57, limitation 1.1).
Skene’s Table 8, which provides an example of topology mapping, is
reproduced below.

Id. at col. 21. Table 8 illustrates an exemplary Wide IP configuration for
“directing traffic based on geographic proximity.” Id. at 21:1-2. This
example includes wide IP pools named “New York,” “Los Angeles,” and
Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

60

“Tokyo.” The fifth line of this table reads “pool_lbmode topology,” which
means that topology is used to select the appropriate pool from the plurality
of pools. The last eight lines of Table 8 recite the relationships used to
implement “topology” load balancing in this example. For example, the
fourth of these eight lines shows that a request whose source is the region of
“Japan” will be directed to a wide IP pool named “Tokyo.” Thus, a request
originating in the region of “Japan” will be associated (in a source-to-
destination sense) with wide IP pool named “Tokyo.”25
The rejection is the based on following example in Skene (hereinafter
referred to as the “exodus.com example”):
Determining the location for an IP address may be
problematic for any address that resolves back to a “.com” or
“.net” domain name. For example, exodus.com would always
come up as located in Santa Clara, Calif. when it is known that
the service provider exodus.com deploys worldwide.
Therefore, according to one embodiment, the “last hop” IP
address is used to determine geographic proximity.
Skene 19:55-61 (emphasis added). As noted in the D’Andrade Declaration
(at paragraph 20), this embodiment is the subject of Skene’s claim 7, which
reads as follows:
7. The method of claim 1, further comprising:

25 In the Table 8 example, each of the wide IP pools use preferred, alternate,
and fallback modes other than “topology” to identify the appropriate server
in the selected pool of servers.
Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

61

using a last hop address to determine a geographic
location of the request; and
distributing the request based on the geographic location.
Skene col. 29 (emphasis added).
The Request at pages 55-57, limitation 1.1 reads claim 1’s first step
(“storing first address prefix information and corresponding first geographic
region information”) on region definitions of the type set forth in Tables 6
and 7. See, e.g., id. at 56 (“Skene . . . discloses that the Primary EDNS
stores IP subnets (claimed ‘address prefixes’) corresponding to geographic
information.”). More particularly, the Request when discussing claim 1’s
third step reads the “first address prefix information and corresponding first
geographic region information” on the exodus.com example as follows:
“Skene discloses the network address “exodus.com” (the claimed “first
address prefix”) is associated with a first geographic region, “‘Santa Clara,
Calif.’” Id. at 59, limitation 1.3. We note that Santa Clara and the address
prefix for the exodus.com address are associated in a “deemed to reside”
sense (not required by the claim language).
Patent Owner argues:
Skene does not teach first geographic region information that
corresponds to first address prefix information, since Santa
Clara, CA is a business mailing address of the registrant
exodus.com rather than a location where a device having the
first address prefix is deemed to reside ([D’Andrade Decl.]
paragraph 27).
Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

62

PO Non-Final Action Resp. 28-29. The cited testimony reads in relevant
part as follows:
30. . . . The association of exodus.com and Santa Clara,
Calif. is based on a whois search of exodus.com, which shows
that the exodus.com has a business address in Santa Clara,
Calif. and the results of this whois search [are] provided in the
“Internic Whois – Owners” records in the data repository in
Figure 16 of the Skene patent. The whois registrant mailing
address (Santa Clara, Calif. in the Skene patent example) is not
a first geographic region as disclosed within the scope of the
‘965 patent, because a whois search does not provide the
geographic location where a device using a particular IP
address is deemed to be residing.
D’Andrade Decl. para. 30 (emphasis added; footnote omitted).
This testimony and the argument based thereon are unpersuasive
because the claim language does not require a “deemed to reside”
interpretation. In any case, the “whois” address satisfies claim 1’s first step
even if given a “deemed to reside” interpretation, which does not require that
the “corresponding geographic location information” be accurate.
The Request reads claim 1’s second step (“storing second address
prefix information and corresponding second geographic region
information”) on Skene’s exodus.com example in two different ways. First,
when describing claim 1’s second step, the Request reads the recited
“second address prefix information” on the address prefix of the “last hop”
IP address and reads the recited “second geographic region information” on
the geographic location for the “last hop” IP address. See Request 57,
Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

63

limitation 1.2 (“The address prefix of the IP address of the “last hop” and the
corresponding geographic location correspond to the claimed “second
address prefix information and corresponding second geographic region
information.”). We note that the prefix of the “last hop” IP address and the
geographic location for the “last hop” IP address have a “deemed to reside”
type of association (not required by the claim language).
However, the Request reads the limitations of claim 1’s second step
on the exodus.com example in a different way when discussing claim 1’s
third step (“for network addresses that have first address prefix information
that matches the second address prefix information, associating these
network addresses to the second geographic region information, which is
different from said corresponding first geographic region information”).
That is, although the Request continues to read the recited “second
geographic region information” on the geographic location for the “last hop”
IP address, the Request reads the “second address prefix information” on the
address prefix of the exodus.com address rather than continuing to read it on
the address prefix of the “last hop” IP address, with the result that both the
“first address prefix information” and the “second address prefix
information” are being read on the address prefix of the exodus.com address.
Specifically, the Request states:
Skene . . . discloses that the topology mapping may be based on
a region that is defined by “last hop” proximity (a claimed
“second geographic region”). For example, Skene discloses the
Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

64

network address “exodus.com” (the claimed “first address
prefix”) is associated with a first geographic region, “Santa
Clara, Calif.” and the same network address “exodus.com” (the
claimed “second address prefix”) is associated with a second
geographic region that is determined by “last hop” IP address.
Request 59, limitation 1.3 (emphasis added).
In response to the Non-Final Action (which at page 3, Issue #3 adopts
the reasoning set forth in the Request), Patent Owner pointed out the above-
noted inconsistency in how the Request proposes to read the “second address
prefix” on Skene and argued (in arguments addressed infra) that the “second
address prefix” cannot be read on Skene in either of the two ways proposed
in the Request. PO Non-Final Action Resp. 28-29.
Requester responded by clarifying that the “second address prefix”
(like the “first address prefix”) is being read on the address prefix of the
exodus.com address:
The above passage [in Skene, describing the exodus.com
example] describes using a “last hop” address to determine
geographic proximity for addresses associated with the prefix
“exodus.com.” Specifically, the “exodus.com” prefix, which
originally corresponded to Santa Clara, Calif. (i.e., the “first
geographic region information”), is later associated with a “last
hop” region (i.e., the “second geographic region information”),
which is different from Santa Clara, Calif. Thus, addresses
with a prefix matching the “exodus.com” prefix (i.e., the
“second address prefix”) are associated with the second,
different, “last hop” region.
Req. Non-Final Action Comments 22 (emphasis added).
Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

65

The Examiner has not commented on this clarification of Requester’s
position. Therefore, we will address the merits of both of Requester’s
proposed ways of reading the “second address prefix information” on Skene.

1. The Merits of Reading the “Second Address Prefix Information”
on the “Last Hop” IP Address
Patent Owner makes the following two arguments against reading the
claimed “second address prefix information” on the address prefix of the
“last hop” IP address:
[(1)] Skene does not teach that the address prefix information of
the last hop necessarily matches a stored address prefix
information of exodus.com ([D’Andrade Decl.] paragraph 25);
[and] [(2)] Skene does not teach that the geographic region
information for the last hop is necessarily different from the
geographic region information of exodus.com ([id. at]
paragraph 26); . . . .
PO Non-Final Action Resp. 28-29.
We begin with argument (2). The cited testimony, reproduced below,
presumes a “last hop” address of 173.252.220.138, allegedly located in
Santa Clara:
26. . . . A person of ordinary skill in the art would know that
a last hop (173.252.220.138) is located in Santa Clara, Calif.
based on geolocation tools, which is also the same as the
asserted first geographic region information of exodus.com;
hence, a last hop geographic region information (e.g., Santa
Clara, Calif.) is not necessarily different from the geographic
region information (e.g., Santa Clara, Calif.) associated with
Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

66

exodus.com. In my opinion, the Skene patent therefore does
not disclose second geographic region information that is
necessarily different from first geographic region information at
column 19, lines 55-63.
D’Andrade Decl. para. 26 (emphasis added; footnote omitted).
Argument (2) is unpersuasive because Skene’s exodus.com example is
specifically based on a “last hop” IP address that is located in a geographic
region other than Santa Clara, as noted by Requester. See Req. Non-Final
Action Comments 24 (“Skene makes clear that the entire reason for using a
‘last hop’ region is so that Santa Clara, Calif. is not associated with
‘exodus.com.’”). It is immaterial that another “last hop” address may be
located in Santa Clara.
This brings us to argument (1), i.e., that “Skene does not teach that the
address prefix information of the last hop necessarily matches a stored
address prefix information of exodus.com.” (Emphasis added.) This
argument is directed to the following language in claim 1’s third step: “for
network addresses that have first address prefix information that matches the
second address prefix information, associating these network addresses to
the second geographic region information . . . .” The testimony cited as
support reads in relevant parts as follows:
25. . . . [I]f the stored address prefix for exodus.com is
208.45.180.0/25 and a last hop network address [located in
Santa Clara] is 173.252.220.138, a person of ordinary skill in
the art would understand that the last hop IP network address
prefix will not be matched to the stored address prefix for
Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

67

exodus.com, since the address prefixes are numerically
dissimilar (208.45.180.0 versus 173.252.220.138). In my
opinion, the Skene patent therefore does not disclose that first
address prefix information (based on exodus.com) of network
addresses is necessarily matched to second address prefix
information (based on last hop IP address) as required by claim
1 of the ‘965 patent.
D’Andrade Decl. para. 25 (footnotes omitted).
Argument (1) is unpersuasive to the extent it is based on a “last hop”
address that is located in Santa Clara rather than in a different geographic
region. As explained above, the exodus.com example presumes a “last hop”
address in a geographic region different from Santa Clara. However,
argument (1) is persuasive to the extent it faults the Request for failing to
establish that the address prefix of the exodus.com address will “match” the
address prefix of a “last hop” IP address that is located in geographic region
different from Santa Clara, as is necessary to satisfy claim 1’s third step if
the “second address prefix information” is to be read on the address prefix of
the “last hop” IP address.
We therefore agree with Patent Owner that the recited “second
address prefix information” cannot be read on the address prefix of the “last
hop” IP address in Skene’s exodus.com example.

Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

68

2. The Merits of Reading the “Second Address Prefix” on the
Address Prefix for the Exodus.com Address
As noted above, Requester reads claim 1’s second step on the
exodus.com example as follows:
[T]he “exodus.com” prefix, which originally corresponded to
Santa Clara, Calif. (i.e., the “first geographic region
information”), is later associated with a “last hop” region (i.e.,
the “second geographic region information”), which is different
from Santa Clara, Calif. Thus, addresses with a prefix matching
the “exodus.com” prefix (i.e., the “second address prefix”) are
associated with the second, different, “last hop” region.
Req. Non-Final Action Comments 22.
Patent Owner argues that it is improper to read the “second address
prefix” on the exodus.com address prefix because “Skene does not teach that
geographic region information for the last hop is necessarily different from
the geographic region information of exodus.com ([D’Andrade Decl.]
paragraph 29).” PO Non-Final Action Resp. 29. This argument is identical
to the above-discussed argument (2), which, as explained above, is
unpersuasive because the exodus.com example is specifically based on a
“last hop” IP address whose address prefix has a geographic location
different from Santa Clara.
In the same paper, Patent Owner also argued:
Pages 34-35 [sic, 57-59] of the Request cite[] the above
quoted passage from Skene’s col. 20, lines 64-67 [describing
topology mapping] and Table 8 [sic, Tables 6 and 7] and the
accompanying description. However and once again, these
Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

69

passages merely describe the manner in which traffic is
directed to a particular virtual server according to geographic
proximity (source-to-destination). These passages are silent
with respect to second geographic region information that is
different from first geographic region information that
corresponded to matching address prefixes.
PO Non-Final Action Resp. 27. This argument is unpersuasive because it
improperly assumes that claim 1’s first and second steps must be given a
“deemed to reside” claim interpretation.
The Brief presents two arguments against anticipation by Skene’s
exodus.com example, of which the first argument is:
Skene explains that it is sometimes not possible to determine
[the] geographic region in which an IP address resides. Skene
at col. 19, lines 55-63 (“Determining the location for an IP
address may be problematic for any address that resolves back
to a ‘.com’ or ‘.net’ domain name”). Rather than solve this
problem as in the invention recited in claim 1 of [the] ‘965
patent, Skene ignores the IP address of the origination of the
request and instead focuses on the IP address of the last hop.
Skene at col. 19, lines 55-63 (“Therefore, according to one
embodiment, the “last hop” IP address is used to determine
geographic proximity.”).
Br. 28-29 (emphasis added). To the extent Patent Owner is suggesting that
the exodus.com example fails to associate the IP address of the origination
of the request with the geographic region of the “last hop” IP address, we do
not agree. The effect of the exodus.com example is to associate the request
Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

70

(which presumably includes the IP address of the origination of the request)
with the geographic location of the “last hop” IP address.
Patent Owner’s second argument is stated as follows:
Having determined a geographic region associated with a
request for a network resource, Skene uses a topology mapping
(same as that discussed with respect to 3-DNS) to select a
server to respond to the request for the network resource.
Skene at col. 20, lines 64-67 (“A topology mapping is created
between Wide IP pools and regions, continents, countries, or IP
subnets, such that traffic can be guided to that region when a
requesting IP address is identified.”). Thus, Skene discloses a
system whereby a source of a request for content is being used
to determine which destination server to use to fulfill the
request. Skene never discloses associating a network addresses
prefix to second geographic region information that is different
than the first geographic region information. A first address
prefix is never associated with second and different geographic
region information.
Br. 28-29 (emphasis added). This argument is unpersuasive because it
appears to be based on Patent Owner’s unduly narrow “deemed to reside”
claim interpretation.
For the foregoing reasons, Patent Owner has not persuaded us of error
in the Examiner’s determination that (canceled) claim 1 is anticipated by
Skene. We therefore sustain the rejection on this ground of dependent
claims 7, 9, and 16, which Patent Owner treats as standing or falling with
claim 1.

Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

71

III. SUMMARY
1. The appeal is dismissed with respect to claims 1, 12, 13, 15, 17,
and 18 due to their cancelation by Ex Parte Reexamination Certificate
US 7,756,965 C1, which issued on May 9, 2014.
2. The rejection of dependent claims 2-5, 8, 10, 11, 19-21, and 23
under 35 U.S.C. § 102 for anticipation by ServerIron is not separately argued
and therefore summarily is sustained, making it unnecessary to address the
merits of the other grounds of rejection of these claims.
3. Regarding the rejection of claims 2, 3, 6, 19, and 20 under
35 U.S.C. § 103(a) for obviousness over ServerIron in view of AAPA, we
(i) found it unnecessary to address the merits of the rejection of claims 2, 3,
19, and 20 and (ii) sustain the rejection of claim 6.
4. Regarding the rejection of claims 2-5, 7, 8, 10, 11, 16, 19, 21 and
23 under 35 U.S.C. § 102 for anticipation by 3-DNS, we (i) found it
unnecessary to address the merits of the rejection of claim 2-5, 8, 10, 11, 19,
21, and 23 and (ii) sustain the rejection of claims 7 and 16.
5. Regarding the rejection of claims 2-5, 7-11, 16, 19-21, and 23
under 35 U.S.C. § 102 for anticipation by Skene, we (i) found it unnecessary
to address the rejection of claims 2-5, 8, 10, 11, 19-21, and 23 and (ii)
sustain the rejection of claims 7, 9, and 16.
Appeal 2014-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

72

6. Thus, the Examiner’s decision that claims 2-11, 16, 19-21, and 23
are unpatentable over the prior art is sustained.
IV. DECISION
1. The appeal is dismissed with respect to claims 1, 12, 13, 15, 17,
and 18.
2. The Examiner’s decision that claims 2-11, 16, 19-21, and 23 are
unpatentable over the prior art is affirmed.
3. 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-006854
Reexamination Control 95/001,827
Patent 7,756,965 B2

73

For Patent Owner:

SAN FRANCISCO OFFICE OF
NOVAK DRUCE CONNOLLY BOVE + QUIGG LLP
1000 LOUISIANA STREET
FIFTY-THIRD FLOOR
HOUSTON TX 77002

For Third Party Requester:

TIMOTHY J. MAY
FINNEGAN, HENDERSON, FARABOW GARRETT & DUNNER, LLP
901 NEW YORK AVENUE, NW
WASHINGTON, DC 20001-4413

cu