VIRNETX INC. (OWNER) et al.

Patent Trials and Appeals Board

May 14, 2021

2021001315 (P.T.A.B. May. 14, 2021)

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,682 07/11/2011 6,502,135 077580-0132 1074
137313 7590 05/14/2021
PAUL HASTINGS LLP
2050 M. Street NW
Washington, DC 20036
EXAMINER
PEIKARI, BEHZAD
ART UNIT PAPER NUMBER
3992
MAIL DATE DELIVERY MODE
05/14/2021 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

APPLE INC.
Requester

v.

Patent of VIRNETX INC.
Patent Owner and Appellant

Appeal 2021-001315
Reexamination Control 95/001,682
Patent 6,502,135 B1
Technology Center 3900

Before KARL D. EASTHOM, JEFFREY B. ROBERTSON, and
JEREMY J. CURCURI, Administrative Patent Judges.
ROBERTSON, Administrative Patent Judge.
DECISION ON APPEAL

Appeal 2021-001315
Reexamination Control 95/001,682
Patent 6,502,135 B1

2
I. STATEMENT OF THE CASE
VirnetX Inc. (“Patent Owner”) appeals under 35 U.S.C. §§ 134(b) and
315(a) (Pre-AIA) from the Examiner’s decision to reject claims 10–18.1
Third-Party Requester Apple Inc. (hereinafter “Requester”) urges that the
Examiner’s decision must be affirmed.2 We have jurisdiction under 35
U.S.C. §§ 134(b) and 315(a) (Pre-AIA).
We affirm in part.

II. INTRODUCTION
A. Background and Summary
United States Patent 6,502,135 B1 (hereinafter the “’135 Patent”),
which is the subject of the current inter partes reexamination, issued to
Munger et al. on December 31, 2002. Inter partes reexamination was
requested by Apple. Inc. (“REQUEST FOR INTER PARTES
REEXAMINATION” filed on July 10, 2011, “Request”). Both Patent
Owner and Requester identify numerous related appeals and proceedings.
See Appeal Br. iv–vii; Resp’t Br. iv, 1–2.
In particular, the Federal Circuit, in VirnetX v. Mangrove Partners
Master Fund, Ltd., 778 F. App’x 897 (Fed. Cir. 2019), vacated and
remanded a PTAB Final Written Decision in IPR2015-01046, an inter partes
review of the ’135 Patent. Subsequently, the panel in that case issued a

1 See Patent Owner’s Appeal Brief filed February 6, 2020 (hereinafter
“Appeal Br.”); Examiner’s Answer (mailed August 25, 2020) (hereinafter
“Ans.”); Right of Appeal Notice (mailed November 6, 2019) (hereinafter
“RAN”); Patent Owner’s Rebuttal Brief filed September 24, 2020
(hereinafter “Reb. Br.”).
2 See Respondent Brief (filed April 17, 2020) (hereinafter “Resp’t Br.”).
Appeal 2021-001315
Reexamination Control 95/001,682
Patent 6,502,135 B1

3
Final Written Decision on Remand Determining All Challenged Claims
Unpatentable (claims 1, 3, 4, 7, 8, 10, 12). Mangrove Partners Master
Fund, LTD v. VirnetX, IPR2015-01046, Paper No. 112 (PTAB July 14,
2020).
In addition, the ’135 Patent is the subject of inter partes
reexamination control no. 95/001,679 requested by Cisco Systems, Inc., and
in which a Decision on Appeal (Appeal No. 2017-011862) was entered on
February 6, 2018, which affirmed the Examiner’s rejections of claims 1–9
and 13–18.3
B. The ’135 Patent
The ’135 Patent describes a system and method for communicating
over the Internet and the automatic creation of a virtual private network
(VPN) in response to a domain-name server look-up function. See ’135
Patent, col. 2, l. 66 – col. 3, l. 2, col. 37, ll. 19–21.
Claims 10, 13, and 18, the independent claims on appeal, are
illustrative of the appealed subject matter, and read as follows:
10. A system that transparently creates a virtual private
network (VPN) between a client computer and a secure target
computer, comprising:

3 Rehearing was requested by Patent Owner, and denied in a Decision
mailed January 18, 2019. The Board’s decisions were appealed to the
Federal Circuit. A General Order by the Chief Administrative Patent Judge
entered on May 5, 2020 in the 95/001,679 reexamination indicated that the
Federal Circuit had issued orders vacating a number of decisions by the
PTAB including the Board’s Decision in 95/001,679 in view of Arthrex, Inc.
v. Smith & Nephew, Inc., 941 F.3d 1320 (Fed. Cir. 2019)(cert. granted sub
nom. United States v. Arthrex, Inc., 2020 WL 6037206 (Oct. 13, 2020)).
The General Order ordered 95/001,679 be held in abeyance until the
Supreme Court ultimately resolves the issues raised in Arthrex.
Appeal 2021-001315
Reexamination Control 95/001,682
Patent 6,502,135 B1

4
a DNS proxy server that receives a request from the
client computer to look up an IP address for a domain name,
wherein the DNS proxy server returns the IP address for the
requested domain name if it is determined that access to a non-
secure web site has been requested, and wherein the DNS proxy
server generates a request to create the VPN between the client
computer and the secure target computer if it is determined that
access to a secure web site has been requested; and
a gatekeeper computer that allocates resources for the
VPN between the client computer and the secure web computer
in response to the request by the DNS proxy server.

13. A method of establishing communication between
one of a plurality of client computers and a central computer
that maintains a plurality of authentication tables each
corresponding to one of the client computers, the method
comprising the steps of:
(1) in the central computer, receiving from one of the
plurality of client computers a request to establish a connection;
(2) authenticating, with reference to one of the plurality
of authentication tables, that the request received in step (1) is
from an authorized client;
(3) responsive to a determination that the request is from
an authorized client, allocating resources to establish a virtual
private link between the client and a second computer; and
(4) communicating between the authorized client and the
second computer using the virtual private link.

18. A method of transparently creating a virtual private
network (VPN) between a client computer and a target
computer, comprising the steps of:
(1) generating from the client computer a Domain Name
Service (DNS) request that requests an IP address
corresponding to a domain name associated with the target
computer;
Appeal 2021-001315
Reexamination Control 95/001,682
Patent 6,502,135 B1

5
(2) determining whether the DNS request transmitted in
step (1) is requesting access to a secure web site; and
(3) in response to determining that the DNS request in
step (2) is requesting access to a secure target web site,
automatically initiating the VPN between the client computer
and the target computer, wherein:
steps (2) and (3) are performed at a DNS server separate
from the client computer, and step (3) comprises the step of,
prior to automatically initiating the VPN between the client
computer and the target computer, determining whether the
client computer is authorized to resolve addresses of non secure
target computers and, if not so authorized, returning an error
from the DNS request.
(Appeal Br., Claims App. i–iii.)

C. Claim Construction
Patent Owner informs us that the ’135 Patent has expired. Appeal
Br. 6. Requester does not dispute that the ’135 Patent is expired, but rather
contends the Board need not construe the claims, which, according to
Requester, are unpatentable even under Patent Owner’s construction. Resp’t
Br. 2–4.
Because the ’135 Patent is expired, we construe the claims using the
standard in Phillips v. AWH Corp., 415 F.3d 1303 (Fed Cir. 2005) (en banc)
as held in In re CSB-Sys. Int’l Inc., 832 F.3d 1335, 1342 (Fed Cir. 2016)
(holding that the PTO should apply the Phillips standard for claim
construction once a patent expires). We largely agree with Requester, that
the claims on appeal do not require construction in order to resolve the
issues on appeal as discussed infra. However, to the extent claim
construction is necessary to resolve the case, we construe the claims under
Appeal 2021-001315
Reexamination Control 95/001,682
Patent 6,502,135 B1

6
the Phillips standard to the extent necessary as discussed below. Vivid
Techs., Inc. v. Am. Sci. & Eng’g, Inc., 200 F.3d 795, 803 (Fed. Cir. 1999).

D. Adopted Rejections
Patent Owner contests the Examiner’s decision to reject the claims as
follows (Appeal Br. 2–4; see RAN 6–10; Ans. 1):

4 Aventail Connect v3.1/v2.6 Administrator’s Guide, 1999 (“Aventail
Connect v3.1”).
5 Aventail Connect v3.01/v2.51 Administrator’s Guide, 1999 (“Aventail
Connect v3.01”).
6 Aventail AutoSOCKS v2.1 Administration & User’s Guide, 1997
(“AutoSOCKS”).
7 Michael G. Reed, Paul F. Syverson, and David M. Goldschlag, Proxies for
Anonymous Routing, 12th Annual Computer Security Applications
Conference, San Diego, CA, December 9–13, 1996 (“Reed”).
8 Boden et al., US 6,615,357 B1, issued September 2, 2003 (“Boden”).
9 Weiss, US 4,885,778, issued December 5, 1989 (“Weiss”).
Claim(s) Rejected 35 U.S.C. § Reference(s)
10, 12–14 102(a) Aventail Connect v3.14
10, 12–14 102(b) Aventail Connect v3.015
10, 12, 13 102(b) AutoSOCKS6
11 103(a) Aventail Connect v3.1,
Reed7
11 103(a) Aventail Connect v3.01,
Reed
11, 14, 15 103(a) AutoSOCKS, Reed
16 103(a) Aventail Connect v3.1,
Boden8
16 103(a) Aventail Connect v3.01,
Boden
16 103(a) AutoSOCKS, Reed, Boden
17 103(a) Aventail Connect v3.1,
Weiss9
17 103(a) Aventail Connect v3.01,
Appeal 2021-001315
Reexamination Control 95/001,682
Patent 6,502,135 B1

7

