NOTE: This disposition is nonprecedential.

United States Court of Appeals 

for the Federal Circuit ______________________

ROUTE1 INC.,

Plaintiff-Appellant

v.

AIRWATCH LLC, VMWARE, INC.,

Defendants-Appellees

______________________

2020-1031

______________________

Appeal from the United States District Court for the 

District of Delaware in No. 1:17-cv-00331-KAJ, Circuit 

Judge Kent A. Jordan.

______________________

Decided: October 7, 2020

______________________

MARCEL CHARLES DUHAMEL, Vorys Sayer Seymour & 

Pease LLP, Cleveland, OH, for plaintiff-appellant. Also 

represented by MICHAEL J. GARVIN, AARON WILLIAMS; 

WILLIAM H. OLDACH, III, Washington, DC; REX W. MILLER,

II, Columbus, OH. 

 BRIAN ROBERT MATSUI, Morrison & Foerster LLP, 

Washington, DC, for defendants-appellees. Also represented by SAMUEL BENJAMIN GOLDSTEIN; RICHARD HUNG,

MICHAEL ALLEN JACOBS, San Francisco, CA.

Case: 20-1031 Document: 58 Page: 1 Filed: 10/07/2020
2 ROUTE1 INC. v. AIRWATCH LLC

 ______________________

Before PROST, Chief Judge, MOORE and STOLL, Circuit 

Judges.

PROST, Chief Judge.

Route1 Inc. (“Route1”) appeals the U.S. District Court 

for the District of Delaware’s order granting summary 

judgment of noninfringement to AirWatch LLC and 

VMware, Inc. (collectively, “AirWatch”). We affirm the district court’s thorough opinion. 

BACKGROUND

I

Route1 owns U.S. Patent No. 7,814,216 (“the ’216 patent”), which involves enabling communication between a 

host computer (“host”) and a remote device (“remote”). The 

patent’s sole independent claim recites a method by which 

the host and remote become connected by interfacing with 

an intermediary called the “controller.” First, the controller separately connects to the host and the remote. Next, 

it validates certificates received from each. After that, it 

receives the remote’s selection of a host and sends parameters for the remote to the selected host. So far, the host 

and remote have interacted only with the controller. The 

next step changes that. This step, the “instruction limitation,” is the subject of this appeal: “sending an instruction, 

from the controller to the selected host, to establish a connection to the remote device.” Last, the controller receives

notice that the host and remote are connected to one another and refrains from further involvement. The claim recites in full:

1. A method of enabling communication between a 

host and a remote device using a controller, comprising:

connecting the controller to the host;

Case: 20-1031 Document: 58 Page: 2 Filed: 10/07/2020
ROUTE1 INC. v. AIRWATCH LLC 3

connecting the controller to the remote device, the 

host and the remote device being in separate locations;

validating, at the controller, digital identity certificates received from each of the host and the remote 

device, each identity certificate containing (i) the 

public half of an asymmetric key algorithm key 

pair, (ii) identity information, and (iii) a digital signature of the issuing certificate authority, thereby 

converting the host to a validated host, and converting the remote device to a validated remote device;

receiving, at the controller, a selection of the host 

from the validated remote device;

sending parameters for the validated remote device 

from the controller to the selected host;

sending an instruction, from the controller to the selected host, to establish a connection to the remote 

device;

receiving, at the controller, notifications from the

selected host and the validated remote device that 

a connection exists therebetween; and

after receiving notice of a connection between the

selected host and the validated remote device refraining from involvement, at the controller, in 

transporting data between the selected host and 

the validated remote device, so that the selected 

host and the validated remote device subsequently 

communicate with each other without using any resource of the controller.

’216 patent claim 1 (emphasis added). 

Case: 20-1031 Document: 58 Page: 3 Filed: 10/07/2020
4 ROUTE1 INC. v. AIRWATCH LLC

II

The instruction limitation was not proposed for construction during the Markman proceedings in this case. 

Rather, AirWatch requested construction after Route1’s 

expert opined that the limitation may cover “a host-initiated connection, or a remote-initiated and host-accepted 

connection.” J.A. 12. AirWatch moved for summary judgement of noninfringement while that request was pending.

