Court Opinion

ID: 8405144
Source: CourtListenerOpinion
Date Created: 2022-10-25 15:00:56.461761+00
Date Added: 2024-06-11T16:46:48.950010
License: Public Domain

Case: 20-2237   Document: 53     Page: 1    Filed: 10/25/2022

        NOTE: This disposition is nonprecedential.

   United States Court of Appeals
       for the Federal Circuit
                 ______________________

                 TREND MICRO INC.,
                     Appellant

                            v.

                CUPP COMPUTING AS,
                      Appellee

  KATHERINE K. VIDAL, UNDER SECRETARY OF
  COMMERCE FOR INTELLECTUAL PROPERTY
    AND DIRECTOR OF THE UNITED STATES
      PATENT AND TRADEMARK OFFICE,
                  Intervenor
            ______________________

                  2020-2237, 2020-2238
                 ______________________

     Appeals from the United States Patent and Trademark
 Office, Patent Trial and Appeal Board in Nos. IPR2019-
 00561, IPR2019-00641.
                  ______________________

                Decided: October 25, 2022
                 ______________________

     STANLEY JOSEPH PANIKOWSKI, III, DLA Piper LLP
 (US), San Diego, CA, argued for appellant. Also repre-
 sented by ROBERT BUERGI, MARK D. FOWLER, East Palo
 Alto, CA.
Case: 20-2237    Document: 53     Page: 2     Filed: 10/25/2022

 2                    TREND MICRO INC.   v. CUPP COMPUTING AS

     JAMES R. HANNAH, Kramer Levin Naftalis & Frankel
 LLP, Redwood Shores, CA, argued for appellee. Also rep-
 resented by PAUL J. ANDRE; CRISTINA MARTINEZ, JEFFREY
 PRICE, New York, NY.

     BENJAMIN T. HICKMAN, Office of the Solicitor, United
 States Patent and Trademark Office, Alexandria, VA, for
 intervenor.   Also represented by KAKOLI CAPRIHAN,
 THOMAS W. KRAUSE, FARHEENA YASMEEN RASHEED.
                 ______________________

     Before DYK, TARANTO, and STARK, Circuit Judges.
 TARANTO, Circuit Judge.
     Trend Micro Inc. filed petitions in the Patent and
 Trademark Office seeking inter partes reviews (IPRs) un-
 der 35 U.S.C. §§ 311–19 of certain claims of two patents
 owned by CUPP Computing AS—claims 1, 7, and 16 of U.S.
 Patent No. 8,365,272 and claims 1, 6, and 7 of U.S. Patent
 No. 9,756,079. The PTO’s Patent Trial and Appeal Board,
 after instituting and conducting the requested reviews, is-
 sued final written decisions holding each claim 1 to be un-
 patentable but rejecting Trend Micro’s challenges to claims
 7 and 16 of the ’272 patent and claims 6 and 7 of the ’079
 patent. Trend Micro Inc. v. CUPP Computing AS, No.
 IPR2019-00561, 2020 WL 3709007, at *1 (P.T.A.B. July 6,
 2020) (IPR561 Decision); Trend Micro Inc. v. CUPP Com-
 puting AS, No. IPR2019-00641, 2020 WL 3697863, at *1
 (P.T.A.B. July 6, 2020) (IPR641 Decision). Trend Micro ap-
 peals the Board’s holding regarding claims 7 and 16 of the
 ’272 patent and claim 7 of the ’079 patent. We vacate the
 Board’s final written decisions on each appealed claim and
 remand.