10 Wang, Broadband Forum TR-025: Core Network Architecture
Recommendations For Access to Legacy Data Networks over ADSL, Issue
1.0 (September 1999), accessible at http://www.broadband-forum.org/
technical/download/TR-025.pdf (“Wang”).
11 Beser et al., US 6,496,867 B1, issued December 17, 2002 (“Beser”).
12 S. Kent and R. Atkinson, “Security Architecture for the Internet Protocol,”
Network Working Group RFC 2401, November 1998 (“Kent”).
13 Blum et al., US 6,182,141 B1, issued January 30, 2001 (“Blum”).
14 BinGO! User’s Guide (“BinGO UG”) incorporating by reference BinGO!
Extended Feature Reference (“BinGO EFR”), accessible at
ftp://ftp.funkwerk-ec.com/bintec/old_products/bintec/bingo-generation/
bingo/doku/71000b.pdf, ftp://ftp.elmeg.de/bintec/doku/swref/old/
71050a_v12.pdf (collectively referred to as “BinGO”).
Weiss
17 103(a) AutoSOCKS, Weiss
10, 12, 13, 18 102(a) Wang10
11, 14, 15 103(a) Wang, Reed
16 103(a) Wang, Reed, Boden
17 103(a) Wang, Weiss
10, 12, 13, 18 103(a) Beser,11 Kent12
18 103(a) Beser, Kent, Blum13
18 103(a) Beser, Kent, AutoSOCKS
11 103(a) Beser, Kent, Reed
10, 12–15, 18 102(a) BinGO14
11 103(a) BinGO, Reed
16 103(a) BinGO, Borden
17 103(a) BinGO, Weiss
Appeal 2021-001315
Reexamination Control 95/001,682
Patent 6,502,135 B1

8
III. PATENT OWNER’S APPEAL
A. Rejections based on Aventail Connect v3.1, Aventail Connect v3.01, and
AutoSOCKS (“the Aventail References”) (Issues 19–30)15
1. The Examiner’s Rejections
The Examiner rejected claims 10–17 based on the Aventail
References either alone or in combination with other prior art by virtue of
adopting the Requester’s explanations in the Request. See RAN 10–22,
citing Request 18–24 and 38–118, Exh. C1–C3. The Examiner did not offer
any substantive comments in response to the Appeal Brief or Respondent
Brief. Ans. 1.

2. Patent Owner’s Contentions
Patent Owner contends, inter alia, the Aventail References do not
disclose the methods recited in the claims. Appeal Br. 11–25. Patent Owner
argues the Federal Circuit has already held that Patent Owner has disclaimed
systems such as those described in the Aventail References. Id. at 12, citing
VirnetX v. Mangrove Partners, 778 F. App’x at 909–10.

3. Requester’s Contentions
Requester does not dispute Patent Owner’s arguments, but rather
appears to agree with Patent Owner. See Resp’t Br. 1 (“Requester
recommends that the Board not affirm the Examiner’s rejections based on
[the Aventail References].”); Reb. Br. 3.

15 The designation “Issue 19” is based on the labeling of rejections by the
Patent Owner, Requester, and the Examiner. We refer to these designations
for convenience of the reader.
Appeal 2021-001315
Reexamination Control 95/001,682
Patent 6,502,135 B1

9

4. Discussion
As a result of the above discussion, it appears Requester has
withdrawn its earlier position that claims 10–17 would have been
unpatentable over the Aventail References alone or in combination with the
other prior art cited. In this regard, we observe that, as discussed above, the
Examiner’s rejections based on the Aventail References were adopted as set
forth in the Request. In addition, the Examiner relies almost exclusively on
(and adopts) Requester’s previous arguments in maintaining the rejections
based on the Aventail References. RAN 28–34.
In view of the above, we reverse the rejections of claims 10–17 over
the Aventail References.16

B. Anticipation – Wang (Issue 31)
We limit our discussion to claims 10, 13, and 18, which is sufficient to
resolve the issues associated with this rejection. See 37 C.F.R.
§ 41.67(c)(1)(vii).
1. Claims 10 and 18
a) The Examiner’s Findings
The Examiner adopted the proposed rejection of independent claims
10 and 18 as set forth in the Request. RAN 22, citing Request 12–13,

16 In this regard, although the Answer indicates all of the grounds in the
RAN are maintained based on the determinations made therein (Ans. 1), we
cannot reconcile the Examiner’s positions, which adopt Requester’s
rejections and positions, with the positions set forth by the Requester in the
Respondent Brief.
Appeal 2021-001315
Reexamination Control 95/001,682
Patent 6,502,135 B1

10
25–26, and 119–139, 142; Exh. C4. Thus, the Examiner found Wang
discloses client computers (PC Clients), a gateway computer (PC-based
remote access server), and a corporate network containing secure destination
computers. Request 135, 137–138. The Examiner found Wang discloses
systems that include a DNS proxy server, namley L2TP Access Aggregation
(LAA) architecture, which includes an L2TP Access Concentrator (LAC) as
the DNS proxy server, and point-to-point protocol (PPP) Terminated
Aggregation (PTA), which includes a Broadband Access Server (BAS) as
the DNS proxy server. Request 135–137; Exh. C4, 24–27. The Examiner
found Wang discloses in the LAA architecture, PPP tunnels through the
Regional Broadband Network, and the PPP allows for authentication to be
requested during negotiation of a configuration request. Request 135–136.
The Examiner found Wang discloses the LAC determines the destination of
the request based on the user-name and domain information, and also
whether a tunnel exists to the proper L2TP Network Server (LNS), and if a
tunnel does not exist, the LAC establishes one. Request 136. The Examiner
found the BAS provides similar functions in the PTA architecture. Request
136–137.
The Examiner found Wang discloses “VPNs (i.e., secure encrypted
tunnels being established after authentication)” that are established in
response to DNS requests specifying a secure domain, a corporate network.
Request 135–137, citing Wang 14–16, 18; see id. at 124, citing Wang 8–9.

b) Patent Owner’s Contentions
Patent Owner contends, inter alia, that neither the L2TP Access
Concentrator (LAC) used in the L2TP Access Aggregation (LAA)
Appeal 2021-001315
Reexamination Control 95/001,682
Patent 6,502,135 B1

11
architecture nor the Broadband Access Server (BAS), used in the point-to-
point protocol (PPP) Terminated Aggregation (PTA) architecture disclosed
in Wang correspond to the DNS proxy server recited in claim 10. Appeal
Br. 27. In particular, Patent Owner argues the LAC and BAS do not receive
a request from a client computer to look up an IP address for a domain
name, but rather, only receive a user name from the user computer during
the PPP authentication phase. Id. Thus, Patent Owner argues the LAC and
BAS challenge the user for a user-name and password, and a user’s response
to this challenge is not a request to look up an IP address even if the
destination Network Service Provider (NSP) is determined by the LAC and
BAS after receiving a user-name. Id. at 28.
Similarly, Patent Owner argues Wang’s LAC and BAS do not
disclose the DNS proxy server in claim 10, because neither returns an IP
address for a requested domain name if it is determined that access to a non-
secure web site has been requested. Appeal Br. 28–29. In this regard,
Patent Owner contends the Examiner has already determined Wang does not
disclose this feature in reference to claim 3, which recites similar language.
Id. at 28, citing, e.g., Action Closing Prosecution (“ACP”) dated April 27,
2015. Patent Owner contends the LAC determines only the destination
Network Service Provider (NSP) from the name, determines if a tunnel
already exists to the proper LNS, and if one does not, the LAC establishes a
tunnel. Id. at 29. Patent Owner contends the BAS does not include
additional DNS servers as indicated by Requester, and further that the NSP
is not alleged to be the claimed DNS proxy server, such that the NSP cannot
correspond to the claimed DNS proxy server. Id.
Appeal 2021-001315
Reexamination Control 95/001,682
Patent 6,502,135 B1

12
Patent Owner also contends that Wang’s LAC and BAS do not
generate a request to create a VPN between a client computer and a secure
target computer as recited in claim 10. Id. at 29–30. Patent Owner argues
Requester has not shown that a tunnel exists in any portion of the path
between the user computer and the NSP through the BAS such that Wang
does not disclose a VPN, and with regard to the LAC, the mere creation of a
tunnel does not mean traffic satisfies all the requirements of a VPN. Id. at
30. Patent Owner argues that in view of Wang’s failure to disclose a VPN,
Wang fails to disclose the gatekeeper computer recited in claim 10. Id. at
31–32.
Patent Owner contends also that Requester has improperly combined
elements from different architectures, the LAC and BAS of Wang, in order
to meet the recited DNS proxy server of claim 10. Id. at 31.
Regarding independent claim 18, Patent Owner contends Wang does
not disclose generating a DNS request from a client computer that requests
an IP address corresponding to a domain name associated with a target
computer, because Wang merely discloses that a user name is provided by a
user to the LAC or BAS (an intermediate device) so that the user’s intended
NSP is known. Id. at 34–36. Patent Owner contends Wang fails to disclose
automatically initiating a VPN between a client computer and a target
computer in response to determining a DNS request is requesting access to a
secure target web site. Id. at 36–38. Similar to claim 10, Patent Owner
argues that the rejection improperly combines separate elements from Wang
to anticipate claim 18. Id. at 38.

Appeal 2021-001315
Reexamination Control 95/001,682
Patent 6,502,135 B1

13
c) Requester’s Contentions
Requester contends the rejection should be affirmed for the reasons
stated in the RAN and the Request, as Patent Owner’s arguments are
substantially the same as those previously of record. Resp’t Br. 13.