The court construed the instruction limitation in an order and memorandum opinion on summary judgment. See

O2 Micro Int’l Ltd. v. Beyond Innovation Tech. Co., 521 

F.3d 1351, 1362 (Fed. Cir. 2008) (“When the parties present 

a fundamental dispute regarding the scope of a claim term, 

it is the court’s duty to resolve it.”). The court’s construction—“sending an instruction, from the controller to the selected host, for the host to establish a connection to the 

remote device”—adds only the words “for the host.” J.A. 18

(emphasis added). Under this construction, the limitation 

“encompasses only host-initiated, not remote-initiated, 

connections.” J.A. 11. Based on this construction, the 

court granted summary judgment of noninfringement. 

J.A. 20. Route1 appealed. We have jurisdiction under 28 

U.S.C. § 1295(a)(1). 

DISCUSSION

The parties agree that AirWatch does not infringe

claim 1 of the ’216 patent under the district court’s construction. Appellant’s Br. 23–24; see also J.A. 20. We 

therefore need only decide whether that construction is correct. We review a claim construction de novo where, as 

here, it depends only on the intrinsic evidence. Teva 

Pharms. USA, Inc. v. Sandoz, Inc., 574 U.S. 318, 331 

(2015).

The words of a claim “are generally given their ordinary and customary meaning,” which is “the meaning that 

the term would have to a person of ordinary skill in the art 

Case: 20-1031 Document: 58 Page: 4 Filed: 10/07/2020
ROUTE1 INC. v. AIRWATCH LLC 5

in question at the time of the invention.” Phillips v. AWH 

Corp., 415 F.3d 1303, 1312–13 (Fed. Cir. 2005) (en banc). 

Claim terms “must be read in view of the specification.” Id.

at 1315. Additionally, “the prosecution history can often 

inform the meaning of the claim language by demonstrating how the inventor understood the invention and 

whether the inventor limited the invention in the course of 

prosecution.” Id. at 1317. Based on this intrinsic evidence, 

we affirm. 

I

The district court’s construction emphasizes what is already plain from the claim language: the instruction sent 

to the host is meant to be carried out by the host. As the 

court explained: “It would be illogical, absent contrary intrinsic evidence, to conclude that an instruction sent from 

the controller to the host somehow instructs the remote to 

establish the connection, when the remote has received no 

instruction.” J.A. 13. We agree. 

Route1 appears to agree that the host, not the remote, 

establishes the connection. Reply Br. 5 (“The structure of 

the claim indicates that in the Instruction Limitation, it is 

the host that acts to establish the connection.”). But by 

parsing the word “establish,” Route1 contends that the instruction limitation nonetheless encompasses remote-initiated as well as host-initiated connections. According to 

Route1, “‘establish’ connotes the culmination or conclusion 

of a process, regardless of where or how it was ‘initiated.’” 

Appellant’s Br. 17; see id. at 15 (advancing the construction 

“sending an instruction, from the controller to the host, to 

bring into existence a connection to the remote device”). On 

that basis, Route1 contends that the limitation does not 

specify whether the host or remote initiates the connection—only that, after one of them does, the host takes the 

final step of establishing it. We are unpersuaded. 

Route1 improperly focuses on “the abstract meaning of 

words rather than on the meaning of claim terms within 

Case: 20-1031 Document: 58 Page: 5 Filed: 10/07/2020
6 ROUTE1 INC. v. AIRWATCH LLC

the context of the patent.” Phillips, 415 F.3d at 1321. The 

claim requires that, once the controller has separately validated both the host and the remote, it sends parameters

for the remote to the host. Route1 acknowledges that, upon 

receiving the parameters, “the host is enabled to make a 

connection with the remote device.” Reply Br. 4. Therefore, before instructing the host to establish a connection to 

the remote, the controller has already sent the host information enabling it to do so. Rather than supporting

Route1’s construction, this setup reinforces that “establish” 

in this context is a simple directive for one entity to establish communication to another—and not, as Route1 contends, a more roundabout directive to “actively determin[e] 

whether or not to accept a connection request” from the remote based on the previously received parameters. Id. At 