Case: 20-2237    Document: 53      Page: 3    Filed: 10/25/2022

 TREND MICRO INC.   v. CUPP COMPUTING AS                    3

                               I
                               A
      The ’272 patent is the grandparent of the ’079 patent,
 so we cite only to the former’s specification (replicated in
 relevant part in the latter). The specification discusses as-
 pects of communication between (a) a computer (or a par-
 ticular application on the computer) that is part of a
 particular network (e.g., the computer’s home network) and
 (b) computers or applications outside that network (e.g., on
 a public network). In particular, it recognizes that such a
 computer or application may have an “internal” (e.g., home-
 network) address that, for one or more reasons, should not
 be included as the source (originating) address in a commu-
 nication sent outside that network.
      Computers often communicate with one another using
 packets that adhere to an Internet Protocol, i.e., using IP
 packets. Such a packet includes a header that contains a
 source IP address and a destination IP address, which typ-
 ically identify the source and destination computers. The
 packet may also include source and destination port num-
 bers to identify source and destination applications within
 the source and destination computers. IP addresses and
 port numbers are important for reliably communicating, by
 initial message and reply, between the source and intended
 destination.
     Such reliable communication can be impaired when a
 computer that is part of a local (home) network is assigned
 an IP address that is unique within that network (for use
 in internal-to-the-network communication) but that is not
 unique within a broader public network (because another
 computer outside the local network may be using it). To
 deal with the problem, and its counterpart problem for non-
 unique port numbers, when a packet from such a local-net-
 work computer is destined for an external computer, the
 source’s internal-network IP address and port number in
 the outgoing packet are often translated, before leaving the
Case: 20-2237    Document: 53     Page: 4      Filed: 10/25/2022

 4                    TREND MICRO INC.    v. CUPP COMPUTING AS

 local network, and replaced with a public-source IP address
 and port number that are (at the time) unique within the
 public network. This process is referred to as network ad-
 dress translation (NAT) and port address translation
 (PAT)—collectively, NPAT. Such translations can achieve
 the uniqueness needed for reply communication by the ex-
 ternal computer and can protect the security and privacy
 of the internal-network computer and application ad-
 dresses by situating the NPAT-processing unit as a firewall
 intermediary in the line of reply communication.
     Computers must obtain public IP addresses from some-
 where, and there are various means for doing so. For ex-
 ample, a computer administrator could manually assign an
 IP address. Commonly, though, computers use Dynamic
 Host Configuration Protocol (DHCP) to get an IP address,
 for use as a source address in outgoing packets, within a
 given network. Under DHCP, computers request IP ad-
 dresses for use as public-source IP addresses in outgoing
 packets and receive (potentially renewable) leases for ad-
 dresses for set times.
     The parties agree that claims 7 and 16 of the ’272 pa-
 tent and claim 7 of the ’079 patent deal specifically with
 outgoing communications from a computer application to
 addresses in networks that are external to the originating
 network, with such communications including a source ad-
 dress (useful to enable an eventual reply) and a destination
 address. In particular, the claims recite “dynamically iso-
 lating” the internal address of a computer application from
 an external network by translating the application’s inter-
 nal address so as to include a different origination address
 in the message sent to a computer outside the home net-
 work.
     Claim 16 of the ’272 patent reads:
         16. A method within a computer of processing
     outgoing data, the method comprising:
Case: 20-2237    Document: 53      Page: 5   Filed: 10/25/2022

 TREND MICRO INC.   v. CUPP COMPUTING AS                    5

         receiving the outgoing data from an applica-
     tion, the application being associated with an in-
     ternal address;
         translating, using a network address transla-
     tion engine within the computer, the internal ad-
     dress into a public address;
         routing, using a driver within the computer, at
     least a subset of the outgoing data to an external
     network using the public address, thereby dynami-
     cally isolating the internal address from the exter-
     nal network; and
         providing, using a network interface within the
     computer, the subset of the outgoing data to the ex-
     ternal network.
 ’272 patent at col. 26, lines 37–48 (emphasis added). Claim
 7 of the ’079 patent reads:
         7. A system comprising:
         a network interface configured to be coupled to
     an external network;
         a firewall in communication with the network
     interface, the firewall configured to perform both
     network-level security and application-level secu-
     rity on incoming data packets, the firewall being
     further configured to reject the incoming data
     packets if the incoming data packets include mali-
     cious content according to a security policy, the
     firewall being configured to allow the incoming
     data packets to pass to one or more applications if
     the incoming data packets do not include malicious
     content according to the security policy;
         a computer system in communication with the
     firewall, the computer system having one or more
     applications associated with at least one applica-
     tion address, the computer system being
