Ex Parte 8051181 et al

Patent Trial and Appeal Board

Sep 29, 2015

95001949 (P.T.A.B. Sep. 29, 2015)

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,949 03/28/2012 8051181 41484-80200 4522
22852 7590 09/29/2015
FINNEGAN, HENDERSON, FARABOW, GARRETT & DUNNER
LLP
901 NEW YORK AVENUE, NW
WASHINGTON, DC 20001-4413
EXAMINER
BONSHOCK, DENNIS G
ART UNIT PAPER NUMBER
3992
MAIL DATE DELIVERY MODE
09/29/2015 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.

VIRNETX INC.,
Owner

____________________

Appeal 2015-004512
Reexamination Control 95/001,949
Patent 8,051,181 B2
Technology Center 3900
____________________

Before JEFFREY B. ROBERTSON, DENISE M. POTHIER, and
JEREMY J. CURCURI, Administrative Patent Judges.

POTHIER, Administrative Patent Judge.

DECISION ON APPEAL

Appeal 2015-004512
Control 95/001,949
Patent 8,051,181 B2

2
I. STATEMENT OF CASE
Apple, Inc., requested inter partes reexamination of U.S. Patent No.
8,051,181 B2 (“the ’181 patent”) issued to Victor Larson, Robert Dunham Short,
III, Edmund Colby Munger, and Michael Williamson, entitled Method for
Establishing Secure Communication Link Between Computers of Virtual Private
Network. The ’181 patent issued November 1, 2011 and is assigned to VirnetX
Incorporated.
Owner appeals from the decision in the RAN, rejecting claims 1–29 of the
’181 patent. App. Br. viii; RAN 1.1 Requester filed a Respondent Brief, and
Owner filed a Rebuttal Brief. See generally Resp. Br. and Reb. Br.
The Examiner’s Answer relies solely on the RAN, incorporating it by
reference. See Ans. 1.
We have been informed of two related inter partes reexamination
proceedings, Control Nos. 95/001,746 and 95/001,792, involving “the Munger
Family.”2 App. Br. vi. Control No. 95/001,746 has been appealed to the Patent
Trial and Appeal Board (“the Board.”) A decision was rendered by the Board for
Control No. 95/001,792 on April 1, 2014 (Appeal No. 2014-000591). We also
have been informed of numerous Inter Partes Reviews and judicial proceedings
related to the ’181 patent. App. Br. vi–viii; Resp. Br. iv, Related Proceedings
App’x.

1 Throughout this opinion, we refer to the Appeal Brief (App. Br.) filed March 14,
2014; (2) the Respondent Brief (Resp. Br.) filed April 24, 2014; (3) the Examiner’s
Answer (Ans.) mailed July 15, 2014; (4) the Rebuttal Brief (Reb. Br.) filed August
15, 2014; (5) the Examiner’s Right of Appeal Notice (RAN) mailed August 16,
2013, and (6) the Action Closing Prosecution (ACP) mailed January 16, 2013.
2 Owner indicates the “‘Munger family,’ refers to the family of patents or patent
applications related to the ’181 patent.” App. Br. vi n. 1.
Appeal 2015-004512
Control 95/001,949
Patent 8,051,181 B2

3
We have jurisdiction under 35 U.S.C. §§ 134(b) and 315.
An oral hearing was conducted on September 11, 2015.
We AFFIRM the Examiner’s decision to reject claims 1–29.
Illustrative original claims 1 and 2 read as follows:   
1. A non-transitory machine-readable medium comprising instructions for a
method of communicating with a first device associated with a secure name
and an unsecured name, the method comprising:
receiving, at a network address corresponding to the secure name
associated with the first device, a message from a second device of the
desired to securely communicate with the first device; and
sending a message over a secure communication link from the first
device to the second device.

2. A method of using a first device to communicate with a second device
having a secure name, the method comprising:
from the first device, sending a message to a secure name service, the
message requesting a network address associated with the secure name of
the second device;
at the first device, receiving a message containing the network address
associated with the secure name of the second device; and
from the first device, sending a message to the network address
associated with the secure name of the second device using a secure
communication link.

App. Br., Claims App’x.
A. Prior Art Relied Upon
The Examiner relies on the following as evidence of unpatentability:
Mattaway US 6,131,121 Oct. 10, 2000
Beser US 6,496,867 B1 Dec. 17, 2002
Johnson US 6,499,108 B1 Dec. 24, 2002
Provino US 6,557,037 B1 Apr. 29, 2003

P. Mockapetris, Request for Comments 1034, Domain Names – Concepts and
Facilities (November 1987) (“RFC 1034”)
Appeal 2015-004512
Control 95/001,949
Patent 8,051,181 B2

4

Rolf Lendenmann et al., Understanding OSF DCE 1.1 for AIX and OS/2 (October
1995) (“Lendenmann”)

R. Droms, Request for Comments 2131, Dynamic Host Configuration Protocol
(March 1997) (“RFC 2131”)

ITU-T H.225.0, Call Signalling [sic] Protocols and Media Stream Packetization
for Packet-Based Multimedia Communications Systems (February
1998) (“H.225”)

ITU-T H.245, Control Protocol for Multimedia Communication (February 1998)
(“H.245”)

ITU-T H.323, Packet-Based Multimedia Communications Systems (February
1998) (“H.323”)

ITU-T H.235, Security and Encryption for H-Series (H.323 and other H.245-
based) Multimedia Terminals (November 1998) (“H.235”)

S. Kent, Request for Comments 2401, Security Architecture for the Internet
Protocol (November 1998) (“RFC 2401”)

B. Adopted Rejections
The Examiner maintains the following rejections:

Reference(s) Basis Claims RAN
Beser § 102(e) 1–12, 14, 15, 17–29 4
Mattaway § 102(e)
1, 2, 7–9,
12–17, 19–21,
24–29
5
Mattaway and Beser § 103(a) 3, 4, 10, 11, 18, 23 5–6
Mattaway and RFC 2401 § 103(a) 10, 11 6
Appeal 2015-004512
Control 95/001,949
Patent 8,051,181 B2

5
Lendenmann § 102(b) 1–9, 12–15, 18–29 6
Lendenmann and Beser § 103(a) 10, 11, 17 6–7
Lendenmann and RFC
2401 § 103(a) 10, 11 7
Provino § 102(e) 1–15, 18–23, 28, 29 7–10
Provino and H.323 § 103(a) 24–26 10
H.323 § 102(b) 1–29 10–11
Johnson, RFC 2131, RFC
1034, and RFC 2401 § 103(a) 1–16, 18–29 11–12

App. Br. 3.

