Court Opinion

ID: 4573754
Source: CourtListenerOpinion
Date Created: 2020-10-07 16:00:43.993282+00
Date Added: 2024-06-11T13:32:03.326689
License: Public Domain

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

        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 repre-
 sented by SAMUEL BENJAMIN GOLDSTEIN; RICHARD HUNG,
 MICHAEL ALLEN JACOBS, San Francisco, CA.
Case: 20-1031     Document: 58      Page: 2      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 dis-
 trict court’s thorough opinion.
                         BACKGROUND
                               I
     Route1 owns U.S. Patent No. 7,814,216 (“the ’216 pa-
 tent”), 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 control-
 ler 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 param-
 eters 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 limita-
 tion,” is the subject of this appeal: “sending an instruction,
 from the controller to the selected host, to establish a con-
 nection to the remote device.” Last, the controller receives
 notice that the host and remote are connected to one an-
 other and refrains from further involvement. The claim re-
 cites in full:
      1. A method of enabling communication between a
      host and a remote device using a controller, com-
      prising:
      connecting the controller to the host;
Case: 20-1031      Document: 58     Page: 3     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 loca-
    tions;
    validating, at the controller, digital identity certif-
    icates 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 sig-
    nature of the issuing certificate authority, thereby
    converting the host to a validated host, and con-
    verting the remote device to a validated remote de-
    vice;
    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 se-
    lected 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 re-
    fraining 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 re-
    source of the controller.
 ’216 patent claim 1 (emphasis added).
Case: 20-1031     Document: 58       Page: 4      Filed: 10/07/2020

 4                                  ROUTE1 INC.   v. AIRWATCH LLC

                               II
     The instruction limitation was not proposed for con-
 struction during the Markman proceedings in this case.
 Rather, AirWatch requested construction after Route1’s
 expert opined that the limitation may cover “a host-initi-
 ated connection, or a remote-initiated and host-accepted
 connection.” J.A. 12. AirWatch moved for summary judge-
 ment of noninfringement while that request was pending.
      The court construed the instruction limitation in an or-
 der 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 construc-
 tion—“sending an instruction, from the controller to the se-
 lected 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 con-
 struction. Appellant’s Br. 23–24; see also J.A. 20. We
 therefore need only decide whether that construction is cor-
 rect. 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 ordi-
 nary 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: 5   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 demonstrat-
 ing 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 al-
 ready 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 in-
 trinsic 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 in-
 struction limitation nonetheless encompasses remote-initi-
 ated 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 connec-
 tion—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: 6      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 val-
 idated 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. There-
 fore, before instructing the host to establish a connection to
 the remote, the controller has already sent the host infor-
 mation 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 estab-
 lish communication to another—and not, as Route1 con-
 tends, a more roundabout directive to “actively determin[e]
 whether or not to accept a connection request” from the re-
 mote 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 re-
 mote. For example, it details steps for “[s]etting up a com-
 munication channel between a remote computer and a host
 computer” as follows: “At step 335, host 60 sends a hand-
 shake 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: 7    Filed: 10/07/2020

 ROUTE1 INC.   v. AIRWATCH LLC                               7

 Id. at Fig. 3A (annotated).
      The district court was right: “That handshake estab-
 lishes 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 spec-
 ification where it is disclosed that the remote asks the host
Case: 20-1031     Document: 58        Page: 8      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-initi-
 ated 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 descrip-
 tions.” 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” remote-
 initiated connections, “this is not an instance where the
 specification would necessarily have to disavow an embod-
 iment that would otherwise be covered by the plain lan-
 guage 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 pros-
 ecution to overcome a rejection over U.S. Patent Applica-
 tion 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 Ki-
 wimagi by adding two bold columns—one on either side—
 in an arrangement mirroring Figure 3A (i.e., depicting Ki-
 wimagi’s remote client (remote), security host (controller)
 and system host (host) from left to right):
Case: 20-1031      Document: 58   Page: 9   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 hand-
 shake. 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 “cru-
 cially 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: 10     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 fire-
      wall. . . . 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 com-
      puting 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 fire-
      wall . . . . The firewall blocks unsolicited messages
      to the host computer . . . ; an example of an unso-
      licited message to the host computer is: an access
      request from a remote computer. The present in-
      vention 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 parame-
      ters for the remote to the host, and instructs the host
      to establish communication with the remote. In
      contrast, Kiwimagi has its security host send pa-
      rameters for the host to the remote, so that the re-
      mote 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: 11     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 initia-
     tive to establish a connection to the host. . . . Ki-
     wimagi’s remote request[s] access from the host, so
     there is no need for the host to establish a connec-
     tion 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 limita-
 tion (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 Ki-
 wimagi’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 distinc-
 tion 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: 12     Filed: 10/07/2020

 12                               ROUTE1 INC.   v. AIRWATCH LLC

 remote as “request[ing]” access, J.A. 5302, just how it de-
 scribes 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 sup-
 ports the district court’s construction of the instruction lim-
 itation 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 construc-
 tion. Because Route1 does not dispute noninfringement
 under that construction, we affirm the district court’s grant
 of summary judgment of noninfringement.
                         AFFIRMED