d) Analysis
We are persuaded by Patent Owner’s contentions that Wang does not
look up an IP address for a domain name as a result of a request from a
client computer as recited in claim 10 and generating from the client
computer a DNS request that requests an IP address corresponding to a
domain name associated with the target computer as recited in claim 18.
Wang discloses that in the LAA embodiment, the user will send a request to
initiate a session between a user’s Customer Premises Equipment (CPE) and
the LAC (DNS proxy server), where for the purposes of authentication, the
user enters a user name as well as a domain name for the Network Service
Provider (NSP) for example, by entering “Joe@nsp.net.” Wang 14–15. The
LAC determines the destination NSP “[b]ased on the user-name and domain
information.” Id. at 15. The LAC establishes a tunnel to the proper LNS if
one does not exist. Id. Thus, as Patent Owner contends, Wang does not
disclose the LAC returns an IP address as recited in claim 10. See
Keromytis Decl. ¶¶ 78, 79.
Similarly, in the PTA architecture, Wang discloses the user initiates a
PPP session to the BAS over Asynchronous (ATM) Virtual Circuit
Connection (VCC), where the virtual dialer will send a PPP Link Control
Protocol (LCP) Configuration-Request to the BAS. Wang 18. The BAS
responds with a PPP LCP configuration-ACK and the PPP dialer responds
Appeal 2021-001315
Reexamination Control 95/001,682
Patent 6,502,135 B1

14
with a PPP LCP Configuration-ACK to complete the configuration. Id.
After a link is established, the BAS initiates an authentication stage, which
challenges the user for a user-name and password, and the user will reply
with a fully qualified domain name. Id. Wang discloses “[t]he BAS extracts
the domain string portion of the user-name and sends off a query to NSP to
authenticate and obtain address information (e.g., DNS server’s address).”
Id. Wang discloses “[i]n the case of IP network, The NSP replies with an IP
address and other IP configuration information (e.g. DNS Server’s address).
This information is passed along to the user during the NCP phase for
configuring IP transport (based on IPCP).” Id. Thus, as Patent Owner
contends, Wang discloses receiving the IP address of the DNS server and not
the IP address of a domain name for a target computer. Appeal Br. 35;
Keromytis Decl. 80.
Further with respect to claim 10, the Examiner and Requester do not
address, and we cannot reconcile, the apparent inconsistency identified by
Patent Owner in the Examiner’s positions regarding the similar language in
claims 3 and 10 as to whether Wang discloses a DNS proxy server that
returns an IP address for a requested domain name if it is determined that
access to a non-secure web site has been requested. After identifying the
proposed rejection of claim 3 from the Request, the Examiner agreed that it
was well known for DNS servers to return an IP address associated with a
domain name, but found such was not the only mode of operation for the
systems disclosed in Wang. ACP 23–24, citing Request 128, Wang 18. The
Examiner found the portion of Wang cited in the Request discloses returning
an IP address of the DNS server, not the IP address associated with the target
domain name. Id. at 24. Thus, the Examiner found the Request was
Appeal 2021-001315
Reexamination Control 95/001,682
Patent 6,502,135 B1

15
deficient in showing Wang discloses a DNS server that returns an IP address
associated with a domain name in response to a query for access to a non
secure target and showing that such an operation in Wang would have been
inherent. Id. Requester did not dispute the Examiner’s findings with respect
to claim 3. See Req. 3rd Comments 18–25 (addressing anticipation
rejections of the claims based on Wang, but not the Examiner’s findings that
the Request failed to show claim 3 was anticipated). The Examiner made no
additional comments or findings with respect to claim 10 being anticipated
by Wang, choosing instead to rely solely on the Request and Requester’s
comments with respect thereto. See ACP 23, 38; RAN 22, 34, citing
Request 12, 13, 25, 26, 119–142, Exh. C4; Req. 3rd Comments 18–25. We
observe that the Request, in describing how claims 3 and 10 are anticipated
by Wang, relies on some of the same passages therein. Compare Request
Exh. C4, 11–12, with 23–26.
Moreover, we are unable to find a clear statement of how Wang
discloses a DNS proxy server that returns an IP address for a requested
domain name if it is determined that access to a non-secure web site has
been requested as recited in claim 10. See, e.g., Request 12, 13, 25, 26, 119–
142, Exh. C4; Req. Req. 3rd Comments 18–25. That is, Requester focuses
on whether Wang discloses a DNS proxy server that returns an IP address as
a general matter, rather than the specific language of claim 10, as to what
happens in the event it is determined the DNS request is for a non-secure
web-site.
Therefore, we agree with Patent Owner that the Examiner and
Requester have failed to provide sufficient explanation that Wang discloses
the system and method recited in claims 10 and 18 as arranged in the claims.
Appeal 2021-001315
Reexamination Control 95/001,682
Patent 6,502,135 B1

16
Appeal Br. 31 (citing NetMoneyIN, Inc. v. VeriSign, Inc., 545 F.3d 1359,
1371 (Fed. Cir. 2008)), 36 (citing Richardson v. Suzuki Motor Co., 868 F.2d
1226, 1236 (Fed. Cir. 1989)).
Accordingly, we reverse the Examiner’s rejection of claims 10 and 18
as anticipated by Wang.

2. Claim 13
a) The Examiner’s Findings
The Examiner adopted the proposed rejection of independent claim 13
as set forth in the Request. RAN 22, citing Request 12–13, 25–26, and 139–
142; Ex. C4.
b) Patent Owner’s Contentions
Patent Owner argues Wang does not disclose a central computer that
maintains a plurality of authentication tables each corresponding to one of
the client computers, because authentication tables are not inherently present
in the LAC and BAS, which are alleged to correspond to the central
computer. Appeal Br. 32–33. Patent Owner argues also that the LAC and
BAS in Wang control admissions to tunnels based on the number of users in
a tunnel, and not responsive to authorization of a client, such that Wang does
not disclose allocating resources to establish a VPN based on a
determination that a client is authorized. Id. at 33–34.
c) Requester’s Contentions
Requester contends the rejection should be affirmed for the reasons
stated in the RAN and the Request, as Patent Owner’s arguments are
substantially the same as those previously of record. Resp’t Br. 13.

Appeal 2021-001315
Reexamination Control 95/001,682
Patent 6,502,135 B1

17
d) Analysis
We are not persuaded by Patent Owner’s arguments. That is, Patent
Owner’s main argument is that the LAC does not compare the user name
with any credential stored therein, and similarly, the BAS does not compare
the received user name and password to any credentials stored therein, but
rather sends a query to the NSP to authenticate, and as such neither the LAC
nor the BAS is a central computer “maintains a plurality of authentication
tables” as recited in claim 13.
In responding to Patent Owner’s arguments, the Examiner, in the
RAN, incorporated by reference Requester’s Comments filed July 15, 2015
(“Req. 3rd Comments”). RAN 34. The Examiner and Requester rely on the
LAC as a central computer in the LAA architecture, and the BAS as the
central computer in the PTA architecture. Request, Exh. C4, 32–33; Req.
3rd Comments 24. The Request identifies the authentication phase between
the request from the client and the LAC, and the username and password
unique to the user as the information contained in authentication tables on
the LAC. Request, Exh. C4, 32, citing Wang, 14–15. In addition, the
Request specifically identifies Challenge Handshake Authentication
Protocol (CHAP) used in conjunction with the BAS as involving a
comparison of credentials stored on the server computer with credentials
presented by a client computer as involving the use of authentication tables.
Request, Exh. C4, 32–33, citing Wang, 18, Fig. 8. We agree with the
Examiner and Requester that claim 13 does not recite any particular form or
content for the “authentication tables” recited therein. Req. 3rd Comments
24. As such, we do not discern a distinction between the username and
password information that would be stored on the LAC for authentication
Appeal 2021-001315
Reexamination Control 95/001,682
Patent 6,502,135 B1

18
phase or the BAS for CHAP authentication and the “authentication tables”
recited in claim 13.
As to Patent Owner’s arguments that the LAC and BAS in Wang do
not allocate resources responsive to a determination that the request is from
an authorized client, the Request explains that upon authenticating a client,
Wang discloses several gateway computers (LAC, BAS, and NSP) that
allocate resources to establish a VPN. Request, Exh. C4, 32–35, citing
Wang 12, 14–22. Patent Owner’s arguments appear to be based on the
position that Wang does not disclose client authorization (Appeal Br. 33–
34), which we found unpersuasive as previously discussed. In this regard,
whether the LAC and BAS also perform admission control based on the
number of users in a tunnel (Appeal Br. 34) does not address the rationale in
the Request and adopted by the Examiner.
As a result, we affirm the Examiner’s rejection of claim 13 as
anticipated by Wang.
C. Obviousness – Wang, Reed, Boden, Weiss (Issues 34–36)
1. Claims 11, 14, and 15 – Wang, Reed (Issue 34)
a) Claims 11 and 14
Regarding claim 11, which depends from claim 10, because we
reversed the rejection of claim 10, and as Patent Owner points out, Reed
does not remedy the deficiencies of Wang (Appeal Br. 39), we reverse the
rejection of claim 11 as obvious over Wang and Reed.
Regarding claim 14, Patent Owner does not set forth any additional
arguments with respect to claim 14, relying on it dependency from claim 13
as basis for patentability. Appeal Br. 39. Accordingly, we affirm the
Appeal 2021-001315
Reexamination Control 95/001,682
Patent 6,502,135 B1

