Trend Micro Inc. v. Cupp Computing As

N OTE: 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 J OSEPH P ANIKOWSKI, III, DLA Piper LLP
(US), San Diego, CA, argued for appellant. Also repre-
sented by ROBERT B UERGI, MARK D. F OWLER, East Palo
Alto, CA.
Case: 20-2237 Document: 53 Page: 1 Filed: 10/25/2022

-- 1 of 13 --

TREND MICRO INC. v. CUPP COMPUTING AS 2
J AMES R. HANNAH , Kramer Levin Naftalis & Frankel
LLP, Redwood Shores, CA, argued for appellee. Also rep-
resented by P AUL J. ANDRE; CRISTINA MARTINEZ, J EFFREY
P RICE , New York, NY.
BENJAMIN T. HICKMAN, Office of the Solicitor, United
States Patent and Trademark Office, Alexandria, VA, for
intervenor. Also represented by K AKOLI CAPRIHAN,
T HOMAS W. K RAUSE, F ARHEENA Y ASMEEN RASHEED.
______________________
Before D YK, T ARANTO, and STARK, Circuit Judges.
T ARANTO, 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: 2 Filed: 10/25/2022

-- 2 of 13 --

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: 3 Filed: 10/25/2022

-- 3 of 13 --

TREND MICRO INC. v. CUPP COMPUTING AS 4
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: 4 Filed: 10/25/2022

-- 4 of 13 --

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: 5 Filed: 10/25/2022

-- 5 of 13 --

TREND MICRO INC. v. CUPP COMPUTING AS 6
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: 6 Filed: 10/25/2022

-- 6 of 13 --

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: 7 Filed: 10/25/2022

-- 7 of 13 --

TREND MICRO INC. v. CUPP COMPUTING AS 8
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: 8 Filed: 10/25/2022

-- 8 of 13 --

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: 9 Filed: 10/25/2022

-- 9 of 13 --

TREND MICRO INC. v. CUPP COMPUTING AS 10
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: 10 Filed: 10/25/2022

-- 10 of 13 --

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: 11 Filed: 10/25/2022

-- 11 of 13 --

TREND MICRO INC. v. CUPP COMPUTING AS 12
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: 12 Filed: 10/25/2022

-- 12 of 13 --

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
Case: 20-2237 Document: 53 Page: 13 Filed: 10/25/2022

-- 13 of 13 --