II. ISSUES ON APPEAL
We review the appealed rejections for error based upon the issues identified
by Owner, and in light of the arguments and evidence produced thereon. Cf. Ex
parte Frye, 94 USPQ2d 1072, 1075 (BPAI 2010) (precedential) (citing In re
Oetiker, 977 F.2d 1443, 1445 (Fed. Cir. 1992)). “Any arguments or authorities not
included in the briefs permitted under this section or [37 C.F.R.] §§ 41.68 and
41.71 will be refused consideration by the Board, unless good cause is shown.” 37
C.F.R. § 41.67(c)(1)(vii).
Based on the disputed errors presented by Owner, the main issues on appeal
are whether the Examiner erred in finding the cited prior art discloses or teaches:
(1) “a first device associated with a secure name and an unsecured name”
recited in independent claim 1 and similarly in independent claim 26?
(2) receiving a message from a second device “at a network address
corresponding to the secure name associated with the first device” as recited in
Appeal 2015-004512
Control 95/001,949
Patent 8,051,181 B2

6
claim 1, “sending a message to a secure name service, the message requesting a
network address associated with the secure name of the second device” from the
first device as recited in claim 2, and similarly in other claims?
(3) “sending a message over a secure communication link” as recited in
claim 1, “sending a message to the network address associated with the secure
name of the second device using a secure communication link” as recited in claim
2, or similarly recited in other claims?

III. ANALYSIS
A. Claim Construction
Owner and Requester disagree on how terms in the claims on appeal should
be construed. App. Br. 11, 15 and Resp. Br. 2, 4. During examination of a patent
application, a claim is given its broadest reasonable construction “in light of the
specification as it would be interpreted by one of ordinary skill in the art.” In re
Am. Acad. of Sci. Tech Ctr., 367 F.3d 1359, 1364 (Fed. Cir. 2004) (internal
citations and quotations omitted). We presume that claim terms have their
ordinary and customary meaning. See In re Translogic Tech., Inc., 504 F.3d 1249,
1257 (Fed. Cir. 2007) (internal quotations omitted) (“The ordinary and customary
meaning is the meaning that the term would have to a person of ordinary skill in
the art in question.”). However, patentees may rebut this presumption by acting as
their own lexicographer, providing a definition of the term in the specification with
“reasonable clarity, deliberateness, and precision.” In re Paulsen, 30 F.3d 1475,
1480 (Fed. Cir. 1994).
Appeal 2015-004512
Control 95/001,949
Patent 8,051,181 B2

7
1. A Secure Name
All independent claims recite “a secure name.” Owner contends that a
secure name in the disclosure of the ’181 patent “is a name used to communicate
securely that is resolved by a secure name service (i.e., a service that both resolves
a name into a network address and further supports establishing a secure
communication link).” App. Br. 11. For support, Owner cites to column 50, lines
60 through 67 of the disclosure of the ’181 patent. This passage of the ’181 patent
discusses a secure domain name service (SDNS) (e.g., 3313) that can register and
contain secure domain names in a cross-reference database, such as storing a
computer network address corresponding to the secure domain name, and resolves
this translation using the service. The ’181 patent 50:60–67; Fig. 33. However,
this passage does not discuss or explain what a secure name itself is. Id.
Similarly, the Declaration of Dr. Angelos D. Keromytis (“the Keromytis
declaration”) discusses an understanding of a “secure name service” in context of
claim 2 and how one of ordinarily skill in the art would have understood this
service, but there is no discussion of the recited phrase, “a secure name.” App. Br.
11 (citing Keromytis Decl. ¶ 66). Although the Supplemental Declaration of Dr.
Angelos D. Keromytis (“the supplemental Keromytis declaration”) discusses his
understanding of “a secure name” in the context of Mattaway to include “those
names used to communicate securely that are resolved by a secure name service,”
no underlying support for his understanding has been provided. Id. at 22 (citing
Supp. Keromytis Decl. ¶ 10). As such, Owner has not provided persuasive
evidence that “a secure name” requires resolution by a secure name service that
both resolves a name into a network address and further supports establishing a
Appeal 2015-004512
Control 95/001,949
Patent 8,051,181 B2

8
secure communication link. App. Br. 11. Even so, as explained below, the prior
art satisfies this narrow construction.
Turning to other portions of the ’181 patent, the Specification describes one
embodiment of a “top-level domain name.” The ’181 patent 50:9–16; Fig. 33. For
example, the disclosure states software module 3309 replaces the .com top-level
domain name for server 3304 with a .scom top-level domain name, “where the ‘s’
stands for secure.” Id. at 50:12–16; Fig. 33. Yet, this discussion in the ’181 patent
is only an example of a secure name. The Specification merely discloses an
example in which a secure domain name server (SDNS) is used to obtain a
Uniform Resource Locator (URL) for a secure domain name. Id. at 50:22-25; Fig.
33.
The ’181 patent further states “any other non-standard top-level domain
name” can be used to replace the top-level domain name of server 3304. Id. at
50:16–18. Accordingly, consistent with the disclosure, “a secure name” includes
non-standard top-level domain names. The ’181 patent also discusses other “non-
standard” domain names (e.g., .sorg, .snet, .sedu). The ’181 patent 7:34–37. Yet,
these are just further examples of non-standard names with neither passage
explaining or defining what “non-standard” means. See the ’181 patent 6:34–37,
50:16–18. Furthermore, Requester indicates Owner has on at least one occasion
indicated a secure name can be a telephone number. See Resp. Br. 8 (citing RAN
28, which further cites to ACP 32).
Because the ’181 patent does not define “non-standard top-level domain
name,” we construe the phrase “secure name” broadly, but reasonably.
Accordingly, when considering the phrase, “secure name” in light of the ’181
Appeal 2015-004512
Control 95/001,949
Patent 8,051,181 B2

9
patent’s disclosure, we find the phrase includes a name that connotes a level of
security, including corresponding to a secure computer network address.
2. An Unsecured Name
Claims 1 and 26 recite “an unsecured name.” Owner contends this term
“does not require resolution by a secure name service.” App. Br. 11 (citing the
’181 patent 40:33–36, 51:55–57, 52:11–58; Figs. 26–27). Once again, this
understanding and cited passages do not address what an unsecured name is, but
rather focus on how a name is resolved by service and establishing a “non-VPN
communication link,” which is not recited in the claims. App. Br., Claims App’x.
Owner also refers to the Keromytis declaration and supplemental Keromytis
declaration to support its understanding of “an unsecured name.” App. Br. 11
(citing Keromytis Decl. ¶ 66 and Supp. Keromytis Decl. ¶ 10). These paragraphs
in the declarations do not discuss “an unsecured name” as recited and provide
insufficient support for Owner’s understanding. Based on the above discussions of
“a secure name,” we determine an “an unsecured name” includes a name that does
not connote a level of security, including corresponding to an unsecure computer
network address.
3. A Secure Communication Link
Independent claims 1, 2, and 28 recite “a secure communication link.”
Owner contends that “[t]he broadest reasonable interpretation of the recited secure
communication link requires encryption[.]” App. Br. 15 (citing the ’181 patent
1:50–57, 9:57–58, 11:5–7, 50:1–3 and Keromytis Decl. ¶ 27). Although the ’181
patent discusses encryption in the context of data security (the ’181 patent 1:50–
57), the disclosure states “[d]ata security is usually tackled using some form of
data encryption” (id. at 1:50–51 (italics added)) and also states “[a] tremendous
Appeal 2015-004512
Control 95/001,949
Patent 8,051,181 B2