19
Examiner’s rejection of claim 14 for similar reasons as discussed above with
respect to claim 13.
b) Claim 15
Claim 15 depends from claim 14 and recites “wherein step (4)
comprises the step of comparing an Internet protocol (IP) address in a header
of each data packet to a table of valid IP addresses maintained in a table in
the second computer.”
The Examiner relied on the explanation provided by Requester in the
Request that Reed discloses comparing IP addresses because Reed discloses
“[w]hen a data cell arrives, the onion router looks up the cell’s identifier in
its tables and finds the corresponding outbound identifier.” RAN 23, citing
Request 145–146; Request Exh. C4, 36; Reed 7.
Patent Owner contends Reed does not disclose or suggest the features
of claim 15. Appeal Br. 39 (citing § VIII(I)(3), 22). In particular, Patent
Owner argues Reed discloses an onion router, which looks up a data cell’s
identifier in its tables when the data cell arrives at the onion router. Id. at 22,
citing Reed § 5.3.1. Patent Owner contends the cell identifiers are not IP
addresses, because they identify an anonymous connection and not the onion
router transmitting a cell. Id. citing Reed §§ 5.1, 5.2.1, Fig. 3.
The Examiner and Requester do not respond to Patent Owner’s
arguments. Resp’t Br. 14; Req. Req. 3rd Comments 25.
We agree with Patent Owner that there is no indication in Reed that
the cell identifier disclosed therein is an IP address. Reed discloses “cells
have type data and are labeled with the identifier of the associated
anonymous connection.” Reed 7, § 5.3.1. The onion router looks up the
cell’s identifier in tables within the onion router to find the corresponding
Appeal 2021-001315
Reexamination Control 95/001,682
Patent 6,502,135 B1

20
outbound identifier. Id. The Examiner and Requester do not sufficiently
explain how the identifier would be an IP address. Indeed, Requester relies
on the Declaration of Michael Fratto executed on July 7, 2011 (Resp’t Br.
Exh. E2) for support. See Request Exh. C4, 36, citing Fratto Decl. Exh. E2
¶¶ 193–194. Yet, the cited portion of the Fratto Declaration discussing
claim 15 does not rely on Reed for disclosing tables of IP addresses. Fratto
Decl. ¶¶ 193–194.
As a result, we reverse the Examiner’s rejection of claim 15 as
obvious over Wang and Reed.

2. Claim 16 – Wang, Reed, Boden (Issue 35)
Claim 16, depends from claim 15 and is rejected over the combination
of Wang, Reed, and Boden. See RAN 23; Request 147–148; Exh. C4, 37–
38. Thus, because, as Patent Owner points out, Boden does not remedy the
deficiencies of Reed (Appeal Br. 39), we reverse the Examiner’s rejection of
claim 16 for similar reasons as discussed above for claim 15.

3. Claim 17 – Wang, Reed, Weiss (Issue 36)
Regarding claim 17, Patent Owner does not set forth any additional
arguments with respect to claim 17, relying on its dependency from claim 13
as the basis for patentability. Appeal Br. 39–40. Accordingly, we affirm the
Examiner’s rejection of claim 17 for similar reasons as discussed above with
respect to claim 13.

Appeal 2021-001315
Reexamination Control 95/001,682
Patent 6,502,135 B1

21
D. Obviousness – Beser and Kent (Issues 37–40)
We limit our discussion to claims 10, 13, and 18, which is sufficient to
resolve the issues associated with these rejections. See 37 C.F.R.
§ 41.67(c)(1)(vii).
1. Claim 10
a) The Examiner’s Findings
In rejecting claim 10 as obvious over Beser and Kent, the Examiner
adopted the rejections as proposed by Requestor. RAN 24, citing Request
13, 29–30, and 150–173, Exh. C5.

b) Patent Owner’s Contentions
Patent Owner contends, inter alia, Beser and Kent do not disclose or
suggest both a request to look up an IP address for a domain name and a
request to create a VPN as recited in claim 10, because Beser’s tunneling
request (request to initiate a VoIP association) cannot be both requests, as
there is no request from the trusted-third-party network device to the second
network device to negotiate the IP tunnel. Appeal Br. 47.

c) Requester’s Contentions
Requester argues Beser receives a request from a client computer to
look up an IP address for a domain name because Beser discloses that the
trusted-third-party-network device, which can be a DNS server, contains a
table that correlates unique identifiers (domain names) to both the IP address
of the terminating device and the IP address of the associated second
network device. Id. at 10–11. Requester contends Beser and Kent teach
both a request to look up an IP address for a domain name and a request to
Appeal 2021-001315
Reexamination Control 95/001,682
Patent 6,502,135 B1

22
create a VPN, because Beser discloses that after the trusted-third-party
network device receives a tunneling request, it sends a request to the second
network device to begin negotiating the IP tunnel (VPN). Id. at 11.

d) Analysis
Claim 10 recites “a gatekeeper computer that allocates resources for
the VPN between the client computer and the secure web computer in
response to the request by the DNS proxy server.” As explained in the ’135
Patent, the “[g]atekeeper 2603 can be implemented on a separate computer
(as shown in FIG. 26) or as a function within the modified DNS server
2602.” ’135 Patent, col. 38, ll. 53–55. Claim 10 expressly recites a system
including a DNS proxy server and a gatekeeper computer that allocates
resources for the VPN. Thus, in view of the ’135 Patent, we interpret claim
10 to be directed to embodiments where the gatekeeper is a separate
computer and not a function within the DNS server.
In the rejection, the Examiner and Requestor rely on the trusted third
party network device disclosed in Beser as a gateway computer (see
Request, Exh. C5, 12, 16) and also as the DNS proxy server (see Resp’t Br.
9 (discussing how the trusted-third-party network device would return an
unsecure IP address, recited in claim 10 as a function performed by the DNS
proxy server); Request, Exh. C5, 14). Beser discloses a trusted third party
network device 30 that is connected to a public network 12, which may be a
domain name server. Beser, col. 3, l. 60 – col. 4, l. 18; Fig. 1. Although
Beser discloses the trusted-third party network device 30 may be distributed
over several locations (id.), the rejection does not sufficiently explain how
Beser would be modified to meet the requirements set forth in claim 10.
Appeal 2021-001315
Reexamination Control 95/001,682
Patent 6,502,135 B1

23
Thus, because claim 10 requires a gatekeeper computer that allocates
resources for the VPN that is separate from a DNS proxy server, we agree
with Patent Owner that the same third party trusted network cannot relied on
as disclosing both limitations. Appeal Br. 47.
As a result, we reverse the Examiner’s rejection of claim 10 and claim
12, dependent therefrom, as obvious over Beser and Kent.
In addition, claim 11, which depends from claim 10, is separately
rejected as obvious over Beser, Kent, and Reed (Issue 40). Reed does not
remedy the above noted deficiencies (see Request, Exh. C5, 16–18). Thus,
we reverse the rejection of claim 11 as well.

2. Claim 13
Although claim 13 is listed as rejected in the Request (see Request 29)
and in the Right of Appeal Notice (see RAN 24), we agree with Patent
Owner (Appeal Br. 48–49) that there is no articulation of a rejection of claim
13. See Request, Exh. C5, 18–19 (showing claim charts for claims 12 and
18, but not claim 13). Neither the Requester nor the Examiner provides any
clarity with respect to this issue. See RAN generally; Resp’t Br. 4–14. We
are of the view the reference to claim 13 in the rejection is a typographical
error.
However, to the extent that the Request and RAN may be interpreted
to set forth a rejection of claim 13 as obvious over Beser and Kent, we
reverse such a rejection as being facially deficient. That is, there is no
articulated prima facie case of how the limitations of claim 13 would have
been rendered obvious over Beser and Kent on this record.

Appeal 2021-001315
Reexamination Control 95/001,682
Patent 6,502,135 B1

24
3. Claim 18
a) The Examiner’s Findings
In rejecting claim 18 as obvious over Beser, Kent, Blum, and
AutoSOCKS, the Examiner adopted the rejections as proposed by
Requestor. RAN 24–25, 36–37, citing Request 12, 13, 29–32, 150–173, and
178–182, Exh. C5.

b) Patent Owner’s Contentions
Patent Owner argues one of ordinary skill in the art would not have
combined Beser and Kent because Beser teaches away from encryption
between a client computer and a target computer and the IPsec protocol
disclosed in Kent. Appeal Br. 42–44, 49. Patent Owner contends Beser and
Kent do not disclose or suggest receiving a request from a client computer to
look up an IP address for a domain name or determining whether the DNS
request is requesting access to a secure web site. Id. at 46, 49–51.
Patent Owner contends also that Beser and Kent do not disclose or
suggest returning an IP address for a requested domain name if it is
determined that access to a non-secure web site has been requested. Id. at
44–45. Specifically, Patent Owner contends that Beser is silent as to what
would happen if an identifier for an unknown destination were sent to the
trusted-third-party network device, and if the destination is unknown, the
trusted-third-party network device has no information about the destination
and therefore cannot determine whether the tunneling request is requesting
access to a secure or unsecure destination or web site. Id.
Patent Owner argues Beser and Kent do not disclose or suggest
determining whether the client computer is authorized to resolve addresses
Appeal 2021-001315
Reexamination Control 95/001,682
Patent 6,502,135 B1

25
of non-secure target computers. Id. at 51. Patent Owner contends also that
Blum’s DNS services do not factor in client authorization. Id. at 52–53.

c) Requester’s Contentions
Requester points out that the Board, in a number of other proceedings
involving other patents in the same family as the ’135 Patent, has made
findings with respect to Beser that are consistent with the Examiner’s
determinations in the current reexamination. Resp’t Br. 4–5. Requester
argues Beser does not teach away from encryption in IP tunneling
applications, rather, Beser discloses encryption is conventional and is
ordinarily used in IP tunneling schemes, expressly referring to Kent for such
implementations. Id. at 6–8. Requester argues the practical concerns in
implementing encryption in IP tunneling schemes discussed in Beser are in
only two data transfer scenarios that may be overcome by using more
powerful equipment. Id. at 7–8. Requester contends that contrary to Patent
Owner’s argument that Beser does not disclose returning an IP address if it
is determined that access to a non-secure web site is requested, Beser
discloses the trusted-third-party network device would return either an
unsecure IP address, or if the identifier was not contained in a public DNS
entry, a “host unknown” error. Id. at 9. Requester argues Beser receives a
request from a client computer to look up an IP address for a domain name
because Beser discloses that the trusted-third-party-network device, which
can be a DNS server, contains a table that correlates unique identifiers
(domain names) to both the IP address of the terminating device and the IP
address of the associated second network device. Id. at 10–11. Requester
contends Beser and Kent teach both a request to look up an IP address for a
Appeal 2021-001315
Reexamination Control 95/001,682
Patent 6,502,135 B1