the very least, Route1’s distinction between establishing 

and initiating finds no support in the claim language. We 

therefore turn to the rest of the specification.

II

The specification discloses host-initiated connections,

not remote-initiated connections, between the host and remote. For example, it details steps for “[s]etting up a communication channel between a remote computer and a host 

computer” as follows: “At step 335, host 60 sends a handshake to remote 10. . . . At step 435, remote 10 receives the 

handshake from host 60.” ’216 patent col. 7 ll. 5–7, 14–15. 

Figure 3A depicts this “handshake” with an arrow. As 

shown, the host offers its hand first.

Case: 20-1031 Document: 58 Page: 6 Filed: 10/07/2020
ROUTE1 INC. v. AIRWATCH LLC 7

Id. at Fig. 3A (annotated). 

The district court was right: “That handshake establishes the connection, and is initiated by the host.” J.A. 13–

14. Although Route1 quotes passages in which the remote 

requests a connection to the controller, it does not identify 

a disclosure in which “the host establishes the connection 

by responding to a request from the remote device.” Reply 

Br. 2. Indeed, Route1 admits “there is no place in the specification where it is disclosed that the remote asks the host 

Case: 20-1031 Document: 58 Page: 7 Filed: 10/07/2020
8 ROUTE1 INC. v. AIRWATCH LLC

to connect, at least not directly.” Id. at 10. Rather, the 

specification discloses only host-initiated connections, not

remote-initiated ones.

Of course, the specification’s disclosing only host-initiated connections is not dispositive. Phillips, 415 F.3d at

1323. But it does “suggest that the patent’s claim[] do[es]

not encompass an embodiment contrary to these descriptions.” Wi-LAN USA, Inc. v. Apple Inc., 830 F.3d 1374, 

1382 (Fed. Cir. 2016). And, although “the specification 

does not contain an explicit statement disclaiming” remoteinitiated connections, “this is not an instance where the 

specification would necessarily have to disavow an embodiment that would otherwise be covered by the plain language of the claim[].” In re Abbott Diabetes Care Inc., 696 

F.3d 1142, 1149 (Fed. Cir. 2012). Rather, the plain terms 

of the instruction limitation are “entirely consistent with 

and even support the specification’s exclusive depiction” of 

host-initiated connections. Id. at 1150. 

III

Even if there were any lingering doubt, such doubt is 

put to rest by the prosecution history. Route1 added the 

instruction limitation to claim 1 (then claim 3) during prosecution to overcome a rejection over U.S. Patent Application Publication No. 2005/0120204 (“Kiwimagi”) and 

repeatedly distinguished Kiwimagi on the ground that it 

teaches a remote-initiated connection. For example, after 

relying on Figure 3A to explain the instruction limitation 

to the patent office, Route1 annotated a figure from Kiwimagi by adding two bold columns—one on either side—

in an arrangement mirroring Figure 3A (i.e., depicting Kiwimagi’s remote client (remote), security host (controller) 

and system host (host) from left to right):

Case: 20-1031 Document: 58 Page: 8 Filed: 10/07/2020
ROUTE1 INC. v. AIRWATCH LLC 9

J.A. 5250. To depict the remote’s first contact with the

host, Route1 added an arrow extending from the remote to 

the host—the opposite direction of the Figure 3A handshake. Then, Route1 argued that Kiwimagi “fails to show 

or suggest” the instruction limitation and “teaches away

from claim 3 because claim 3 requires that the controller 

instruct the host to establish a connection to the remote, 

whereas Kiwimagi teaches that the remote client requests 

a connection directly from the host system.” J.A. 5251. 

Route1 also explained why this difference was “crucially important”:

An advantage of the invention of claim 3 is that it 

works flawlessly even if the host is behind a 

Case: 20-1031 Document: 58 Page: 9 Filed: 10/07/2020
10 ROUTE1 INC. v. AIRWATCH LLC

firewall. In contrast, a firewall is likely to block a 

request from an unknown remote for access to a 

host behind the firewall, and so Kiwimagi’s system 

will not work properly with a host behind a firewall. . . . Thus, the ability to work despite the host 