Case: 20-2237    Document: 53      Page: 6    Filed: 10/25/2022

 6                    TREND MICRO INC.   v. CUPP COMPUTING AS

     configured to send to the firewall outgoing data
     packets including an application identifier identi-
     fying a particular application of the one or more
     applications to the firewall; and
         an address translation engine configured to
     translate the at least one application address asso-
     ciated with the particular application of the one or
     more applications to an external address, thereby
     dynamically isolating the particular application of
     the one or more applications from the external net-
     work.
 ’079 patent, col. 26, lines 4–29 (emphasis added). Claim 7
 of the ’272 patent, col. 25, lines 34–57, is a system claim
 that is similar, for purposes of these appeals, to claim 7 of
 the ’079 patent. And the parties have not shown that the
 “dynamically isolating” limitations of the three claims at
 issue differ from each other in any way material to these
 appeals, so we use the singular and refer to the “dynami-
 cally isolating” limitation.
                              B
     In its IPR petitions, Trend Micro asserted that the
 claims are unpatentable under 35 U.S.C. § 103 (2008) 1 be-
 cause their subject matter would have been obvious, at the
 relevant priority date in 2007, over certain combinations of
 prior-art references that include WO2006/069041 (Sikdar),
 which was published on June 29, 2006, and is undisputedly
 prior art. In addressing the “dynamically isolating”

     1   The parties do not dispute the Board’s determina-
 tion, IPR561 Decision at *6 n.5; IPR641 Decision at *6 n.6,
 that, for both patents at issue, the applicable version of
 § 103 is the version pre-dating the Leahy-Smith America
 Invents Act, Pub. L. No. 112-29, § 3(n)(1), 125 Stat. 293
 (2011).
Case: 20-2237     Document: 53     Page: 7    Filed: 10/25/2022

 TREND MICRO INC.   v. CUPP COMPUTING AS                     7

 limitation of claims 7 and 16 of the ’272 patent and claim 7
 of the ’079 patent—the claims on appeal now—Trend Micro
 asserted that Sikdar teaches that limitation. See IPR561
 Decision at *13–15, 19–20; IPR641 Decision at *19–21. In
 ultimately rejecting Trend Micro’s challenge to these three
 claims, the Board’s sole stated basis was that Trend Micro
 failed to show that teaching in Sikdar. IPR561 Decision at
 *13–15, 19–20; IPR641 Decision at *19–22. 2
      In reaching that conclusion, the Board relied on a claim
 construction now accepted as correct by both parties. The
 Board construed “dynamically isolating” in its institution
 decisions sua sponte (applying the standard of Phillips v.
 AWH Corp., 415 F.3d 1303 (Fed. Cir. 2005) (en banc)), and
 it stated in its final written decisions that it was maintain-
 ing its earlier construction. J.A. 2139–41; IPR561 Decision
 at *7–10. It construed the phrase “as including the use of
 DHCP or other source of addresses in connection with a
 NAT engine to translate IP addresses.” IPR561 Decision
 at *8. It added that the phrase “further refer[s] to an oper-
 ation that occurs ‘when and as needed.’” Id. With respect
 to the latter aspect, the Board explained that the term “dy-
 namically” modifies “isolating,” id. at *9, so that transla-
 tion that occurs “beforehand, at device configuration[,] . . .
 would not be dynamic,” id. The parties accept that con-
 struction on appeal. Opening Br. at 26–28; Response Br.
 at 18; Reply Br. at 5; Oral Arg. at 12:31–13:20.
     The issue on appeal is whether, as the Board ulti-
 mately found, Sikdar fails to disclose what that construc-
 tion requires.   Sikdar discloses in relevant part a
 Reconfigurable Semantic Processor (RSP) capable of per-
 forming NAT and PAT. J.A. 836–39. The RSP, Sikdar

     2   The Board’s construction of “dynamically isolating”
 and its obviousness analysis with respect to this claim lim-
 itation are the same in the two IPRs. We hereafter cite
 only to the Board’s rulings in IPR2019-00561.