26
domain name and a request to create a VPN, because Beser discloses that
after the trusted-third-party network device receives a tunneling request, it
sends a request to the second network device to begin negotiating the IP
tunnel (VPN). Id. at 11.
Requester contends Blum discloses errors are provided in a variety of
scenarios incidental to DNS queries in its scheme, such as if a DNS request
fails or to enforce security policies. Resp’t Br. 12. Requester contends that
Patent Owner admits various errors are returned in VPN deployment using
IPSec as disclosed in Kent including “ICMP error messages.” Id.

d) Analysis
(1) Collateral Estoppel
At the outset, we observe, as does Requester, that several issues
identified by Patent Owner with respect to the combination of Beser and
Kent have been decided previously by the Board in other proceedings and
subsequently affirmed by the Federal Circuit. In particular, Patent Owner’s
arguments that Beser teaches away from the use of encryption and the IPsec
protocol disclosed in Kent, as well as Patent Owner’s arguments that Beser
does not render obvious looking up an IP address for a domain name and
determining whether the request is requesting access to a secure/non-secure
web site have been addressed and as such, we are of the view that Patent
Owner is collaterally estopped from relying on such arguments here for the
reasons that follow.
As recently held by our reviewing court in SynQor, Inc. v. Vicor
Corp., No. 19-1704, slip op. at 13–14, 18 (Fed. Cir. Feb. 22, 2021),
collateral estoppel arising from a first reexamination may be applied to a
Appeal 2021-001315
Reexamination Control 95/001,682
Patent 6,502,135 B1

27
second reexamination. In addition, as noted in SynQor, issue preclusion
applies to inter partes review. Id. at 7, citing Papst Licensing GmbH & Co.
KG v. Samsung Elecs. Am., Inc., 924 F.3d 1243, 1250–51 (Fed. Cir. 2019).
Thus, as further discussed below, we do not see a reason why issue
preclusion would not apply to a reexamination based on a previous inter
partes review.
Issue preclusion is appropriate only if: (1) the issue is
identical to one decided in the first action; (2) the issue was
actually litigated in the first action; (3) resolution of the issue was
essential to a final judgment in the first action; and (4) plaintiff
had a full and fair opportunity to litigate the issue in the first
action.
SynQor, slip op. at 18, quoting In re Freeman, 30 F.3d 1459, 1465 (Fed. Cir.
1994).
In determining whether the issues are identical, we observe that the
patent claims of the patents at issue in each proceeding need not be identical.
Id., quoting Ohio Willow Wood Co. v. Alps S., LLC, 735 F.3d 1333, 1342
(Fed. Cir. 2013). In addition, “an ‘issue’ must be understood broadly
enough ‘to prevent repetitions litigation of what is essentially the same
dispute.’” Id. at 18–19, citing B&B Hardware, Inc. v. Hargis Indus., Inc.,
575 U.S. 138, 157 (2015) (citing Restatement (Second) of Judgments § 27
cmt. c, at 252–253).
Here, Patent Owner has argued in multiple inter partes review
proceedings in which the combination of Beser and Kent have been applied
to claims reciting a request for an IP address based on a domain name and
where a virtual private network link is established, that Beser does not
disclose or suggest DNS look up functionality and that Beser teaches away
Appeal 2021-001315
Reexamination Control 95/001,682
Patent 6,502,135 B1

28
from the use of IPsec protocol in Kent, arguments that were rejected by the
Board and where the Decisions were affirmed by the Federal Circuit. See
Apple, Inc. v. VirnetX, Inc., IPR2016-00331, Paper 29 at 6, 21–41 (PTAB
June 22, 2017) (Final Written Decision), aff’d, VirnetX, Inc. v. Apple, Inc.,
909 F.3d 1375 (Fed. Cir. 2018); Apple, Inc. v. VirnetX, Inc., IPR2015-
00810, Paper 44 at 5, 26–45 (PTAB August 30, 2016) (Final Written
Decision); Apple, Inc. v. VirnetX, Inc., IPR2015-00812, Paper 43 at 4–5, 16–
38 (PTAB August 30, 2016) (Final Written Decision); Apple, Inc. v.
VirnetX, Inc., IPR2015-00866, Paper 39 at 4–5, 17–39 (PTAB September
28, 2016) (Final Written Decision); Apple, Inc. v. VirnetX, Inc., IPR2015-
00868, Paper 39 at 5, 18–41 (PTAB September 28, 2016) (Final Written
Decision); Apple, Inc. v. VirnetX, Inc., IPR2015-00870, Paper 39 at 4–5, 29–
52 (PTAB September 28, 2016) (Final Written Decision), aff’d, VirnetX, Inc.
v. Apple, Inc., 715 F. App’x 1024 (Fed. Cir. 2018). See VirnetX, 909 F.3d at
1378 (discussing that a Rule 36 judgment may serve as a basis for collateral
estoppel, citing Phil-Insul Corp. v. Airlite Plastics Co., 854 F.3d 1344,
1356–57 (Fed. Cir. 2017)).
Thus, the issues of whether as a general matter, Beser teaches away
from encryption and the IPsec protocol disclosed in Kent, whether Beser
discloses or renders obvious receiving a request to look up an IP address for
a domain name, and whether Beser determines that a requested web-site is
secure/non-secure are identical and actually litigated in the aforementioned
inter partes review proceedings. Such issues were also essential to the final
judgment, because they were essential to the determination of whether Beser
and Kent rendered the claims obvious. Moreover, Patent Owner had a full
and fair opportunity to litigate such issues in the inter partes review
Appeal 2021-001315
Reexamination Control 95/001,682
Patent 6,502,135 B1

29
proceedings through the presenting of evidence in the form of expert
declarations and cross-examination. See SynQor, slip op. at 15–17 (citing
MaxLinear, Inc. v. CF CRESPE LLC, 880 F.3d 1373, 1376 (Fed. Cir. 2018),
for the proposition that live testimony is not a prerequisite for the application
of collateral estoppel in administrative proceedings such as inter partes
reviews). Accordingly, Patent Owner is collaterally estopped from arguing
that Beser teaches away from encryption and that Beser fails to disclose or
render obvious receiving a request to look up an IP address for a domain
name and determining whether the request is to a secure/non-secure web
site.
Alternatively, even if collateral estoppel does not apply, the findings
and rationale of the Examiner and arguments and evidence cited by
Requestor, as summarized above, show persuasively that the combination of
Beser and Kent renders obvious the claims at issue here. Accordingly, no
good reason exists on this record to depart from the above-listed Board
decisions directed to materially similar issues.

(2) “determining whether the client computer is authorized . . .”
Claim 18 recites in part, “step (3) comprises the step of, prior to
automatically initiating the VPN between the client computer and the target
computer, determining whether the client computer is authorized to resolve
addresses of non secure target computers and, if not so authorized, returning
an error from the DNS request.”
The ’135 Patent discloses a scenario where if a client does not have
permission to establish a normal/non-VPN link, the gatekeeper would reject
the request and the DNS proxy server would return an error message to the
Appeal 2021-001315
Reexamination Control 95/001,682
Patent 6,502,135 B1

30
client. ’135 Patent, col. 40, ll. 4–13. The language of claim 18 is confusing
because the language appears to be directed to the disclosed scenario at
column 40, lines 4–13 of the ’135 Patent, but the claim language does not
clearly recite this scenario. In an effort to resolve the issues with respect to
claim 18, we consider Patent Owner’s arguments and decide whether as a
general matter, the prior art would have rendered obvious determining
whether a client has permission to access a web site and if not, returning an
error message.
We observe, as does Patent Owner, that although claim 18 is listed as
rejected as obvious over Beser and Kent alone (RAN 24, Issue 37), and
additionally over the combination of Beser, Kent, and Blum (RAN 24, Issue
38), the rejection of claim 18 as set forth in the Request and adopted by the
Examiner does not explain how claim 18 would have been obvious over
Beser and Kent alone, but rather relies on Blum for the client authorization
recitation. See Request 176–178, Exh. C5, 19–21. Moreover, regarding the
combination of Beser, Kent, and AutoSOCKS (RAN 25, Issue 39; Request
181–182), although the Examiner indicates that the proposed rejection is
adopted, as Patent Owner observes, the Examiner expressly found
AutoSOCKS does not disclose determining whether the client is authorized
to resolve addresses of non-secure target computers. RAN 18.
Accordingly, we limit our discussion to the combination of Beser,
Kent, and Blum, and to the extent claim 18 stands rejected over the
combination of Beser and Kent alone or the combination of Beser, Kent, and
AutoSOCKS, we reverse such rejections due to the lack of a prima facie
case.
Appeal 2021-001315
Reexamination Control 95/001,682
Patent 6,502,135 B1

31
We are not persuaded by Patent Owner’s arguments. In particular,
Patent Owner’s arguments that Beser does not necessarily require any
determination of client computer authorization and that Kent’s disclosure of
ICMP error messages do not relate to authorization or DNS requests (Appeal
Br. 52, citing Keromytis Decl. ¶ 102 and Supp. Keromytis Decl. ¶ 21) fail to
appreciate what the prior art as a whole would convey to one of ordinary
skill in the art. In this regard, Beser discloses the IP packets may require
authentication (Beser, col. 11, ll. 22–25), and Kent discloses access control,
which is “prevention of use of a resource in an unauthorized manner.” Kent
4, 45. Further, Blum discloses employing protocol filters in order to impart
specific capabilities and functions, and when services are not available to a
client computer, an error message may be returned to the client. Blum,
col. 7, ll. 35–38, 56–58; col. 8, l. 65 – col. 9, l. 3.
Thus, the determination of what web sites, whether secure or non-
secure, are available to the client would have been an obvious variation of
the authentication procedures disclosed in Beser, Kent, and Blum, such that
determining whether a client is authorized to access a non secure target
computer and returning an error if the client is not authorized to access a
non-secure target as recited in claim 18 would have been obvious.
Accordingly, we affirm the Examiner’s rejection of claim 18 as
obvious over Beser, Kent, and Blum.