being behind a firewall, present in claim 3 but not 

in Kiwimagi, is crucially important in modern computing systems.

J.A. 5251. Further, in a prosecution appeal brief, Route1 

doubled down on its “firewall” rationale and distinguished

Kiwimagi on the basis that Kiwimagi’s remote “takes the 

initiative”:

The present invention is directed to a configuration 

where a host computer is likely to be behind a firewall . . . . The firewall blocks unsolicited messages 

to the host computer . . . ; an example of an unsolicited message to the host computer is: an access 

request from a remote computer. The present invention is a workaround that enables a remote 

computer to access a host computer where the host 

computer is behind a firewall. In short, the remote 

tells the controller that it wishes to access the host, 

and the controller instructs the host to establish 

communication with the remote. Thus, the remote 

is able to access the host without sending an access 

request to the host that would be blocked by the

firewall.

. . . .

Claim 3 requires that the controller sends parameters for the remote to the host, and instructs the host 

to establish communication with the remote. In 

contrast, Kiwimagi has its security host send parameters for the host to the remote, so that the remote can establish communication with the host. 

Kiwimagi is simply the prior art, where the remote 

can request access to a host without concern for a 

Case: 20-1031 Document: 58 Page: 10 Filed: 10/07/2020
ROUTE1 INC. v. AIRWATCH LLC 11

firewall that blocks such access requests. When 

the host is behind a firewall, Kiwimagi’s teaching 

does not enable communication to occur between the 

remote and the host. In contrast, when the host is 

behind a firewall, the invention of claim 3 enables 

communication to occur between the remote and the 

host.

J.A. 5292, 5300. After reprising its annotated Kiwimagi 

figure, Route1 concluded:

Kiwimagi fails to show or suggest . . . sending an 

instruction, from the controller to the selected host, 

to establish a connection to the remote. Instead, 

Kiwimagi teaches that the remote takes the initiative to establish a connection to the host. . . . Kiwimagi’s remote request[s] access from the host, so 

there is no need for the host to establish a connection to the remote. 

J.A. 5301–02 (emphasis added). 

Route1 attempts to explain away these statements by 

characterizing Kiwimagi’s connection as both initiated and 

established by the remote, whereas the instruction limitation (in Route1’s view) covers connections that are always 

established by the host but can be initiated by the remote. 

The attempt fails. Route1’s annotated figure depicts Kiwimagi’s remote “request[ing]” a connection (with an arrow 

to the host) and the host “grant[ing]” the request (with an 

arrow back to the remote). J.A. 5300–01. Route1’s distinction between initiating and establishing, therefore, does 

not differentiate its statements about Kiwimagi from the 

remote-initiated scenario it now seeks to cover. E.g., Reply

Br. 10 (“[A] connection may be established when a device 

accepts a connection request.”).

Splitting hairs, Route1 tries to differentiate “taking the 

initiative” from “initiating.” See Reply Br. 16. But we see 

no relevant difference. Route1 described Kiwimagi’s 

Case: 20-1031 Document: 58 Page: 11 Filed: 10/07/2020
12 ROUTE1 INC. v. AIRWATCH LLC

remote as “request[ing]” access, J.A. 5302, just how it describes remote-initiated connections here. E.g. Appellant’s 

Br. 23 (“[T]he remote can initiate the process by requesting 

that the connection be established.”). At the end of the day, 

the construction to which Route1 objects—an instruction

“for the host to establish a connection to the remote”—may 

as well have come from Route1’s prosecution appeal brief. 

E.g., J.A. 5300 (“[T]he controller . . . instructs the host to 

establish communication with the remote.” (emphasis 

omitted)). We conclude that the entire intrinsic record supports the district court’s construction of the instruction limitation as not covering remote-initiated connections. 

CONCLUSION

We have considered Route1’s remaining arguments 

and find them unpersuasive. For the above reasons, we 

hold that the district court did not err in its claim construction. Because Route1 does not dispute noninfringement 

under that construction, we affirm the district court’s grant 

of summary judgment of noninfringement.

AFFIRMED

Case: 20-1031 Document: 58 Page: 12 Filed: 10/07/2020