10
variety of methods have been proposed and implemented to provide security . . . .”
(id. at 1:28–29). See also Keromytis Decl. ¶ 27 (quoting the above passage). Also,
at least one other passage in the ’181 patent does not limit a secure communication
link to encryption. The ’181 patent 50:1–3. The Federal Circuit further examined
similar passages in a related patent3 when differentiating security from encryption.
Cisco, 767 F.3d at 1323. Specifically, the court found “that encryption is a
narrower, more specific requirement than security.” Id.; see id. at 1317-18.
Owner further refers to two exhibits, Defendant’s Responsive Claim
Construction Brief and Defendants’ Motion For Reconsideration of the
Construction of the Term “Secure Communication Link,” filed by Requester in
district court. App. Br. 15 (citing App. Br., Evidence App’x, Ex. A-2, pp. 2-4, 10-
11 and App. Br., Evidence App’x, Ex. A-9, p. 1). In these papers, Requester urges
the court to construe the phrase “secure communication link” to include a
communication link that provides data security through encryption and is a virtual
private network (VPN) communication link, which requires anonymity. See App.
Br., Evidence App’x, Ex. A-2, pp. 4, 10-11 and App. Br., Evidence App’x, Ex. A-
9, p. 1. We are not persuaded.
First, as stated above, we are not persuaded that a secure communication
link requires encryption. Second, the Federal Circuit similarly discusses in the
context of the related ’504 patent several instances of its disclosure using the terms
“secure communication link” and “VPN” interchangeably in finding a secure
communication link provides both data security and anonymity. Cisco, 767 F.3d at
1318. Admittedly, the ’181 patent has similar passages (the ’181 patent 51:64–

3 The related patent discussed in VirnetX, Inc. v. Cisco Systems, Inc., 767 F.3d
1308, 1317-19 (Fed. Circ. 2014) is US 7,418,504 (“the ’504 patent.”)
Appeal 2015-004512
Control 95/001,949
Patent 8,051,181 B2

11
52:1, 52:7–11, and Abstract), but neither Owner nor Requester have advocated in
this proceeding that a secure communication requires both security and anonymity.
Moreover, given that this proceeding is under a different posture than the courts
and giving the broadest reasonable construction that we can employ, we are not
bound by a court’s claim construction. See In re Rambus, 694 F.3d 42, 46 (Fed.
Cir. 2012). Third, even presuming we are bound by such a construction, the court
in Cisco additionally found that physical security beyond that of a VPN server,
such as that of a private network, can establish a secure and anonymous path. See
Cisco, 767 F.3d at 1322
Using the broadest reasonable construction in light of the disclosure, security
as well as “a secure communication link” may include but does not require
encryption. Additionally, as discussed above, a secure communication link can be
created by anonymity or a physical security. The Examiner further found that a
communication link that offers encryption as well as a mechanism for hiding
information (e.g., Internet Protocol (IP) addresses) is a type of secure
communication link. RAN 19. The ’181 patent support the Examiner’s position
when discussing a VPN communication link (e.g., a type of secure communication
link) includes various techniques, such as an IP address hopping regime that
changes IP addresses in packets. The ’181 patent 50:42–56.
Accordingly, a “secure communication link,” in independent claims 1, 2,
and 28 is a transmission path that restricts access to information on its path using
one or more of various techniques, including obfuscation methods that hide the
information on the path, such as, encryption, address hopping, and authentication.

Appeal 2015-004512
Control 95/001,949
Patent 8,051,181 B2

12
B. The Rejections
1. Beser
Claims 1-12, 14, 15, and 17-29 have been rejected under 35 U.S.C. § 102(e)
based on Beser. RAN 4 (citing Request 23–65 and Exhibit C-1). Owner presents
many arguments concerning this rejection, including the alleged, proper
construction of certain terms discussed above in the Claim Construction section.
App. Br. 6–20; Reb. Br. 1–8. For previously discussed reasons, we are
unpersuaded.
As to the other contentions, Beser discloses a method for initiating a
tunneling association between ends in a data network. Beser, Abstract; Fig. 1.
Figure 1 of Beser follows:

The above Figure 1 in Beser shows an exemplary data network 10, which includes
a public network 12, first and second network devices 14 and 16 (e.g., routers or
gateways), one or more private network(s) 20, trusted-third-party device 30 (e.g., a
Appeal 2015-004512
Control 95/001,949
Patent 8,051,181 B2

13
domain name server), and network devices 24 and 26 (e.g., telephony devices) that
are originating and terminating ends of the data flow. Beser 3:60–4:11, 4:43–47;
Fig. 1. Beser also includes flow diagrams illustrating the method for initiating the
tunneling or Voice-over-Internet-Protocol (VoIP) association between an
originating end and a terminating end. Beser 3:27–30, 7:62–64; Figs. 4–5.
Owner contends that the Examiner erred in mapping two separate devices in
Beser (e.g., 14/24 and 16/26) to the recited first and second devices in claims 1 and
2. App. Br. 7–8; Reb. Br. 1–2. Specifically, Owner argues that incorporating or
collapsing certain network device (e.g., element 14 described as an edge router or
gateway) in Beser with another network device (e.g., element 24 described as
telephony or multimedia device) in Beser would render the tunneling function
ineffective. App. Br. 7 (citing Supp. Keromytis Decl. ¶ 6). We are not persuaded.
Notably, the rejection does not propose physically incorporating Beser’s
network device 14 (or 16) with network device 24 (or 26) into a single device as
Owner urges. RAN 4, 15, 17 (citing to Request 24–25 and Claim Chart C-1, p. 1).
Rather, the rejection proposes mapping either Beser’s device 24 or 26 in Figure 1
alone or in combination with devices 14 or 16 to the first device or second device
as recited in claims 1 and 2. Id.; Resp. Br. 1 (citing to RAN 15, 17 (where the
Examiner agrees with Requester’s position that “‘[n]othing in the claims preclude a
‘device’ from being an edge router, a communication device or both working in
conjunction.’”) Given that there is no physical incorporation of the components in
Beser, we are not persuaded that the tunneling function is rendered inoperative or
eliminated as Owner urges. See App. Br. 7–8 (citing Supp. Keromytis Decl.
¶ 6).
Appeal 2015-004512
Control 95/001,949
Patent 8,051,181 B2

14
Furthermore, the Examiner’s position is not inconsistent with the ’181
patent’s disclosure. As noted by Requester (Resp. Br. 2 (citing the ’181 patent
51:15–29; Fig. 28)), the ’181 patent discusses a first device associated with a
secure name and unsecure name (e.g., secure and top-level domain names) include,
in one embodiment, both a secure server computer (e.g., 3320) and a separate,
distinct server computer (e.g., 3304), which has non-VPN communication link
capability. The ’181 patent 50:7–18, 51:22–26; Fig. 33. As such, even Owner
contemplates embodiments where the first device that is associated with both a
secure name and an unsecured name includes more than one element or structure.
See id. We further note that courts have “repeatedly emphasized that an indefinite
article ‘a’ or ‘an’ in patent parlance carries the meaning of ‘one or more’ in open-
ended claims containing the transitional phrase ‘comprising.’” KCJ Corp. v.
Kinetic Concepts, Inc., 223 F.3d 1351, 1356 (Fed. Cir. 2000). For the above
reasons, we are not persuaded that the Examiner erred in mapping more than one
structure to the claimed first and second devices or misapplied the law of
anticipation..
Owner contends that there are nine possible combination of components in
Beser that correspond to the first and second device as recited and the Examiner
has not explained how Beser anticipates each of these nine combinations. App.
Br. 9–10. We agree with Requester that in order to anticipate the claims the
rejection need only explain how one embodiment in Beser discloses the recited
elements. Resp. Br. 3.
Owner also argues that the Examiner has changed his position related to
what in Beser is the recited secure name, contending during the proceeding, the
Examiner has changed between a private IP address when packetized and a unique
Appeal 2015-004512
Control 95/001,949
Patent 8,051,181 B2

15
identifier of the telephony device 26. App. Br. 10–11 (citing RAN 12, Req. 25–
26). Owner further argues that Beser does not disclose a first device associated
with a secure name and an unsecured name as recited in claim 1. App. Br. 10–11;
Reb. Br. 3.
Requester states that the Examiner has not changed the position that the
unique identifier of a telephony device (e.g., 26) in Beser is the recited “secure
name.” Resp. Br. 3–4. We agree. The Examiner adopted the position of the
Requester in the RAN. RAN 4 (citing to Request 25 (further citing to Beser
10:37–41 and discussing the secure name is “a ‘unique identifier’ that is registered
with the trusted-third-party device (30)”), 16 (citing Beser 11:25–32). As such, the
Examiner has maintained that the unique identifier of telephony device 26 is a
secure name as recited. Moreover, Beser discloses that the unique identifier can be
a dial-up number, an electronic mail address, a domain name, and even a
previously assigned public IP address. Beser 10:37–41, 10:67 –11:3. As such, the
unique identifier in Beser is a name.
Concerning whether Beser’s unique identifier is a secure name, the
Examiner explains that Beser further discloses a device, such as telephony device
24 in Figure 1, which sends a message requesting a connection with another device
(e.g., telephony device 26) using a trusted third network device (e.g., 30) to
authenticate the request and negotiate a tunneling association for the devices (e.g.,
24 and 26). RAN 12, 14, 16 (citing Beser 9:64-66, 11:25–12:19; Fig. 6).
Specifically, network device 30 has a database that includes an IP address for a
network device (e.g., 16 or 26) and associates these addresses with the unique
identifier at step 116 or equivalent step 106. Beser 9:6-8, 11:26–29, 45–55; Figs.
4–5. After which at step 118 or equivalent 108, first private IP addresses on
Appeal 2015-004512
Control 95/001,949
Patent 8,051,181 B2

16
related devices (e.g., 14 and 16) are negotiated and assigned to a telephony device
(e.g., 24 and 26) without the private addresses for the ends of the association
appearing in the packet address fields. Beser 9:26–28, 46–49, 11:59–12:19; Fig. 5.
That is, the identities of the terminating devices (e.g., 24 and 26) are hidden on the
public network, ensuring anonymity. Beser Abstract, 12:13–19, 11:63–65. As
such, the unique identifier is a name used to create and connote a level of security.
Additionally, Beser also states the IP packets may require encryption or
authentication to ensure the unique identifier cannot be read on the public network.
Beser 11:22–25. This further connotes a level of security for the transmitted
packet, which contains the unique identifier in Beser. Owner contends that adding
a security feature, such as encryption, does not transform a name into a secure
name. App. Br. 11-12. Yet, Owner also argues that a secure communication link
requires encryption. App. Br. 15. Moreover, the example in the ’181 patent where
the secure name has not been encrypted is just one example of a secure name, but
this example does not disclaim encrypted names as unsecure. App. Br. 12 (citing
the ’181 patent 51:30–32).
Moreover, contrary to Owner’s contention (App. Br. 16) and even though
not required to be “a secure name” as discussed above, Beser also uses public IP
addresses for device 16 on public network 12 to route packets after the tunnel is
formed. Beser 20:6–13, 22:8–22, 44–48. Thus, the packets having unique
identifiers are encrypted even after the tunnel has formed. See id. We thus
determine that encrypting a packet that contains the unique identifier would add a
level of security to the unique identifier itself, forming “a secure name.”
We further disagree that the Examiner has mapped the unique identifier to
both the secure name and the unsecure name. Reb. Br. 3 (citing RAN 12). Rather,
Appeal 2015-004512
Control 95/001,949
Patent 8,051,181 B2

17
as explained above, the unique identifier in Beser is the secure name, and the
public IP address of a network device (e.g., 16), which is associated with telephony
device 26 and is a component of the first device as broadly as recited, is the
“unsecured name” of the first device. See RAN 4 (citing to the Request 23–65);
Request 27. We therefore disagree with Owner that the Examiner erred in relying
on both elements 16 and 26 in Beser to disclose a “first device associated with a
secure name and an unsecured name.” Reb. Br. 4.
For the above reasons, we disagree that the Examiner has switched the
mapping of the recited secure name from Beser’s unique identifier to something
else. App Br. 11–13; Reb. Br. 3. We note that the Examiner’s statement on page
12 of the RAN is part of the Response to Argument section — not the rejection
itself —and focuses on IP addresses affiliated with the unique identifier (e.g., a
private address that is packetized) and hidden to demonstrate a security feature.
Also, in other portions of the RAN, the Examiner expressly agrees with the
Requester’s position that the secure name is Beser’s unique identifier. RAN 14, 16
(stating “[t]he Examiner agrees with the third party requester.”).
Owner further takes exception with a statement made by the Examiner in the
RAN regarding “‘the claim merely requires a message . . . being sent between two
devices[.]’” App. Br. 6 (citing RAN 14). We note that claims 1 and 2 include
sending a message from a device to a network address corresponding to a secure
name associated with another device. App. Br., Claims App’x. Moreover, the
rejection adopted by the Examiner includes a complete discussion of the specific
limitations in the claims. RAN 4 (citing Request 23–40, 41–42, 43–65 and Exhibit
C-1). We therefore disagree that the Examiner simplifies the recited sending and
receiving steps, overlooking specific requirements of the claims. App. Br. 6–7.
Appeal 2015-004512
Control 95/001,949
Patent 8,051,181 B2

18
Returning to Figures 4 and 5 and concerning the disputed receiving and
sending steps of claim 1 (App. Br. 13–16), Beser discloses a process for
establishing a secure transaction by initiating a tunneling or VoIP association
between originating and terminating ends that starts at step 102. Beser 7:62–66,
9:63–66, Figs. 4–5. The network device (e.g., 24 alone or in combination with 14)
is associated with the originating end (e.g., 24) of the tunnel association. See Resp.
Br. 2. At step 102 or 112, the request is received to initiate a tunnel or VoIP
association on the network device (e.g., 14) and the request includes a unique
identifier of the terminating end (e.g., 26) of the tunneling association. Beser
7:64–8:4, 10:2–6, Figs. 4, 5. Trusted-third-party device 30 contains a database or
directory that retains a list of public IP addresses associated with devices 16 and
26. Beser 11:32–58; 12:33–36. At step 106 or equivalent step 116, Beser
discloses a public network address for a network device (e.g., 16) is associated
with the unique identifier of the terminating network device (e.g., 26), the network
device (e.g., 16) is associated with the terminating device (e.g., 26) based on the
unique identifier (e.g., domain name) in the request, and network devices 14 and
16 are associated. Beser 2:43–3:9, 9:6-8, 11:26-32, Figs. 4–6.
Thus, at step 106 or 116 in order to establish a communication between two
network devices, a server (e.g., 30) receives a message from an originating device
that contains a unique identifier (e.g., a request from device 24 alone or in
combination with 14 having a secure name) and associates terminating network
device 26 with a public IP address for device 16 based on the unique identifier
(e.g., receiving a message from a device for communication with another device at
a network address corresponding to a secure name of another device). See id.
Notably, claim 1 does not recite the message is received at any particular device or
Appeal 2015-004512
Control 95/001,949
Patent 8,051,181 B2

19
cannot be transmitted through an intermediary device. See Resp. Br. 5. Also,
similar to the ’181 patent and independent claim 2 of the ’181 patent, the request
includes a query for a computer network address based on a user’s identity that is
sent to a secure name server (e.g., SNDS), and the server contains a cross-reference
database of secure names and corresponding secure network addresses. The ’181
patent 50:36–39, 60–64, 51:11–15; Fig.33.
Additionally, if step 106/116 are not considered to disclose receiving a
message “at a network address” as recited, step 108 or equivalent step 118 in Beser
further discloses private IP addresses on network devices (e.g., 14 and 16) are
negotiated using the public network and the private IP addresses are assigned to the
terminating network devices (e.g., 24, 26). Beser 9:26–28, 46–49, 11:59–62,
11:67–12:4, Figs. 4–6. That is, during negotiation between the devices, messages
are sent from one device (e.g., 14) and received at a network address
corresponding to the secure name associated with another device (e.g., 16). See id.
Beser states the negotiation at step 118 hides the identity of end network
devices (e.g., 24, 26) from the public network and ensures anonymity. Beser
12:13–19. This illustrates both that a message is received from a second device
(e.g., 14) at a network address corresponding to a secure name associated with the
first device (e.g., 16) and creates a secure communication link for information
transmitted between a second and a first device (e.g., 14/24 and 16/26). Beser also
discloses the method “increases the security of communication on the data
network” and hides identities to prevent interception of media flow between ends
of the tunneling or VoIP association. Beser, Abstract. As such, Beser further
discloses sending a message (e.g., communication or media flow) over a secure
communication link from the first and second device (e.g., a path that hides
Appeal 2015-004512
Control 95/001,949
Patent 8,051,181 B2

20
devices’ identities) as recited. Given the above statements and our understanding
of the phrase “secure communication link,” the tunneling or VoIP association
creates a secure communication link from the first device to the second device as
broadly as recited.
Contrary to Owner’s assertion (App. Br. 15–16 (citing Keromytis Decl. ¶ 28,
Supp. Keromytis Decl. ¶ 7)) and although this is anticipation rejection, Beser does
not teach away from encrypting packets. See RAN 18–20. Additionally, claim 1
does not recite and the disclosure of the ’181 patent does not require the recited
“secure communication link” secure the contents of communications from
eavesdropping. App. Br. 16 (citing Keromytis Decl. ¶ 30).
Turning to claim 2, Owner refers to the argument made for claim 1, for
which we are not persuaded. App. Br. 17; Reb. Br. 5–6. Notably, claim 2 does not
recite “an unsecured name” and thus, the arguments concerning a device associated
with unsecure name are not applicable. We further disagree that the same recited
device (e.g., the first device) does not send and receive a message as claimed. We
refer to the above discussion of how device 14 sends a request (e.g., a message) to
a secure name server to make a tunnel or VoIP association (e.g., create a secure
communication link) with a second device (e.g., 16 and 26) and how this is
achieved through association and negotiation of a unique identifier and IP
addresses between devices 14 and 16 (e.g., receiving a message containing the
network address associated with a secure name and sending a message to the
network address associated with the secure name using a secure communication
link). Resp. Br. 6. Moreover, Requester indicates that Beser discloses a first
device (e.g., 14) stores (e.g., receives) the private IP address associated with the
destination device (e.g., 26) and also transmits the private network addresses to the
Appeal 2015-004512
Control 95/001,949
Patent 8,051,181 B2

21
network device at the end of the tunneling association (e.g., 16). Id. (referring to
Request 34–35 and citing Beser 21:38–55).
Disputed claim 4 recites “the secure name indicates security.” App. Br.,
Claims App’x. Owner argues that “nothing about the[] exemplary unique
identifiers [in Beser] indicates or suggests security.” App. Br. 17; Reb. Br. 6. We
disagree. First, the phrase “indicates security” in claim 4 is quite broad. Second, a
unique identifier for a device provides security. For example, a person’s phone
number, social security number, or domain name (Beser 10:37–41, 10:67–11:8) are
unique to person, providing and indicating a certain level of security. Although
Beser’s secure name is not “scom” as illustrated in the ’181 patent, we disagree
that the unique identifier in Beser is not a name that indicates at least some level of
security. Moreover, as explained above, the secure name in Beser is used to create
a secure communication link, which also indicates a level of security. See RAN
20–21.
Owner disputes claim 9, which recites “automatically initiating the secure
communication link after it is enabled.” App. Br. 18; Reb. Br. 6–7. Specifically,
Owner contends that “a user could be involved in the steps” for establishing a
tunnel association and thus does not disclose that the initiating is automated
expressly or inherently. Id. We agree with Requester that Beser discloses the first
and second network devices and the trusted-third-party network device negotiate
addresses to create the tunnel for secure communications without involving an end
user as explained above, and thus the secure communication link is initiated
automatically after the tunnel is enabled (e.g., after steps 116 and 118). Beser
11:9–29, 59–62; Figs. 5–6.
Appeal 2015-004512
Control 95/001,949
Patent 8,051,181 B2

22
Claim 10 depends from claim 2 and further recites the “receiving” step
includes “receiving the message at the first device through tunneling within the
secure communication link.” App. Br., Claims App’x. Claim 11 recites a similar
limitation of receiving the message “in the form of at least one tunneled packet.”
Owner contends that tunnel association is not set up at the time the network
address is received and thus fails to teach claims 10 and 11. App. Br. 18-19; Reb.
Br. 7. We are not persuaded and adopt Requester’s position. Resp. Br. 7.
Owner disputes independent claim 24, which recites “obtaining registration
of a secure name for the first device.” App. Br. 19–20; Reb. Br. 7-8. Owner
repeats the arguments made previously for claim 1, for which we are not
persuaded. App. Br. 20. Specifically, Owner argues Beser’s list does not
inherently disclose the recited “registration,” because the unique identifier could be
“registered in a way other than by requesting registration at that same device.”
App. Br. 19. For example, the device at which registration is requested and
obtained is different from the device from which a message is securely sent. App.
Br. 19 (citing Keromytis Decl. ¶ 38). We are not persuaded. We agree with
Requester that Owner’s arguments are inconsistent with Beser. Resp. Br. 7. In
particular, Beser discloses the private IP addresses for the originating and
terminating devices (e.g., 24 and 26) are recorded on the first and second network
devices (e.g., 14 and 16) and addresses are stored in tables on these network
devices. Beser 12:28–37. As explained above, network device 14 that obtains
registration of the secure name through the recording also sends a message
securely to a second device.
Appeal 2015-004512
Control 95/001,949
Patent 8,051,181 B2

23
As for the remaining claims, Owner refers to the previous arguments made
in connection with claims 1 and 2. App. Br. 20. We are not persuaded and refer to
our previous discussion.
For the above reasons, we are not persuaded that the Examiner erred in
rejected claims 1–12, 14, 15, and 17–29.
2. Mattaway
Claims 1, 2, 5–9, 12–17, 19–21, and 24–29 have been rejected under 35
U.S.C. § 102(e) based on Mattaway. RAN 5 (citing Request 68–94 and Exhibit C-
2). Similar for this rejection, Owner repeats arguments urging a particular
construction of certain terms in the claims (e.g., secure name, secure
communication), for which we discussed above in the Claim Construction section
and for which we do not adopt. App. Br. 20–26; Reb. Br. 8–9. We next turn to
Owner’s specific contentions concerning Mattaway.
Owner argues that Mattaway does not disclose a first device associated with
a secure name and unsecured name. App. Br. 22; Reb. Br. 8–9. In particular,
Owner contends that an email address or an alias does not correspond to the secure
name and unsecured named in claim 1. Id. Moreover, Owner contends, because
both names accomplish the same task and are used in the same way, the labeling of
one as “secure” and the other as “unsecured” is arbitrary. Id.
Regarding the “secure name” limitation in claim 1, we are not persuaded that
“a secure name” must be resolved by a secure name service or requires a secure
name service to resolve secure names based on our claim construction discussed in
Section III.A.1. App. Br. 22. Given our understanding, a secure name connotes a
level of security, including a secure network address or a telephone number. See
Resp. Br. 8 (citing RAN 28, which further cites to ACP 32). The Examiner maps
Appeal 2015-004512
Control 95/001,949
Patent 8,051,181 B2

24
the callee’s email address or telephone number to the recited “secure name” and
the party’s name or alias to the recited “unsecured name.” RAN 28; Request 69–
70; Resp. Br. 8.
Mattaway discloses two devices (e.g., 12, 22 or 1536, 1538) that
communicate with each other and contain VoIP software to enable communication
with each other. Mattaway 4:36–42 (cited at Request 70); Figs. 1, 15A. Such
devices have email addresses. See Mattaway, Table 6, column 36 (e.g.,
“emailAddr” and “party EmailAddr”). Additionally, Mattaway discloses such
names are located in global server 1500 in database 1516, which are located behind
a firewall (e.g., 1522) that protects against unauthorized access from network 1530
into the global server 1500 and destruction of information contained in with server
1500. Request 70 (citing Mattaway 17:44–48); see also Mattaway 17:37–43, 48–
54, 18:19–40; Figs. 15A–B. Given that these addresses are protected from
destruction by the firewall, we find that these email addresses are made secure by
the firewall and connote a level of security. Additionally, these addresses are
matched to an IP address also located behind the firewall (see Mattaway 18:34–40)
and thus are names that corresponds to a secure computer network address.
Although Owner further cites to the Keromytis declaration, which states
Mattaway does not use the word “security” or “secure” (App. Br. 26 (citing
Keromytis Decl. ¶ 46)), the above discussion of preventing unauthorized access
discloses a secure network for data stored behind the firewall. Also, given the
firewall server in Mattaway, server 1500 includes more than just the conventional
DNS functions as Owner’s argues. App. Br. 22. Even further, Mattaway discloses
email addresses can be encrypted, which connotes another level of security. See
Resp. Br. 8; RAN 24–25 (citing Mattaway 25:32–34).
Appeal 2015-004512
Control 95/001,949
Patent 8,051,181 B2

25
Regarding whether the first device is also associated with an unsecure name,
the rejection notes that the caller or party’s name (e.g., a name or alias), which is
associated with the device that permits the call (e.g., a web phone), is identified
when an incoming call arrives. Request 70 (citing Mattaway 11:13–15, 26:45–47).
As such, when the first device (e.g., 22 in Figure 1) places a call, an associated
name (e.g., a party name or alias) of the first device is identified, and given that
this name is exposed to the callee, we agree that this name is unsecure. We
therefore find that a party name or alias does not connote a level of security or is an
unsecured name as recited. Also, as explained above, we further disagree that the
mapped secure and unsecured names “functionally identical[ly].” App. Br. 22.
Although Owner contends that placing (e.g., storing) a name behind a
firewall or encrypting a name does not transform it to a secure name, we disagree.
App. Br. 23-24. Essentially, Owner argues for a narrower construction of “secure
name” that requires resolution by a secure name server into a network address and
supports establishing a secure communication link, which has not adopted. See id.
Additionally, Owner admits that using cryptographic digital signatures and
authentication techniques adds security “in the colloquial sense,” but contends the
’181 patent disparages these techniques and rejects that these processes transform a
domain name into a secure name as recited. App. Br. 24 (citing the ’181 patent
39:14–25). We are not persuaded.
First, column 39 of the ’181 patent does not disparage using a conventional
scheme or reject that this process does not transform the domain name into a
secure name. The ’181 patent 39:14–25. In fact, although indicating the scheme
suffers from drawbacks (the ’181 patent 39:23), this passage states the scheme
“provides secure virtual private networks over the Internet.” The ’181 patent
Appeal 2015-004512
Control 95/001,949
Patent 8,051,181 B2

26
39:14–15 (italics added). Additionally, as explained above and in column 39, there
is no distinction in the ’181 disclosure that adding security “in the colloquial
sense” (App. Br. 24) cannot establish a secure name. As explained previously, a
secure name includes “non-standard” names, which is an expansive term that
includes email addresses that are secured behind a firewall as Mattaway discloses.
We therefore disagree that Mattaway fails to disclose a first device associated with
a secure name and an unsecured name.
Next, Owner argues that Mattaway’s message is not a
message received at the network address corresponding to the secure name
associated with the first device as recited in claim 1. App. Br. 24–25; Reb. Br. 9.
However, as noted by Requester, the Examiner adopted the rejection that includes
mapping the message to the receiving step in claim 1. RAN 26–27
(adopting the Requester’s response discussing in step 8 following the
and messages 6 and 7A); see also Resp. Br. 9
(citing Request 72, RAN 24–27). That is, Mattaway discloses webphone 1536
opens a socket to server 1500 and transmits a packet at step 6.
Mattaway 23:56–64; Fig. 17A. The email address in the packet is used to perform
a mapping to determine the IP address of the callee and server 1500 transmits a
packet to webphone 1536 at step 7A, closing the socket.
Mattaway 23:59–67; Fig. 17A. Next, Mattaway discloses webphone 1536 opens a
socket with webphone 1538 and transmits a packet or message 8 having
the format at Table 6, which includes the email address (e.g., emailAddr).
Mattaway 24:19–25.
Thus, at least message 8 is a message from a second device (e.g., webphone
1536) at a network address related to or corresponding with a secure name
Appeal 2015-004512
Control 95/001,949
Patent 8,051,181 B2

27
associated with the first device (e.g., email address is correlated to the IP address
of webphone 1538). Id.; Mattaway 17:37–50, 18:19–40. That is, the
message discloses the recited receiving step in claim 1. As such, Owner’s
argument that the interrelationship between the , , and messages has not been explained (App. Br. 26) overlooks
that message 8 in Mattaway has been mapped to the receiving step in the rejection.
Even so, the relationship of these messages in Mattaway, as explained above,
would have been recognized by an ordinarily skilled artisan. We therefore
disagree that Mattaway fails to disclose the recited “receiving” step in claim 1.
As for the remaining claims, Owner refers back to the arguments presented
for claim 1. App. Br. 26-27. We are not persuaded for the above reasons.
Additionally, we note that independent claims 2, 24, 28, and 29 do not recite an
unsecured name and claim 2 recites sending a message to a secure name server.
For the above reasons, we are not persuaded that the Examiner erred in
rejected claims 1, 2, 5–9, 12–17, 19–22, and 24–29.
3. Provino
Claims 1–15, 18–23, 28, and 29 of the ’181 patent are rejected under 35
U.S.C. § 102(e) based on Provino. RAN 7–10. Owner contends that there is an
ambiguity in the rejection as to what is being mapped to the first and second
devices in Provino and the Examiner has switched positions throughout the
proceedings. App. Br. 39–40 (citing RAN 64); Reb. Br. 11. Specifically, Owner
contends that device 12(m) was first mapped to the first device and now server
31(s) is mapped to the first device and 12(m) to the second device. App. Br. 39
(citing Request 169, 171 and RAN 64). We disagree.
Appeal 2015-004512
Control 95/001,949
Patent 8,051,181 B2

28
At the outset, we note that Owner labels the first device in claim 1 as the
device that is associated with the secure name and then switches in claim 2 to label
a second device having a secure name. App. Br., Claims App’x. This switch in
the claim language between claims 1 and 2 only contributes to the confusion,
which may have led to some apparent, conflicting mapping by the Examiner to the
claimed first and second devices as recited in claims 1 and 2. We therefore give
some latitude in the rejection and in clarifying the position the rejection takes.
Provino discloses the following system in Figure 1:

Figure 1 shown above includes device 12(m) and server 31(s) which can
communicate in a secure fashion in virtual private network (VPN) 15. Request
170–171 (citing Provino 13:26–67, which discusses created a secure tunnel
between device 12(m) and servers 31(s) in a VPN); RAN 62 (citing Provino 10:7–
Appeal 2015-004512
Control 95/001,949
Patent 8,051,181 B2

29
12, discussing the secure tunnel that includes a firewall 30 and
encryption/decryption algorithms).
Requester notes and we agree that the rejection did not switch which device
is the first and second device as claimed. Resp. Br. 11. For example, the Request,
which is adopted by the Examiner (RAN 7), discusses server 31(s) connecting to
device 12(m) and two names associated with server 31(s). Request 168 (citing
Provino 9:2–5, 10:45–52). The Examiner articulates this same position in the
RAN. RAN 64 (stating server 31(s) is the recited first device and device 12(m) is
the recited second device.) Granted, the Request discusses device 12(m) as “a first
device” (Request 171 (citing Provino 9:46–52); Resp. Br. 11), but explains that this
device (e.g., the recited second device) initiates the secure communication link that
sends the message requesting to securely communicate with another device (e.g.,
the recited first device). Accordingly, as claimed and as mapped in the rejection,
the Examiner mapped server 31(s) to the first device and device 12(m) to the
recited “second device” in claim 1.
Next, Owner asserts that Provino does not disclose “a first device associated
with a secure name and an unsecured name” as recited in the preamble of claim 1.
App. Br. 40–41. Owner maintains that the Examiner has mapped the first device to
device 12(m) in contending that this device does not have a domain name stored in
servers 17 or 32. Id. We are not persuaded, because, as explained above, these
arguments do not address the rejection that maps server 31(s) to the first device.
Request 168; RAN 64.
Owner argues that even if server 31(s) is mapped to the first device, server
17 does not contain any name associated with server 31(s). App. Br. 40 (citing
Keromytis Decl. ¶ 79 and Provino 10:48–55). This argument overlooks other
Appeal 2015-004512
Control 95/001,949
Patent 8,051,181 B2

30
portions of Provino that teach using server 32 when the device 12(m) and firewall
30 cooperate to establish a secure tunnel and when the nameserver 17 is not
provided with an integer Internet address for server 31(s). Provino 10:45–11:29.
In this scenario firewall 30 provides device 12(m) with the identification of
nameserver 32 in the VPN 15 so as to obtain the appropriate integer Internet
address from the human-readable Internet address. Provino 10:56–67 (cited at
Request 169), 11:10–25; see also Provino 8:67–9:5 (citing at Request 168, 170).
See also Resp. Br. 11.
As the Examiner states, the domain name or other human-readable Internet
address for servers 31(s) is mapped to the “secure name” associated with the first
device. RAN 62–63 (citing Provino 8:67–9:5). Upon review, we agree with the
Examiner that servers 31(s) in Provino include human readable Internet addresses.
Provino 9:2–5, 2:2–5. Moreover, although some passage in Provino discuss name
server 17 resolving the human domain name (e.g., Provino 7:37–43), Provino
further discusses name server 32 also resolves human-readable addresses of server
31(s) (Provino 8:64–9:5). See also RAN 63. Moreover, the human–readable name
is not accessible to servers (e.g., nameserver 17) and is located behind the firewall,
which connotes a level security for the name. As such, Provino discloses a first
device (e.g., server31(s)) associated with a secure name as recited.
Owner next argues that nameserver 32 in Provino operates in a conventional
manner that is disclaimed by the ’181 patent. App. Br. 41. We disagree that the
’181 patent has disclaimed a name server, such as server 32, from assisting in
creating a secure communication link as argued. Keromytis Decl. ¶ 82. As
discussed above, a “secure name” as broadly, but reasonably construed in light of
the disclosure, need not be resolved by a secure name server. See RAN 68. Even
Appeal 2015-004512
Control 95/001,949
Patent 8,051,181 B2

31
so, Provino’s server 32 does resolve the secure name (e.g., a human-readable
address for server 31(s)) into an unsecured name (e.g., integer IP address for server
31(s)). Provino 9:2–5. Moreover, even presuming such a disclaimer exists, we
agree with Requester that server 32 in Provino, which is described as a “VPN name
server,” is not a standard DNS server on the public Internet and is located internal
to VPN 15. See Resp. Br. 12; Provino 9:2–5; Fig. 1. Additionally, Provino
discloses the resolution establishes a secure communication link due to the firewall
and encryption/decryption algorithms. Provino 10:7–12, 12:4–16, 13:26–67.
Also, to the extent argued (App. Br. 41), we disagree that the ’181 patent
disparages conventional DNS as failing to create a secure communication link.
Rather, the ’181 patent states a conventional scheme can “provide[] secure virtual
private networks.” The ’181 patent 39:14–16 (cited at App. Br. 41).
Concerning the “first device associated with . . . an unsecured name”
limitation, Owner argues that the domain name stored in nameserver 17 is not any
name, including an unsecured name, associated with the first device (e.g., server
31(s)). App. Br. 40. We disagree. Both servers 17 and 32 contain the human
readable Internet address and an integer Internet address for devices. Provino
8:40–43, 8:67–9:5. Additionally, as Requester explains, “VPN 15 and devices
within it are ‘associated with the unsecure name’ - that is how public name server
17 is able to find and route traffic to VPN 15 to firewall 30.” Resp. Br. 11 (citing
RAN 62–63; Req. at 167–71). We agree.
As the Examiner explains, Provino discloses access to an unsecured name
(e.g., integer Internet address) through a public domain name server (e.g., 17).
RAN 62, 65 (citing Provino 8:40–43). When nameserver 17 does not have an
address, message packets are sent to firewall 30, which is connected to Internet 14
Appeal 2015-004512
Control 95/001,949
Patent 8,051,181 B2

32
and has an Internet address. Provino 8:65–67; Fig. 1. Given that the message is
forwarded to firewall 30, the firewall’s Internet address must be known and does
not connote security (e.g., an unsecure name). Although firewall 30 serves to
control access of devices external to VPN 15, the firewall also receives messages
intended for servers, such as server 31(s), which are sent from devices, such as
12(m), and forwards them to server 31(s) if authorized. Provino 8:67–9:5, 9:13–
22, 10:45–11:22. Additionally, Provino states the firewall is similar to other
devices 31(s) in the VPN. Provino 9:27–30. Given that the firewall’s address is
used to forward messages to the server 31(s), there is some association between
firewall 30 and server 31(s). As such and as broadly as recited, Provino teaches an
unsecured name (e.g., domain name address provided by server 17) that is
associated with the first device (e.g., 31(s)).
The Examiner and Requester further determine that the first device can
include multiple components. RAN 67. As explained above, when addressing
Beser, we agree that the recited “first device” is not limited to one element in
Provino. See also Resp. Br. 11. The Examiner similarly refers to Figure 26 in the
’181 patent that permits the functions of the first device to be distributed across
multiple components. RAN 67 (discussing DNS server 2609, DNS Proxy 2610,
and Gate Keeper 2603 in the ’181 patent); Resp. Br. 11. As such, multiple
components of the VPN (e.g., firewall 30, server 31(s)) can be mapped to the
recited “first device” in claim 1. Accordingly, we do not find that the Examiner
has diverged from the original position in the rejection, such that the rejection must
be designating a new ground. App. Br. 40–41.
Appeal 2015-004512
Control 95/001,949
Patent 8,051,181 B2

33
As for claims 2–15, 18–23, 28, and 29, the Examiner relies on the arguments
presented for claim 1. App. Br. 41–42. For the previously stated reasons, we are
not persuaded.
Accordingly, we are not persuaded that the Examiner erred in rejected
claims 1–15, 18–23, 28, and 29.
4. Remaining Rejections
Our conclusion that the Examiner did not err in rejecting claims 1–29 based
on the adopted rejections discussed above renders it unnecessary to reach the
propriety of the remaining rejections. See Beloit Corp. v. Valmet Oy, 742 F.2d
1421, 1423 (Fed. Cir. 1984); cf. In re Gleave, 560 F.3d 1331, 1338 (Fed. Cir.
2009). See also 37 C.F.R. 41.77 (a) (“The Patent Trial and Appeal Board … may
affirm or reverse each decision of the examiner on all issues raised on each
appealed claim”) and Gleave, 560 F.3d at 1338. Additionally, because the
rejections discussed are based on anticipation and covering all the rejected claims,
we need not reach the discussion of secondary consideration. App. Br. 63–71.
Even so, we note that much of the evidence was discussed in related proceeding
Control No. 95/001,792, where we found the evidence insufficient to outweigh the
evidence of obviousness. Cisco Systems, Inc. v. VirnetX, Inc., Appeal No. 2014-
000591, 2014 WL 1322692 at *11-14 (PTAB April 1, 2014).

IV. CONCLUSIONS
Owner did not demonstrate that the Examiner erred in rejecting claims 1–29
based on Beser, Mattaway, or Provino.
The Examiner’s decision to reject claims 1–29 is affirmed.

Appeal 2015-004512
Control 95/001,949
Patent 8,051,181 B2

34
V. TIME PERIOD FOR RESPONSE
Requests for extensions of time in this inter partes reexamination
proceeding are governed by 37 C.F.R. § 1.956. See 37 C.F.R. § 41.79.
In the event neither party files a request for rehearing within the time
provided in 37 C.F.R. § 41.79, and this decision becomes final and appealable
under 37 C.F.R. § 41.81, a party seeking judicial review must timely serve notice
on the Director of the United States Patent and Trademark Office. See 37 C.F.R.
§§ 90.1 and 1.983

AFFIRMED

Appeal 2015-004512
Control 95/001,949
Patent 8,051,181 B2

35

FOR PATENT OWNER:

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

FOR THIRD-PARTY REQUESTERS:

SIDLEY AUSTIN LLP
2001 ROSS AVENUE, SUITE 3600
DALLAS, TX 75201