Case: 20-2237     Document: 53      Page: 8    Filed: 10/25/2022

 8                     TREND MICRO INC.   v. CUPP COMPUTING AS

 teaches, “can be programmed for NAT/PAT operations that
 convert IP addresses and/or port numbers for packets trav-
 eling thru the firewall 1062 between public IP addresses
 that are used for transporting the packet over public net-
 work 12 and private IP addresses that are used for trans-
 porting the packet over the private network 24.” J.A. 836.
 The RSP in Sikdar includes a Semantic Processing Unit
 (SPU). J.A. 795–96, 914. Sikdar states that the SPU “gen-
 erates the public IP address and port number for the
 packet” and that “the public IP address is usually the IP
 address assigned to firewall 1062.” J.A. 838. Sikdar fur-
 ther states, regarding that embodiment, that there are typ-
 ically “multiple unique private IP addresses associated
 with different network processing devices operating in pri-
 vate network 24” and that “only one, or a few, public IP
 addresses may be used to represent the multiple private IP
 addresses.” Id. Sikdar also discloses an alternative em-
 bodiment, in which one-to-one mapping occurs, disclosing
 that “one or more IP addresses have an associated individ-
 ual public IP address.” J.A. 837.
      In finding that Sikdar does not disclose the “dynami-
 cally isolating” limitation, the Board found that Sikdar
 uses the same public IP address, i.e., the address of the fire-
 wall, as the source (originating) address for all outgoing
 communications and does not disclose the source from
 which Sikdar obtains that public IP address. IPR561 De-
 cision at *14. In making that determination, the Board
 found that the SPU in Sikdar does not “actually” generate
 the public IP address used as the source address in out-
 going packets. Id. Based on those findings, the Board de-
 termined that Sikdar does not disclose the translation of IP
 addresses “using DHCP or other source of addresses.” Id.
 The Board also noted that Sikdar does not satisfy the “dy-
 namically isolating” limitation because its “public IP ad-
 dress is not determined ‘on the fly’” and because, “[i]nstead,
 the same firewall IP address is used.” Id.
Case: 20-2237    Document: 53       Page: 9   Filed: 10/25/2022

 TREND MICRO INC.   v. CUPP COMPUTING AS                    9

                               C
     Trend Micro timely appealed the Board’s final written
 decisions.    We have jurisdiction under 28 U.S.C.
 § 1295(a)(4) and 35 U.S.C. §§ 141(c), 319.
                               II
     We review the Board’s legal conclusions de novo and its
 factual findings for substantial-evidence support. Dynamic
 Drinkware, LLC v. National Graphics, Inc., 800 F.3d 1375,
 1378 (Fed. Cir. 2015). “A finding is supported by substan-
 tial evidence if a reasonable mind might accept the evi-
 dence to support the finding.” Id. Obviousness is a
 question of law based on underlying findings of fact, includ-
 ing what the prior art teaches. See, e.g., In re Warsaw Or-
 thopedic, Inc., 832 F.3d 1327, 1329-31 (Fed. Cir. 2016).
      As we have noted, the parties agree that the Board’s
 express construction of the claims—requiring “the use of
 DHCP or other source of addresses in connection with a
 NAT engine to translate IP addresses” and “an operation
 that occurs ‘when and as needed’”—is correct. We need
 only decide whether substantial evidence supports the
 Board’s finding that Sikdar does not disclose “dynamically
 isolating” under that construction. See Seal-Flex, Inc. v.
 Athletic Track & Court Construction, 172 F.3d 836, 842
 (Fed. Cir. 1999) (accepting as correct a construction
 adopted by the district court that the parties did not dis-
 pute on appeal). We conclude that the Board’s finding is
 not supported by substantial evidence. We do not see, and
 CUPP has not pointed us to, any evidence that would per-
 mit a reasonable finding that Sikdar fails to teach “dynam-
 ically isolating” under the agreed-on construction. We
 therefore reject that Board finding regarding Sikdar, as we
 have done in other cases where the evidence presented
 could not reasonably support a Board finding. See, e.g.,
 Becton, Dickinson & Co. v. Baxter Corp. Englewood, 998
 F.3d 1337, 1340–42 (Fed. Cir. 2021); Corning v. Fast Felt