E. Anticipation – BinGO (Issue 41)
We limit our discussion to claims 10, 13, 14, and 18, which is
sufficient to resolve the issues associated with this rejection. See 37 C.F.R.
§ 41.67(c)(1)(vii).
Appeal 2021-001315
Reexamination Control 95/001,682
Patent 6,502,135 B1

32
1. Claim 10
a) The Examiner’s Findings
The Examiner adopted the rejection of claims 10, 12–15, and 18 as
anticipated by BinGO as proposed in the Request. See RAN 25–26, citing
Request 13, 14, 32, 33, and 184–218; Exh. C6. Thus, the Examiner found
that BinGO discloses systems including client computers, the BinGO! router
or routers in a corporate network acting as a gateway computer, and
destinations that are both secure and non-secure. Request 206, citing BinGO
15, Fig. 1-1. The Examiner found BinGO discloses three different ways that
will determine if a DNS request specifies a secure destination: (1) a local
DNS server is set up on a Local Area Network (LAN); (2) the client
computer will compare the DNS request first to the data in the LMHOSTS
(LAN Manager HOSTS) file on the client computer; and (3) the BinGO!
router is configured to have a corporate network as a “default route,” where
the DNS request would be resolved. Id. at 206–207, citing BinGO UG 17,
40, 145, 175–176, 265–266; BinGO EFR 82–85. The Examiner found
BinGO discloses automatically establishing a VPN if a secure destination is
requested and if a non-secure web site is requested an IP address of that
DNS request is returned to the client computer. Id. The Examiner found
BinGO discloses the BinGO! router is a gateway computer, because it is
separate from the client computer and allocates resources for the VPN
between the client computer and the secure web computer in response to the
DNS request. Id. at 207.

Appeal 2021-001315
Reexamination Control 95/001,682
Patent 6,502,135 B1

33
b) Patent Owner’s Contentions
Patent Owner contends BinGO does not disclose determining that
access to a secure web site has been requested as recited in claim 10.
Appeal Br. 55. That is, Patent Owner argues BinGO’s disclosures of
querying a local DNS server on a local area network (LAN), querying a
LMHOSTS file, and querying a “default route” in the absence of any
internet service provider (ISP) do not perform the determining step of claim
10. Id. Patent Owner argues querying a local DNS server on a LAN and
querying a default route in the absence of any ISP, the BinGO! router
blindly forwards a request to a primary domain name server in accordance
with its “Static Settings.” Id. at 55–56. As a result, Patent Owner contends
the BinGO! router makes no determination as recited in claim 10. Id. at 56.
Patent Owner contends BinGO discloses that LMHOSTS is an alternative to
setting up a domain name server and operates without asking for a DNS. Id.
Patent Owner contends that BinGO does not disclose a gatekeeper computer
that allocates resources for the VPN. Id. Patent Owner contends it was
improper for the rejection to rely on the combination of BinGO UG and
BinGO EFR in order to support an anticipation rejection. Id. at 56–57.

c) Requester’s Contentions
Requester contends the rejection should be affirmed for the reasons
stated in the RAN and the Request, as Patent Owner’s arguments are
substantially the same as those previously of record. Resp’t Br. 14–15.

Appeal 2021-001315
Reexamination Control 95/001,682
Patent 6,502,135 B1

34
d) Analysis
Initially, we are not persuaded by Patent Owner’s contentions that the
rejection improperly relies on the combination of BinGO UG and BinGO
EFR in order to support the anticipation rejection. In support of their
argument, Patent Owner cites to Advanced Display Sys., Inc. v. Kent State
Univ., 212 F.3d 1272, 1282 (Fed. Cir. 2000). Appeal Br. 57. As explained
in Advanced Display, material not explicitly contained in a single document
may still be considered for anticipation if the material is incorporated into
the document. 212 F.3d at 1282. The material must be cited “in a manner
that makes clear that the material is effectively part of the host document as
if it were explicitly contained therein.” Id. In addition, “the host document
must identify with detailed particularity what specific material it
incorporates and clearly indicate where that material is found in the various
documents.” Id. “Whether and to what extent material has been
incorporated by reference into a host document is a question of law.” Id. at
1283.
In this case, BinGO UG discloses “BinTec Documentation,” which
includes the “Extended Feature Reference.” BinGO UG 22. BinGO UG
expressly refers to BinGO EFR in several places for detailed information in
implementing specific functions. See BinGO UG 115, 226, 266, 279. Thus,
we are of the view that BinGO UG incorporates by reference BinGO EFR.
See RAN 37; Req. 3rd Comments 40.
Patent Owner’s contention that BinGO UG bears a later date (March
1999) than BinGO EFR (February 1999) is not persuasive, as the earlier date
in BinGO EFR is consistent with the proposition that in order for the host
document to incorporate another document by reference, the incorporated
Appeal 2021-001315
Reexamination Control 95/001,682
Patent 6,502,135 B1

35
document must have an earlier date than the host document. See Advanced
Display, 212 F.3d at 1282–83 (citing National Latex Prods. Co. v. Sun
Rubber Co., 274 F.2d 224, 230 (6th Cir. 1959) (requiring a specific
reference to material in an earlier application in order have that material
considered part of a later application)).
We are not persuaded by Patent Owner’s argument that BinGO fails
to disclose the “determining” step in claim 10, because Patent Owner’s
argument is not commensurate in scope with the claim. That is, Patent
Owner’s contention is based on the position that the “BinGO! router plays
no role in deciding where a DNS request is seeking access.” Appeal Br. 55.
However, claim 10 does not assign the determining step to a particular
component or function therein. That is, claim 10 recites that the DNS proxy
server returns an IP address for the requested domain name “if it is
determined” access to a non-secure web site has been requested. Similarly,
claim 10 recites that the DNS proxy server generates a request to create a
VPN between the client computer and secure target computer “if it is
determined” access to a secure web site has been requested. Thus, whether
the BinGO! router plays a role in deciding where a DNS request is seeking
access is not relevant to claim 10.
We are also not persuaded by Patent Owner’s argument that
LMHOSTS does not perform DNS resolution. Appeal Br. 56. BinGO UG
expressly discloses: “In the LMHOSTS file, IP addresses are arranged with
their computer names in tabular form. If, for example, you are looking for
BossPC, . . . your PC asks its LMHOSTS file for the corresponding IP
address and in this way is able to find the PC.” BinGO UG 61. Patent
Owner has not sufficiently explained why this name resolution process does
Appeal 2021-001315
Reexamination Control 95/001,682
Patent 6,502,135 B1

36
not equate to the DNS resolution process at the level of particularity recited
in the claim. See Claim 10 (“[T]he DNS proxy server returns the IP address
for the requested domain name.”).
To the extent Patent Owner’s argument is that the processes in BinGO
would not distinguish between a secure and non-secure target computer, we
are not persuaded, because BinGO expressly discloses connections for
“usual internet services” as well as secure connections to a head office. See
BinGO UG 18.
In addition, BinGO also discloses that in situations where the request
from a client computer is a secure target computer, the BinGO! router
creates a VPN between the client computer and the target computer. That is,
BinGO discloses the BinGO! router sets up a VPN using PPTP (Point to
Point Tunneling Protocol) in order to provide access for field service staff
via an internet and laptop to a company network. BinGO 226.
As a result, we affirm the Examiner’s rejection of claim 10 as
anticipated by BinGO.
2. Claim 12
Claim 12 depends from claim 10, and further recites that “the
gatekeeper computer determines whether the client computer has sufficient
security privileges to create the VPN and, if the client computer lacks
sufficient security privileges, rejecting the request to create the VPN.”
The Examiner found the BinGO! router discloses requiring
authentication before establishing connections to a remote server, by
disclosing checking incoming data to decide whether the connection should
be allowed, such that acceptance of the call takes place only after correct
authentication. Request Exh. C6, citing BinGO UG 269. The Examiner
Appeal 2021-001315
Reexamination Control 95/001,682
Patent 6,502,135 B1

37
found BinGO discloses personal authentication and thus discloses the
BinGO! router (as the gatekeeper computer) will determine if the client
computer has sufficient security privileges to create the VPN and if not, will
reject the request to create the VPN. Id. citing BinGO UG 77, 114, 145,
149, 154–156, 182, 190–192, 242–243, and 263; BinGO EFR at 76–77, 84–
85, 88–91, 93, 95 and 97.
Patent Owner contends the BinGO! router, when checking incoming
data, is authenticating the target computer, and does not disclose
authenticating its own client computer. Appeal Br. 57–58.
The Examiner incorporates by reference Requester’s comments
regarding BinGO. RAN 37, citing Req. 3rd Comments 37–45. Requester
relies on the rejections as set forth in the Request and contends Patent
Owner’s arguments in the Appeal Brief are substantially the same as those
responded to in the Comments relied upon by the Examiner. See Resp’t Br.
14–15.
We are not persuaded by Patent Owner’s arguments, because as
Requester points out, in BinGO, when a user makes a request to the BinGO!
router and that request is for a secure connection through a VPN,
authentication of the initiating partner is performed via PAP, CHAP, or MS-
CHAP. BinGO EFR 84. As such, if the authentication fails, the BinGO!
router would reject the request consistent with the very purpose of
performing an authentication.

Appeal 2021-001315
Reexamination Control 95/001,682
Patent 6,502,135 B1