Case: 20-2237    Document: 53      Page: 10    Filed: 10/25/2022

 10                    TREND MICRO INC.   v. CUPP COMPUTING AS

 Corp., 873 F.3d 896, 901–03 (Fed. Cir. 2017); Belden Inc. v.
 Berk-Tek LLC, 805 F.3d 1064, 1077 (Fed. Cir. 2015).
     Sikdar clearly discloses “the use of DHCP or other
 source of addresses in connection with a NAT engine to
 translate IP addresses.” This claim construction does not
 require the use of DHCP or a source that is, in some nar-
 rowing way, similar or comparable to DHCP. By its broad
 terms, this construction simply requires any source of ad-
 dresses—“DHCP or other source of addresses.” Sikdar
 teaches this aspect of the claim construction in several
 ways: It discloses that the SPU “generates” the public IP
 address, says that this address is “usually” the address “as-
 signed to” the firewall, and describes, in an alternative em-
 bodiment, a one-to-one mapping of private and public
 addresses. J.A. 837–38. These disclosures teach a “source
 of addresses in connection with a NAT engine to translate
 IP addresses.”
      In finding otherwise, the Board found that Sikdar does
 “not actually” generate the public IP address because “the
 public IP address is simply the firewall’s public IP ad-
 dress,” IPR561 Decision at *14, so that “Sikdar discloses
 using the same IP address (the IP address of the firewall)
 for all packets traveling from the private network to the
 public network,” id. But even if Sikdar were limited to us-
 ing an unvarying public IP address (of the firewall), it still
 falls within the claim construction, which nowhere re-
 quires variability of the swapped-in public IP address from
 packet to packet. Indeed, the Board explicitly rejected
 CUPP’s initial argument to build into a claim construction
 a requirement that would “involve[] addresses that are not
 ‘predetermined.’” Id. at *9. After all, as the Board ex-
 plained, “dynamic” in the claim phrase refers to the act of
 translating (converting, swapping), not to variability of re-
 placement addresses among packets. Id.
     The Board’s finding that, in Sikdar, “the public IP ad-
 dress is simply the firewall’s public IP address,” id. at *14,
Case: 20-2237    Document: 53      Page: 11    Filed: 10/25/2022

 TREND MICRO INC.   v. CUPP COMPUTING AS                    11

 is also unsupported by substantial evidence. The referred-
 to portion of Sikdar says only that the swapped-in address
 is “usually” the public address assigned to the firewall—
 not always. J.A. 838. And what “usually” allows, and in-
 deed suggests, an alternative embodiment in Sikdar makes
 explicit. Specifically, Sikdar teaches what the Board
 acknowledges was a one-to-one-mapping embodiment.
 IPR561 Decision at *14 n.11. The Board dismissed that
 embodiment as irrelevant, id., but it offered, and CUPP has
 furnished, no reasonable basis for that dismissal. In that
 embodiment, each private address within Sikdar’s private
 network is associated with a corresponding public address
 for use on the public network. J.A. 837. That embodiment
 teaches the use of different swapped-in addresses where
 there is more than one private address.
     Sikdar also discloses that translation occurs “when and
 as needed.” Sikdar discloses that translation (i.e., the
 swapping of addresses) occurs when “a device 1078 operat-
 ing in private network 24 . . . send[s] packet 1072 through
 firewall 1062 to a destination public network 12.” Id. In
 particular, the RSP “receives packet 1072 from local device
 1078 in private network 24 that contains a private IP ad-
 dress 1070,” and “[i]f the packet 1072 is directed to an end-
 point 1056 in public network 12, the RSP 100 converts the
 private IP address 1070 into a public address 1052 that is
 used to route packet 1050 over public network 12 to end-
 point 1056.” Id. This conversion of an address, described
 precisely as taking place when an outgoing packet is in
 transit, occurs “when and as needed”—as packets pass
 through the RSP and “if” the packet containing a private
 source IP address is destined for a public network.
     The Board lacked a reasonable basis (and hence lacked
 substantial evidence on which) to find that Sikdar fails to
 teach this aspect of the claim construction. The Board, for
 this aspect of the claim construction as for the “source of
 address” aspect, relied on its finding that “the public IP ad-
 dress assigned to the packets is the IP address of the