38
3. Claim 13
a) The Examiner’s Findings
Although the Request relies on BinGO’s disclosure of local name and
common password information, which is also known by a WAN partner and
stored on the BinGO! router (the central computer), as the authentication
tables (see Request, Exh. C6, 30), the Examiner found that it is the use of
PAP, CHAP, and MS-CHAP protocols that correspond to the authentication
tables recited in claim 13. Req. 3rd Comments 43–44, citing BinGO EFR
84. The Examiner found that such authentication protocols require the
BinGO! router as the authenticating device to store user/password
combinations in an authentication table, and to use tables to authenticate
requests from clients. Id.
b) Patent Owner’s Contentions
Regarding claim 13, Patent Owner argues that BinGO does not
disclose a central computer that maintains a plurality of authentication tables
as recited therein. Appeal Br. 58–59. Patent Owner contends there is
insufficient explanation as to how the use of PAP, CHAP, and MS-CHAP
protocols in BinGO necessarily require a central computer that maintains a
plurality of authentication tables. Id. Patent Owner contends that BinGO’s
disclosure of checking incoming calls does not constitute determining that
the request is from an authorized client or allocating resources to establish a
VPN, because BinGO does not disclose a BinGO! router that authenticates
its own client. Id. at 59. In addition, Patent Owner contends the rejection
relies on BinGO EFR for this feature, which is an additional reference that
cannot be combined with BinGO UG in an anticipation rejection. Id.; see id.
Appeal 2021-001315
Reexamination Control 95/001,682
Patent 6,502,135 B1

39
at 56–57. Patent Owner argues that BinGO does not disclose any virtual
private link or encrypted communications. Id.
c) Requester’s Contentions
The Examiner incorporates by reference Requester’s comments
regarding BinGO. RAN 37, citing Req. 3rd Comments 37–45. Requester
relies on the rejections as set forth in the Request and contends Patent
Owner’s arguments in the Appeal Brief are substantially the same as those
responded to in the Comments relied upon by the Examiner. See Resp’t Br.
14–15.
d) Analysis
Initially, we have already addressed the rejection’s reliance on the
combination of BinGO UG and BinGO EFR above with respect to claim 10.
We are not persuaded by Patent Owner’s argument that BinGO does not
disclose a central computer with authentication tables. Claim 13 recites the
central computer receives a request from a client computer to establish a
connection, and requires a determination that the request is from an
authorized client.
In BinGO, when a user makes a request to the BinGO! router and that
request is for a secure connection through a VPN, authentication of the
initiating partner is performed via PAP, CHAP, or MS-CHAP. BinGO EFR
84. As discussed above with respect to Wang, we do not discern a
distinction between the “authentication tables” recited in claim 13 and such a
disclosure as in BinGO. Once this authentication has taken place, the
BinGO! router can set up a VPN (allocate resources) between the client and
second computer. BinGO UG 226.
Appeal 2021-001315
Reexamination Control 95/001,682
Patent 6,502,135 B1

40
Accordingly, we affirm the Examiner’s rejection of claim 13 as
anticipated by BinGO.
4. Claims 14 and 15
Claim 14 depends from claim 13 and recites “wherein step (4)
comprises the step of communicating according to a scheme by which at
least one field in a series of data packets is periodically changed according to
a known sequence.”
In adopting the rejections set forth in the Request, the Examiner found
the BinGO! router “can be configured to implement a variety of Network
Address Translation (NAT) schemes.” Request 212, Exh. C6, 33. The
Examiner found “NAT schemes inherently function by changing at least one
field in a series of data packets periodically according to a known sequence.”
Id. The Examiner relied on an additional reference, RFC 2663, as
“representative of what was publicly known about NAT schemes.” Id.; see
Resp’t Br. Exh. Y17. The Examiner found RFC 2663 discloses NAT
devices provide a transparent routing solution to end hosts by modifying end
node addresses en-route. Id. citing RFC 2663 1. The Examiner found NAT
schemes were known to be useful and compatible with VPNs based on IP
tunneling. Id. citing RFC 2663 21.
Patent Owner contends BinGO does not disclose NAT as being used
in a virtual private link. Appeal Br. 59. Patent Owner contends further that
BinGO does not incorporate by reference RFC 2663, or explain that its use
of NAT complies with RFC 2663. Id. citing BinGO UG 244–49.
Requester contends NAT schemes inherently function by periodically
changing at least one field in a series of data packets according to a
predetermined sequence. Req. 3rd Comments 45, citing Request 212; RAN
Appeal 2021-001315
Reexamination Control 95/001,682
Patent 6,502,135 B1

41
37. Requester contends “[b]ecause the BinGO! router is able to map IP
addresses so that the datagrams are sent to the correct end-point (as opposed
to a random end-point), the sequence of address changes must be known.”
Id. Requester contends that BinGO explicitly discloses it uses NAT, which
is a standard defined in RFC 2663, such that BinGO incorporates RFC 2663
by reference. Id.
We are persuaded by Patent Owner’s argument that BinGO does not
inherently disclose the use of NAT in a manner that necessarily complies
with RFC 2663 by incorporating RFC 2663 by reference. That is, BinGO
has a copyright date of March 1999. BinGO UG 3. RFC 2663 has a date of
August 1999. RFC 2663 1. Thus, BinGO was available prior to RFC 2663,
and cannot have incorporated RFC 2663 by reference. In addition, BinGO
expressly discloses the guidelines and standards to which it adheres, and
RFC 2663 is not listed. BinGO UG 2–3.
To the extent the rejection of claim 14 relies on BinGO itself, we find
no express description that in using NAT, the requirement in claim 14 that
“at least one field in a series of data packets is periodically changed
according to a known sequence” is disclosed therein. BinGO UG 244–249.
Thus, the Examiner’s and Requester’s position that claim 14 is
anticipated by BinGO via the incorporation of RFC 2663 is not sufficiently
supported. Accordingly, we reverse the rejection of claim 14 as anticipated
by BinGO. Because claim 15 depends from claim 14, we reverse the
rejection of claim 15 as well.

Appeal 2021-001315
Reexamination Control 95/001,682
Patent 6,502,135 B1

42
5. Claim 18
a) Patent Owner’s Contentions
Patent Owner contends BinGO does not disclose determining that
access to a secure web site has been requested as recited in claim 18.
Appeal Br. 55, 60. That is, Patent Owner argues BinGO’s disclosures of
querying a local DNS server on a local area network (LAN), querying a
LMHOSTS file, and querying a “default route” in the absence of any
internet service provider (ISP) do not perform the determining step of claim
18. Id. Patent Owner argues that in querying a local DNS server on a LAN
and querying a default route in the absence of any ISP, the BinGO! router
blindly forwards a request to a primary domain name server in accordance
with its “Static Settings.” Id. at 55–56. As a result, Patent Owner contends
the BinGO! router makes no determination as recited in claim 18. Id. at 56.
Patent Owner contends BinGO discloses that the LMHOSTS is an
alternative to setting up a domain name server and operates without asking
for a DNS. Id. Patent Owner contends BinGO does not disclose a request to
create a VPN between the client computer and a secure target computer as
BinGO does not mention encryption or VPNs at all. Id. Patent Owner
contends that the rejection improperly relies on a second reference, BinGO
EFR, which is improper for an anticipation rejection. Id. at 56–57. Patent
Owner contends that the VPN disclosed in BinGO EFR is implemented only
for connecting to the Internet through an ISP, which is the result of a query
requesting a non-secure computer, not for a secure web site as recited in
claim 18. Id. at 57.
In addition, Patent Owner argues BinGO does not disclose that steps
(2) and (3) are performed at a DNS server separate from a client computer as
Appeal 2021-001315
Reexamination Control 95/001,682
Patent 6,502,135 B1

43
recited in claim 18. Appeal Br. 60. In particular, Patent Owner contends the
BinGO! router is not a DNS server, and that a DNS server located on either
a LAN or corporate network does not automatically initiate a VPN. Id. at
60–61. Patent Owner argues also that BinGO does not disclose determining
whether a client computer is authorized to resolve addresses of non secure
target computers, and if not so authorized, returning an error from the DNS
request, and the position that such a step would be inherent in the BinGO!
router is not sufficiently supported. Id. at 61–62.
The Examiner and Requester did not provide any specific responses to
Patent Owner’s contentions.
b) Discussion
BinGO discloses that its BinGO! router is used as a DNS proxy
server. BinGO 87. BinGO discloses the BinGO! router is used to connect to
non-secure sites over the internet, as well as secure sites such as a
company’s head office. See BinGO 15, Fig. 1-1, 18. BinGO discloses that
when the user enters a DNS request for a website (www.bintec.de), if the
destination is unknown to the BinGO! router, it forwards the request to a
further DNS server (provider) for domain name resolution. Id. at 92.
BinGO discloses the IP address is returned to the PC and the PC is
connected to the destination using a default route. Id.
Although in this case, the BinGO! router itself does not perform the
domain name resolution step, claim 18 allows for such a scenario. That is,
claim 18 recites only that that “steps (2) and (3) are performed at a DNS
server separate from the client computer.” Claim 18 does not require a
particular DNS server to perform determining step (2), which allows for the
Appeal 2021-001315
Reexamination Control 95/001,682
Patent 6,502,135 B1

44
BinGO! router acting as a DNS proxy server to forward the request to
another DNS as disclosed in BinGO.
BinGO also discloses that in situations where the request from a client
computer is a secure target computer, the BinGO! router creates a VPN
between the client computer and the target computer. That is, BinGO
disclose the BinGO! router sets up a VPN using PPTP (Point to Point
Tunneling Protocol) in order to provide access for field service staff via an
internet and laptop to a company network. BinGO 226. This also does not
violate the language of claim 18, which again only recites that step (3) is
performed at a DNS server separate from the client computer.
As to determining whether the client computer is authorized to access
non-secure target computers and returning an error message if it determined
the client is not authorized to access non-secure target computers, we
reiterate the issues with claim 18 discussed above. As we discussed above,
BinGO discloses authentication of the initiating partner, which would
include situations where the requested web-site is non-secure. Although it is
true that BinGO does not expressly disclose returning an error message
should the authentication fail, we do not find it credible to argue that one of
ordinary skill in the art would not have immediately understood that such an
authentication failure would result in an error message being returned as
contended by Requester. Req. 3rd Comments 41.