Case: 20-2237    Document: 53      Page: 12    Filed: 10/25/2022

 12                    TREND MICRO INC.   v. CUPP COMPUTING AS

 firewall,” and it added that the “public IP address is not
 determined ‘on the fly.’” IPR561 Decision at *14. But this
 reasoning, besides overlooking the “usually” and one-to-
 one-mapping aspects of Sikdar (discussed just above), de-
 parts from the simple “when and as needed” language of
 the unchallenged claim construction. That language refers
 only to the timing of the act of conversion for an outgoing
 communication, i.e., the act of replacing a private-source
 address in a packet by a different, public address as pack-
 ets pass through the translation engine. Sikdar plainly
 teaches that process. The language “when and as needed”
 does not address how many different public addresses are
 used as the replacements or when the replacements are
 identified (as opposed to when they are actually swapped
 in).
     The Board did not cite, and CUPP has not pointed us
 to, any expert testimony that would permit a reasonable
 finding that Sikdar fails to teach “dynamically isolating”
 under the agreed-on construction. CUPP’s expert, Dr.
 Medvidovic, opined that “the Board should find the [’]272
 [p]atent valid over the cited prior art” because Trend Mi-
 cro’s expert, Dr. Jakobsson, “fail[ed] to provide any analy-
 sis that would support a finding that the cited reference
 disclosed or suggested the use of DHCP or a similar dy-
 namic source of addresses in connection with NAT transla-
 tion.” J.A. 2289–90 (emphasis added). Dr. Medvidovic’s
 reasoning rests on a claim construction that is contrary to
 the one the Board adopted (and CUPP does not challenge):
 His rationale mistakenly treats “dynamic” as modifying
 “source” rather than “isolating”; and it requires a source
 “similar” to DHCP. Dr. Medivodovic’s declaration thus
 does not support the Board’s finding.
     Dr. Jakobsson, for his part, testified that “the public IP
 address is generated somewhere.” J.A. 2904. That testi-
 mony certainly does not point against the evidence, dis-
 cussed above, showing that Sikdar teaches what the claim
 construction requires.      It therefore cannot provide
Case: 20-2237    Document: 53       Page: 13   Filed: 10/25/2022

 TREND MICRO INC.   v. CUPP COMPUTING AS                   13

 substantial-evidence support for the Board’s finding. That
 is so whether or not the Board reasonably characterized Dr.
 Jakobsson’s testimony in this respect as “conclusory,” add-
 ing that the testimony does not identify “how the public IP
 address disclosed in Sikdar, namely, the IP address of the
 firewall, is sourced.” IPR561 Decision at *14. Even if we
 accept the characterization, substantial evidence is lacking
 for the Board’s finding about Sikdar. The Board relied on
 the mistaken firewall-only reading of Sikdar and imported
 a requirement of identifying the address source, rather
 than simply having an address source; and it disregarded
 the facial sufficiency of Dr. Jakobsson’s point that, of
 course, there must be a source (whose character is not lim-
 ited to one similar to DHCP).
      For the foregoing reasons, we conclude that no substan-
 tial evidence supports the Board’s finding that Sikdar does
 not disclose “dynamically isolating.” Rather, as we have
 explained, Sikdar does teach that requirement under the
 Board’s express construction, which the parties accept.
 Trend Micro does not, however, ask for reversal of the final
 written decisions as to the appealed claims on this basis.
 It seeks only vacatur and remand to allow the Board to ad-
 dress issues (relevant to the appealed claims) that the
 Board has not yet addressed. See Trend Micro Opening Br.
 at 55; Response Br. at 38–39; Oral Arg. at 0:55–3:01. We
 follow that course, with the claim construction of “dynami-
 cally isolating” and Sikdar’s teaching of that claim limita-
 tion now settled.
                              III
     The Board’s final written decisions on each appealed
 claim is vacated, and the case is remanded for further pro-
 ceedings consistent with this opinion.
     Costs awarded to Trend Micro.
                VACATED AND REMANDED