F. Obviousness – Claim 11 – BinGO, Reed (Issue 42)
Claim 11 depends from claim 10, and further recites “wherein the
gatekeeper computer creates the VPN by establishing an IP address hopping
Appeal 2021-001315
Reexamination Control 95/001,682
Patent 6,502,135 B1

45
regime that is used to pseudorandomly change IP addresses in packets
transmitted between the client computer and the secure target computer.”
The Examiner adopted the rejection of claim 11 as proposed by the
Requester. Request 33, Exh. C6, 26; RAN 26. The Examiner found BinGO
does not expressly disclose an IP hopping scheme, but Reed discloses an IP
hopping scheme in the form of an onion-routing scheme that meets the
requirements of the IP address hopping regime recited in claim 11. Request,
Exh. C6, 26–27. The Examiner determined one of ordinary skill in the art
would have been motivated by BinGO to ensure that pathways carrying
sensitive data are shielded from the interception or monitoring and would
have integrated the onion-routing schemes disclosed in Reed into a VPN
solution based on use of BinGO! routers. Id. at 27.
Patent Owner contends Reed is incompatible with direct-dialing in
BinGO, and if Reed is combined with the non-direct dialing in BinGO, there
is no transparent creation of a VPN as recited in claim 10. Appeal Br. 62.
We are not persuaded by Patent Owner’s contentions. As the
Examiner stated, despite Patent Owner’s arguments pointing out differences
between the two references, Patent Owner does not provide a sufficient
explanation as to why the results of the combination would be unsatisfactory
or that the principle of operation would be changed in a manner that would
render the combination inoperable. RAN 38. Although Patent Owner
suggests that the Examiner and Requester now rely on indirect dialing, we
do not find the Examiner’s and Requester’s position to be so limited.
Requester and the Examiner stated only that BinGO does not suggest that a
direct dial is the sole intended purpose of its communication schemes, that
any other method for transporting packets would be unsatisfactory. Id.; Req.
Appeal 2021-001315
Reexamination Control 95/001,682
Patent 6,502,135 B1

46
3rd Comments 45. Patent Owner has not provided a sufficient explanation
to demonstrate error in the rejection’s reasoning that one of ordinary skill in
the art would have applied the onion routing scheme of Reed in a VPN
solution in BinGO in a manner that would have rendered claim 11 obvious.
We affirm the rejection of claim 11 as obvious over BinGO and Reed.

G. Obviousness – Claim 16 – BinGO, Boden (Issue 43)
Claim 16 depends from claim 15, and is rejected over the combination
of BinGO and Boden. Request 33–34; RAN 26. Because Boden does not
rectify the deficiencies discussed above with respect to claim 15 (dependent
from claim 14), we reverse the rejection of claim 16 as obvious over BinGO
and Boden.

H. Obviousness – Claim 17 – BinGO, Weiss
Claim 17 depends from claim 13 and further recites “wherein step (2)
comprises the step of using a checkpoint data structure that maintains
synchronization of a periodically changing parameter known by the central
computer and the client computer to authenticate the client.”
1. The Examiner’s Findings
The Examiner found BinGO discloses BinGO! routers may be
configured to use SecurID token authentication methods. Request, Exh. C6,
36, citing BinGO EFR 56; RAN 26–27. The Examiner found BinGO
discloses a configuration where a checkpoint is included, which is used by
the BinGO! router to implement a SecurID authentication process. Id. citing
BinGO EFR 56. The Examiner found Weiss discloses methods in which
codes are periodically changed according to a pre-defined algorithm and at
Appeal 2021-001315
Reexamination Control 95/001,682
Patent 6,502,135 B1

47
least one dynamic variable. Id. at 36–37, citing Weiss, col. 1, ll. 63–68. The
Examiner found Weiss discloses the method can be used with a mechanism
that synchronizes the codes for use in a method for authenticating users. Id.
at 37, citing Weiss, col. 2, l. 44 – col. 3, l. 27, col. 3, l. 38 – col. 4, l. 29. The
Examiner found Weiss discloses the code is represented in a data structure,
and used by client server computers to perform authentication of a user. Id.
citing Weiss, col. 5, ll. 34–43, col. 6, ll. 9–17, col. 7, ll. 14–32.
The Examiner found the SecurID token system is an example of
periodically changing the token system that is synchronized by the client and
server as taught by Weiss. Id. The Examiner determined that because
BinGO EFR provides specific direction to incorporate token authentication
processes as disclosed in Weiss into the BinGO! router, the additional step
of using a checkpoint data structure that maintains synchronization of a
periodically changing parameter known by the central computer and the
client computer to authenticate the client would have been obvious. See id.
2. Patent Owner’s Position
Patent Owner contends that the Examiner’s reasoning for combining
Weiss and BinGO is not sufficiently supported because the discussion in
BinGO EFR of SecurID features is for a BRICK router and not for the
BinGO! router. Appeal Br. 64. Patent Owner also argues that BinGO UG
and BinGO EFR are not properly combinable for the reasons discussed
above. Id.
3. Requester’s Contentions
The Examiner and Requester maintain that BinGO and Weiss are
properly combinable. RAN 39; Req. 3rd Comments 46; Resp’t Br. 15.
Appeal 2021-001315
Reexamination Control 95/001,682
Patent 6,502,135 B1

48
4. Analysis
As discussed above for claim 13, we are of the view that BinGO UG
incorporates BinGO EFR by reference. We are also not persuaded by Patent
Owner’s contention that the SecurID features disclosed in BinGO EFR are
for a BRICK router and not for the BinGO! router. That is, BinGO EFR
discloses expressly that it is applicable to both BIANCA/BRICK and
BinGO! routers. BinGO EFR “NOTE” on page following cover page.
Thus, we are not persuaded that one of ordinary skill in the art would have
understood the SecurID feature as not applicable to the BinGO! router as
well as the BRICK router.
Accordingly, we affirm the Examiner’s rejection of claim 17 as
obvious over the combination of BinGO and Weiss.

Appeal 2021-001315
Reexamination Control 95/001,682
Patent 6,502,135 B1

49

IV. CONCLUSION
In summary, the status of the Adopted Rejections is as follows:
Claim(s)
Rejected
35 U.S.C.
§
Reference(s)/Basis Affirmed Reversed
10, 12–
14
102(a) Aventail Connect
v3.1
10, 12–14
10, 12–
14
102(b) Aventail Connect
v3.01
10, 12–14
10, 12,
13
102(b) AutoSOCKS 10, 12, 13
11 103(a) Aventail Connect
v3.1, Reed
11
11 103(a) Aventail Connect
v3.01, Reed
11
11, 14,
15
103(a) AutoSOCKS, Reed 11, 14, 15
16 103(a) Aventail Connect
v3.1, Boden
16
16 103(a) Aventail Connect
v3.01, Boden
16
16 103(a) AutoSOCKS,
Reed, Boden
16
17 103(a) Aventail Connect
v3.1, Weiss
17
17 103(a) Aventail Connect
v3.01, Weiss
17
17 103(a) AutoSOCKS,
Weiss
17
10, 12,
13, 18
102(a) Wang 13 10, 12, 18
11, 14,
15
103(a) Wang, Reed 14 11, 15
16 103(a) Wang, Reed,
Boden
16
17 103(a) Wang, Weiss 17
Appeal 2021-001315
Reexamination Control 95/001,682
Patent 6,502,135 B1

50

In accordance with 37 C.F.R. § 41.79(a)(1), the “[p]arties to the
appeal may file a request for rehearing of the decision within one month of
the date of: . . . [t]he original decision of the Board under § 41.77(a).” A
request for rehearing must be in compliance with 37 C.F.R. § 41.79(b).
Comments in opposition to the request and additional requests for rehearing
must be in accordance with 37 C.F.R. § 41.79(c) & (d), respectively. Under
37 C.F.R. § 41.79(e), the times for requesting rehearing under paragraph (a)
of this section, for requesting further rehearing under paragraph (d) of this
section, and for submitting comments under paragraph (c) of this section
may not be extended.
An appeal to the United States Court of Appeals for the Federal
Circuit under 35 U.S.C. §§ 141–144 and 315 and 37 C.F.R. § 1.983 for an
inter partes reexamination proceeding “commenced” on or after November
2, 2002 may not be taken “until all parties’ rights to request rehearing have
been exhausted, at which time the decision of the Board is final and
10, 12,
13, 18
103(a) Beser, Kent 10, 12, 13,
18
18 103(a) Beser, Kent, Blum 18
18 103(a) Beser, Kent,
AutoSOCKS
18
11 103(a) Beser, Kent, Reed 11
10, 12–
15, 18
102(a) BinGO 10, 12, 13,
18
14, 15
11 103(a) BinGO, Reed 11
16 103(a) BinGO, Borden 16
17 103(a) BinGO, Weiss 17
Overall
Outcome
10–14, 17,
18
15, 16
Appeal 2021-001315
Reexamination Control 95/001,682
Patent 6,502,135 B1

51
appealable by any party to the appeal to the Board.” 37 C.F.R. § 41.81. See
also MPEP § 2682 (8th ed., Rev. 7, July 2008).

AFFIRMED IN PART

Appeal 2021-001315
Reexamination Control 95/001,682
Patent 6,502,135 B1

52

PATENT OWNER:

PAUL HASTINGS LLP
2050 M. Street NW
Washington DC 20036

THIRD PARTY REQUESTER:

SIDLEY AUSTIN LLP
2021 McKinney Avenue
Suite 2000
Dallas, TX 75201