CUPP Computing AS

Patent Trials and Appeals Board

Jul 6, 2020

IPR2019-00641 (P.T.A.B. Jul. 6, 2020)

Trials@uspto.gov Paper No. 26
571.272.7822 Date: July 6, 2020

UNITED STATES PATENT AND TRADEMARK OFFICE
____________

BEFORE THE PATENT TRIAL AND APPEAL BOARD
____________

TREND MICRO INC.,
Petitioner,

v.

CUPP COMPUTING AS,
Patent Owner.
_______
______________

IPR2019-00641
Patent 9,756,079 B2
___________

Before THOMAS L. GIANNETTI, GARTH D. BAER, and
SHARON FENICK, Administrative Patent Judges.

GIANNETTI, Administrative Patent Judge.

JUDGMENT
Final Written Decision
Determining A Challenged Claim Unpatentable
35 U.S.C. § 318(a)

IPR2019-00641
Patent 9,756,079 B2
2

I. INTRODUCTION
A. Background
Trend Micro Inc. (“Petitioner”) filed a Petition requesting inter partes
review of claims 1, 6, and 7 (the “challenged claims”) of U.S. Patent
No. 9,756,079 B2 (Ex. 1001, the “’079 patent”). Paper 1 (“Pet.”). Patent
Owner (CUPP Computing AS) filed a Preliminary Response. Paper 6
(“Prelim. Resp.”).
After considering the arguments presented in Patent Owner’s
Preliminary Response, we determined that the information presented in the
Petition established that there was a reasonable likelihood that Petitioner
would prevail with respect to at least one challenged claim. Pursuant to 35
U.S.C. § 314, we instituted this inter partes review as to all of the
challenged claims and all grounds raised in the Petition. Paper 7
(“Institution Dec.”).
Following institution, Patent Owner filed a Response. Paper 11 (“PO
Resp.”). Subsequently, Petitioner filed a Reply (Paper 13, “Pet. Reply”) and
Patent Owner filed a Sur-reply (Paper 19, “Sur-reply”). In addition, Patent
Owner filed a Motion to Exclude. Paper 20. We deny that motion in a
separate Order entered concurrently.
On April 20, 2020, we held a consolidated oral hearing with IPR2019-
00561, involving related U.S. Patent No. 8, 365,272, and a transcript of the
hearing is included in the record. Paper 25 (“Hearing Tr.”).
We have jurisdiction under 35 U.S.C. § 6. This decision is a Final
Written Decision under 35 U.S.C. § 318(a). For the reasons we identify
below, we determine that Petitioner had demonstrated by a preponderance of
the evidence that claim 1 of the ’079 patent is unpatentable. We further
IPR2019-00641
Patent 9,756,079 B2
3

determine that Petitioner has not demonstrated that claims 6 and 7 are
unpatentable.
B. Related Proceedings:
Petitioner identifies the following district court proceedings
concerning the ’079 patent: CUPP Cybersecurity LLC et al. v. Trend Micro,
Inc., et al., No. 3:18-cv-01251 (N.D. Tex.); CUPP Cybersecurity LLC v.
Symantec Corp., No. 3:18-cv-01554 (N.D. Tex.); and Symantec Corp. v.
CUPP Cybersecurity LLC, et al., No. 3:18-cv-04720 (N.D. Cal.). Pet. 1.
Patent Owner identifies the following additional action involving the ’079
patent: CUPP Cybersecurity LLC et al. v. Symantec Corp.,
3:19-cv-00298 (N.D. Cal.). Paper 3, 1.
C. Real Party-in-Interest
The Petition identifies Trend Micro as the real party-in-interest.
Pet. 1. Patent Owner in its Preliminary Response does not contest this
identification. Patent Owner identifies CUPP Computing AS as the real
party-in-interest. Paper 3, 1.
D. Description of Relevant Internet Technology
1. TCP/IP
Because the Internet is a global network of computers, each computer
connected to the Internet has a unique address. Ex. 1008 (“How Does the
Internet Work?”), 1. This address is known as an IP (Internet Protocol)
address. Id.
When connecting to the Internet through an Internet Service Provider
(ISP), a computer is usually assigned a temporary IP address for the duration
of a session. Id. at 2. If connecting to the Internet from a local area network
(LAN), a computer might have a permanent IP address or it might obtain a
IPR2019-00641
Patent 9,756,079 B2
4

temporary one from a DHCP (Dynamic Host Configuration Protocol) server.
See discussion of DHCP infra. In any case, if connected to the Internet, a
computer has a unique IP address. Ex. 1008, 2.
When computers communicate over the Internet, they typically use a
suite of protocols referred to as TCP/IP. Id. The protocols are often
described as layers in a “stack.” Id. The TCP (Transmission Control
Protocol) layer directs packets to a specific application on a computer using
a “port number.” Id. at 10. Ports can be thought of as separate channels on
each computer. Id. When a packet arrives at a computer from the Internet,
the TCP layer decides which application receives the packet based on a port
number. Id. In contrast, the IP (Internet Protocol) layer directs packets to a
specific computer using its IP address. Id. at 2. Thus, the purpose of the IP
layer is using the IP address to route packets to other computers, not
applications. Id. at 11.
2. NAT/PAT
Network Address Translation (NAT) is a method by which IP
addresses are “mapped” or translated from one realm to another, in an
attempt to provide transparent routing to hosts. Ex. 1011 (“IP Network
Address Translator (NAT) Terminology and Considerations,” Request for
Comments (RFC)1 2663, August 1999), 1. “The need for IP address
translation arises when a network’s internal IP addresses cannot be used
outside the network either because they are invalid for use outside, or
because the internal addressing must be kept private from the external
network.” Id. at 2.

1 An RFC is a memo published by the Internet Engineering Task Force
(IETF). RFCs contain technical and organizational notes about the Internet.
See https://www.ietf.org/standards/rfcs/.
IPR2019-00641
Patent 9,756,079 B2
5

NAPT (Network Address Port Translation) “extends the notion of
translation” by also translating transport identifiers (e.g., TCP port numbers).
Id. at 11. “This allows the transport identifiers of a number of private hosts
to be multiplexed into the transport identifiers of a single external address.”
Id. Thus, NAPT allows a set of hosts to share a single external address. Id.
NAPT is the combination of NAT and Port Address Translation (PAT).
Ex. 1021 (Jakobsson Decl.) ¶ 61.
3. DHCP
Newton’s Telecom Dictionary 244 (20th ed. March 2004) provides the
following description of this protocol: “DHCP is a TCP/IP protocol that
enables PCs and workstations to get temporary or permanent IP addresses
(out of a pool) from centrally-administered servers.” Ex. 3001.
E. The ’079 Patent
The ’079 patent is titled “System and Method for Providing Network
and Computer Firewall Protection with Dynamic Address Isolation to a
Device.” Ex. 1001, (54). The patent relates generally to computer security,
and more particularly, describes a system and method for providing data and
device security between external and host devices on a computer network.
Id. at 1:25–28.
According to the ’079 patent, prior hardware-based firewalls made use
of NAT to translate the IP addresses of the internal computers on a network
into public IP addresses, thus hiding the IP addresses of the internal
computers. Id. at 18:59–19:12; Fig. 17. According to the ’079 patent,
hardware-based firewalls were an improvement over PC software-based
firewalls running on internal computers. Id. at 19:13–18.
IPR2019-00641
Patent 9,756,079 B2
6

1. “Dynamic Isolation” Embodiment
The ’079 patent describes an embodiment under the heading
“Dynamic Isolation.” Ex. 1001, 18:59–21:46. The description of this
embodiment begins with a discussion of Figure 18 of the ’079 patent.
Figure 18 shows a “prior art” network system having a software-based
firewall. Id. at 19:19–20. Figure 18 follows:

Figure 18 is a block diagram illustrating prior art network system
1800 having a software-based firewall. Id. at 19:19–20. The network
system includes external network 1805 (such as the Internet), one or more
Network Interface Cards (NICs) 1810 (denoted as 1810a, 1810b, . . . 1810n),
and Network Driver Interface Specification (NDIS) driver 1815. Id. at
19:20–23.
IPR2019-00641
Patent 9,756,079 B2
7

As described in the patent, prior art software-based firewall networks
such as that shown in Figure 18 include NDIS 1815 as an interface between
Open Systems Interconnection (“OSI”) layer 2 (the data link layer) and OSI
layer 3 (the network layer),2 as well as intermediate driver 1820, software-
based firewall 1825, operating system 1830 containing the TCP/IP protocol
suite, and one or more applications 1835. Id. at 19:23–30.
In operation, the intermediate driver directs traffic arriving to the
software-based firewall. The firewall decides whether to allow, deny, or
reject the traffic and permits only the allowed traffic to proceed to the
operating system. Id. at 19:31–36. According to the patent, this prior art
system is disadvantageous in that the IP internal addresses visible to the
external network are the same IP addresses viewed and used by the
applications (i.e., there is no address isolation between the applications and
the external network). Id. at 19:39–43.
Figure 19 of the ’079 patent shows a network system that “performs
dynamic address isolation, in accordance with an embodiment.” Id. at
19:44–46. Figure 19 (annotated by the Board) follows:

2 See Pet. 11–12 for a description of the OSI model.
IPR2019-00641
Patent 9,756,079 B2
8

Figure 19 is described as a block diagram illustrating network system
1900 that performs dynamic address isolation. Ex. 1001, 4:41–42. The
network shown in Figure 19 has the same general configuration as prior art
network 1800 of Figure 18, reproduced supra. That is, the Figure 19
network system (like the network of Figure 18) includes external network
1905 (such as the Internet), one or more network interface devices (NICs)
1910a, 1910b, . . . 1910n, NDIS driver 1915 that acts as an interface between
the OSI data link layer 2 and OSI network layer 3, intermediate driver 1920,
software-based or hardware-based firewall 1925, operating system 1930, and
one or more applications 1935a, 1935b, . . . 1935m. Further, as in Figure 18,
operating system 1930 contains TCP/IP protocol suite 1940. Id. at 19:46–
55.
In contrast to prior art Figure 18, however, in Figure 19, intermediate
driver 1920 includes NAT engine 1945, indicated by the red arrow in the
IPR2019-00641
Patent 9,756,079 B2
9

annotated Figure, that contains a translations table for IP addresses. Id. at
19:55–57.
In operation, intermediate driver 1920 receives all data packets
arriving from NICs 1910 and NDIS driver 1915, and routes each data packet
to NAT engine 1945. NAT engine 1945 uses DHCP (see discussion supra)
to “dynamically isolate the IP addresses of the applications 1935 from the
external network 1905.” Id. at 19:66–20:4.
As shown in Figure 19, “the dynamic NAT engine 1945 translates the
IP address of application 1935 (IP address x) to a different IP address (IP
address z) while interfacing with the NIC, and translates the IP address z
back to the IP address x when sending data to the operating system 1930.
Thus, the intermediate driver 1920 provides IP address z to the external
network 1905, while isolating IP address x from the external network.” Id.
at 20:5–20:12.
After NAT engine 1945 translates the IP address, intermediate driver
1920 directs each incoming data packet to firewall 1925. Id. at 20:18–20.
Firewall 1925 decides whether to allow, deny, or reject the data packets it
receives, and permits only allowed data packets to proceed to operating
system 1930. Id. at 20:20–23. Intermediate driver 1920 receives each
allowed data packet back from firewall 1925 and routes each allowed data
packet to an application 1935. Id. at 20:23–25.
For outgoing data packets, intermediate driver 1920 receives each data
packet from application 1935 and routes each data packet to NAT engine
1945. Id. at 20:26–28. NAT engine 1945 translates the IP address
associated with the data packet as described above. Intermediate driver
1920 then receives each data packet containing the translated IP address
IPR2019-00641
Patent 9,756,079 B2
10

back from NAT engine 1945 and routes each data packet to external network
1905. Id. at 20:28–34.
2. “Hybrid Firewall” Embodiment
A separate embodiment of the ’079 patent is described under the
heading “Hybrid Firewall.” Ex. 1001, 21:48–24:59. The description begins
with a discussion of Figure 20 of the patent. Id. at 21:48–22:12. Figure 20
shows a “prior art” network system “having separate network and personal
firewalls.” Id. at 21:35–36. Figure 20 follows:

Figure 20 shows prior art network system 2000 having separate
network and personal firewalls. Id. at 21:48–49. Network system 2000
includes external network 2005 (such as the Internet), network firewall
2010, and personal computers 2015 (denoted as 2015a, 2015b, etc.). Id. at
21:49–52. Each personal computer 2015 comprises personal firewall 2035
IPR2019-00641
Patent 9,756,079 B2
11

(denoted as 2035a, 2035b, etc.) and application 2040 (denoted as 2040a,
2040b, etc.). Id. at 21:55–58.
Network firewall 2010 comprises first NIC 2020, NAT gateway 2025,
and second NIC 2030. Id. at 21:53–55. In operation, network firewall 2010
uses NAT gateway 2025 to translate the IP address of personal computer
2015a (denoted as IP address x) and the IP address of personal computer
2015b (denoted as IP address y) into public IP address z, and thus hiding the
IP addresses of the personal computers. Id. at 21:45–50. The network
firewall 2010 performs a similar translation on the MAC addresses3 of the
personal computers 2015. Id. at 21:59–64.
According to the ’079 patent, network firewall 2010 in Figure 20
performs security measures such as antivirus, anti-spyware, anti-adware, etc.
“However, because the network firewall 2010 is application insensitive and
at a lower layer of the information stack, its processes for malicious code
detection are limited.” Id. at 21:66–22:6.
Further according to the ’079 patent, personal firewall 2035 also
performs security measures such as antivirus, anti-spyware, anti-adware, etc.
However, “[b]ecause the personal firewall 2035 is application sensitive and
at a higher layer of the information stack, its processes for malicious code
detection can be more thorough and focused.” Id. at 22:7–12.
Figure 21 shows network system 2100 with a “hybrid fire wall.”
Ex. 1001, 22:13–14. Figure 21 follows:

3 The MAC (Media Access Control) address is an identifier assigned to a
computer by its manufacturer. Ex. 1022, 42:6–8.
IPR2019-00641
Patent 9,756,079 B2
12

Figure 21 shows network system 2100 comprising a hybrid firewall
2110 in accordance with an embodiment of the ’079 patent. Id. at 22:13–15.
As in Figure 20, network system 2100 includes external network 2105 (such
as the Internet) and personal computers 2115 (denoted as 2115a, 2115b,
etc.). Id. at 22:15–18.
In contrast to Figure 20, however, Figure 21 shows hybrid
network/personal firewall 2110. The hybrid firewall 2110 comprises first
NIC 2120, NAT engine 2125, and second NIC 2130. Id. at 22:22–23.
In this embodiment, each personal computer 2115 also comprises an
agent 2135 (denoted as 2135a, 2135b, etc.) and one or more applications
2140 (denoted as 2140a, 2140b, etc.). Id. at 22:24–26. In operation, hybrid
firewall 2110 uses NAT engine 2125, which contains a translations table for
IP and MAC addresses, to translate the IP address of personal computer
2115a (denoted as IP address x) and the IP address of personal computer
IPR2019-00641
Patent 9,756,079 B2
13

2115b (denoted as IP address y) into a public IP address z, thus hiding the IP
addresses of the personal computers. Id. at 22:31–37. The network firewall
2110 performs a similar translation on the MAC addresses of personal
computers 2115. Id. at 22:37–39.
In contrast to the prior art firewall shown in Figure 20, however,
hybrid firewall 2110 is capable of performing both the network firewall and
personal firewall security measures. Because hybrid firewall 2110 is at the
same level as traditional network firewall 2035, it can stop malicious code
before it enters system 2100. Id. at 22:40–44. “Further, because the hybrid
firewall 2110 is application sensitive, the hybrid firewall 2110 can perform
the processes of the traditional personal firewall 2035.” Id. at 22:44–47.
To enable hybrid firewall 2110 to be “application sensitive,” agents
2135 send packets of data to hybrid firewall 2110, “each packet comprising
data identifying the application 2140 associated with the packet.” Id. at
22:48–51. This enables hybrid firewall 2110 to “act as a personal firewall
2035 to handle application-level security.” Id. at 22:51–55.
E. Illustrative Claims
The ’079 patent has 12 claims. Challenged claims 1 and 7 are the
only independent claims. Pet. 3.
Claim 1 recites4:
1. A computer system comprising:
[1.1] at least one processor and memory;
[1.2] an application associated with an application
address;

4 Paragraph numbers in accordance with the Petition have been added to
claims 1 and 7.
IPR2019-00641
Patent 9,756,079 B2
14

[1.3] a network interface coupled to receive incoming data
packets from and transmit outgoing data packets to an external
network;
[1.4] an address translation engine configured to translate
between the application address and an external address; and
[1.5] a driver for automatically forwarding the outgoing
data packets to the address translation engine to translate the
application address to the external address, and for automatically
forwarding the incoming data packets to the address translation
engine to translate the external address to the application address,
[1.6] the driver coupled to transmit the incoming data
packets to a firewall configured to reject the incoming data
packets if the incoming data packets include malicious content
according to a security policy, and allow the incoming data
packets to be forwarded to the application if the incoming data
packets do not include malicious content according to the
security policy.
Ex, 1001, 25:15–36.
Claim 7 recites:
7. A system comprising:
[7.1] a network interface configured to be coupled to an
external network;
[7.2] a firewall in communication with the network
interface, the firewall configured to perform both network-level
security and application-level security on incoming data packets,
the firewall being further configured to reject the incoming data
packets if the incoming data packets include malicious 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;
[7.3] a computer system in communication with the
firewall, the computer system having one or more applications
associated with at least one application address, the computer
system being configured to send to the firewall outgoing data
packets including an application identifier identifying a
IPR2019-00641
Patent 9,756,079 B2
15

particular application of the one or more applications to the
firewall; and
[7.4] an address translation engine configured to translate
the at least one application address associated 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 network.
Id. at 26:4–29 (emphasis added).
Challenged claim 6 depends from claim 1 and is directed to the hybrid
firewall:
6. The computer system of claim 1, wherein the computer
system is configured to send data packets identifying the
application to the firewall, and the firewall is configured to
handle both network-level security and application-level
security.
Id. at 25:48–26:3.
F. References and Other Evidence
The Petition relies on the following references:
1. WO Intern. Pat. Pub No. 2006/069041 A2 (Ex. 1004, “Sikdar”)
2. Fielding, et al., “Hypertext Transfer Protocol--HTTP/1.1,” Network
Working Group Request for Comment 2616 (Ex. 1006, “RFC 2616”)5
3. U.S. Patent App. Pub. No. 2005/0055578 A1 (Ex. 1014, “Wright”)
Pet. 3.
In addition, Petitioner relies on admitted prior art (APA), specifically
Figure 18 of the ’079 patent, reproduced supra, and the accompanying
description in the specification. Pet. 16.

5 The Petition refers to this reference as “Fielding,” after one of the
identified authors. Pet. iii.
IPR2019-00641
Patent 9,756,079 B2
16

Both parties rely on expert testimony. Petitioner has submitted a
Declaration of Dr. Markus Jakobsson (Ex. 1021, “Jakobsson Decl.”), and a
Supplemental Declaration of Dr. Jakobsson (Ex. 1031, “Jakobsson Supp.
Decl.”). Patent Owner has submitted a Declaration of Nenad Medvidovic,
Ph.D. (Ex. 2001, “Medvidovic Decl.”).
In addition, the parties have submitted deposition transcripts for Dr.
Jakobsson (Ex. 2002, “Jakobsson I Dep.”; Ex. 2009, “Jakobsson II Dep.”)
and Dr. Medvidovic (Ex. 1022, “Medvidovic Dep.”).
Finally, Petitioner has submitted Dr. Medvidovic’s declaration (Ex.
1026) and deposition testimony (Ex. 1028) from the district court action
involving the ’079 patent.
G. Asserted Grounds of Unpatentability
Petitioner asserts the challenged claims are unpatentable on the
following grounds:
Claim
Challenged
Statutory Basis6 References
1 35 U.S.C. § 103 Sikdar, APA
1 35 U.S.C. § 103 APA, Sikdar
7 35 U.S.C. § 103 Sikdar, RFC 2616
7 35 U.S.C. § 103 Sikdar, Wright
6 35 U.S.C. § 103 Sikdar. APA, RFC 2616
6 35 U.S.C. § 103 Sikdar, APA, Wright
Pet. 3

6 Because the effective filing date of the application from which the ’079
patent issued was before March 16, 2013, the pre-AIA (“America Invents
Act”) version of 35 U.S.C § 103 applies. Leahy-Smith America Invents Act,
Pub. L. No. 112-29, 125 Stat. 284, 285–88 (2011).
IPR2019-00641
Patent 9,756,079 B2
17

II. PRELIMINARY MATTERS
A. Level of Ordinary Skill
Petitioner contends “[a] person of ordinary skill in the art at the time
of the alleged invention of the ’079 patent (i.e., May 30, 2007) . . . would
have had a bachelors’ degree in computer science, electrical engineering, or
a comparable field of study, plus at least two years of professional
experience with computer security systems and networks, or the equivalent.”
Pet. 8 (citing Jakobsson Decl. ¶ 49).
Patent Owner’s Response does not provide a formulation of the
person of ordinary skill. Dr. Medvdovic, however, provides the following
testimony: “It is my opinion that the person of ordinary skill in the art in the
field of the ‘079 Patent would be someone with a bachelor’s degree in
computer science or related field, and either (1) two or more years of
industry experience and/or (2) an advanced degree in computer science or
related field.” Medvidovic Decl. ¶ 35.
The two formulations differ only slightly. For example, Dr.
Jakobsson is more specific in requiring “experience with computer security
systems and networks, or the equivalent.” Jakobsson Decl. ¶ 49.
Petitioner’s definition is supported by credible expert testimony, is
more consistent with the prior art before us, and is also commensurate with
the level of skill reflected in the ’079 patent. See Okajima v. Bourdeau, 261
F.3d 1350, 1355 (Fed. Cir. 2001) (prior art itself may reflect an appropriate
level of skill). We, therefore, adopt Petitioner’s description. However, we
would reach the same result under either formulation.
IPR2019-00641
Patent 9,756,079 B2
18

B. Claim Construction
The Board applies the same claim construction standard as that
applied in federal courts. 37 C.F.R. § 42.100(b); see also Changes to the
Claim Construction Standard for Interpreting Claims in Trial Proceedings
Before the Patent Trial and Appeal Board, 83 Fed. Reg. 51,340 (Oct. 11,
2018). In this context, claim terms “are generally given their ordinary and
customary meaning” as understood by a person of ordinary skill in the art in
question at the time of the invention. Phillips v. AWH Corp., 415 F.3d 1303,
1312–13 (Fed. Cir. 2005) (en banc). “In determining the meaning of the
disputed claim limitation, we look principally to the intrinsic evidence of
record, examining the claim language itself, the written description, and the
prosecution history, if in evidence.” DePuy Spine, Inc. v. Medtronic
Sofamor Danek, Inc., 469 F.3d 1005, 1014 (Fed. Cir. 2006) (citing Phillips,
415 F.3d at 1312–17). Extrinsic evidence is “less significant than the
intrinsic record in determining ‘the legally operative meaning of claim
language.’” Phillips, 415 F.3d at 1317.
Petitioner did not request any specific constructions in the Petition.
Patent Owner initially addressed only one term. Prelim. Resp. 9.
1. “a mobile device security policy”
Patent Owner contended in the Preliminary Response that this term “is
well-understood in the art and does not require any particular construction.”
Prelim. Resp. 9. Further, Patent Owner asserted “[f]or purposes of this
institution decision, the Board need not determine whether the term ‘a
mobile device security policy’ is limited to the singular.” Id. Petitioner did
not present a construction for this term.
In our Institution Decision, we agreed with Patent Owner that we did
not need to construe this term. Institution Dec. 12. Only terms that are in
IPR2019-00641
Patent 9,756,079 B2
19

controversy need to be construed, and then only to the extent necessary to
resolve a controversy. Vivid Techs., Inc. v. Am. Sci. & Eng’g, Inc., 200 F.3d
795, 803 (Fed. Cir. 1999); Nidec Motor Corp. v. Zhongshan Broad Ocean
Motor Co., 868 F.3d 1013, 1017 (Fed. Cir. 2017).
Neither party has asked us to re-visit this decision, and we do not see
any need to do so to resolve a controversy.
2. “dynamically isolating” (claim 7)
Neither party initially requested construction of the limitation
“dynamically isolating” appearing in claim 7. Ex. 1001, 26:27, Fig. 19.
However, Patent Owner based its opposition to the Petition, in part, on the
alleged failure of the cited references to disclose this feature. See Prelim.
Resp. 1, 20–23. Thus, we provided a construction of this term as it was
necessary to our evaluation of this argument. Institution Dec. 12–14.
As instructed by Phillips, 415 F.2d at 1312, we first looked to the
words of the claim. Institution Dec. 12. We observed that claim element
7.47 recites “an address translation engine configured to translate the at least
one application address associated 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
network.” Id. (citing Ex. 1001, 26:24–29. We further observed that the
language of the claim describes “dynamically isolating” as a result of the
translation by the address translation engine of “at least one application
address associated with the particular application of the one or more
applications to an external address.” Id. at 12–13.

7 References to claim elements in this decision use the paragraph numbering
added to the claims in Section I.E, supra.

IPR2019-00641
Patent 9,756,079 B2
20

We referred to the specification of the ’079 patent, specifically, the
section headed “Dynamic Isolation,” describing Figure 19 of the ’079 patent
as “a network system 1900 that performs dynamic address isolation.” Id. at
13 (citing Ex. 1001, 19:44–45). We further observed that “[c]onsistent with
the language of the claims,” the specification describes the operation of this
network as follows:
In operation, the intermediate driver 1920 receives all data
packets arriving from the NICs 1910 and NDIS driver 1915, and
routes each data packet to the NAT engine 1945. The NAT engine
1945 uses Dynamic Host Configuration Protocol (DHCP) to
dynamically isolate the IP addresses of the applications 1935
from the external network 1905. As shown in FIG. 19, the
dynamic NAT engine 1945 translates the IP address of the
application 1935 (IP address x) to a different IP address (IP
address z) while interfacing with the NIC, and translates the IP
address z back to the IP address x when sending data to the
operating system 1930. Thus, the intermediate driver 1920
provides IP address z to the external network 1905, while
isolating IP address x from the external network.
Id. (citing Ex. 1001, 19:66–20:12).
Thus, relying on the specification and the claims, we construed
“dynamically isolating” as including the use of DHCP or other source of
addresses in connection with a NAT engine to translate IP addresses. Id.
We noted that the specification does not further address the meaning
of the term “dynamically.” Id. at 13. We, therefore, turned to extrinsic
evidence to determine its meaning to those of skill in the art. Id. (citing
Phillips, 415 F.2d at 1318 (“We have especially noted the help that technical
dictionaries may provide to a court to better understand the underlying
technology and the way in which one of skill in the art might use the claim
terms.”) (citations and internal quotes omitted)). We relied on the IBM
Dictionary of Computing 224 (10th ed. Aug. 1993), defining “dynamic” as:
IPR2019-00641
Patent 9,756,079 B2
21

“Pertaining to an operation that occurs at the time it is needed rather than at
a predetermined or fixed time.” Id. at 13–14 (citing Ex. 3002). We also
relied on and quoted the definition of “dynamic” from the Microsoft
Computer Dictionary (5th ed. 2002) as consistent: “The term . . . describes
some action or event that occurs when and as needed.” Id. at 14 (quoting
Ex. 3003). Thus, for our Institution Decision, we construed “dynamically”
as used in “dynamically isolating” in the ’079 patent as further referring to
an operation that occurs “when and as needed.” Id. This is in contrast to
“static” address translation, in which private addresses are “statically
mapped” to specific fixed public addresses. Ex. 1010 (RFC 3022), 3–4.
Patent Owner disputes this construction. PO Resp. 12–14. According
to Patent Owner, a person of ordinary skill “would disagree with this
construction to the extent that ‘dynamically isolating’ can be understood to
encompass any other source of addresses.” Id. at 12. Thus, Patent Owner
proposes the following construction: “[A person of ordinary skill] would
understand that ‘dynamically isolating’ means ‘the use of a dynamic address
protocol to isolate application [sic].’” Id. at 13 (citing Medvidovic Decl.
¶ 50).
Petitioner contends our initial construction is correct and we should
“reject” Patent Owner’s proposed construction. Pet. Reply 2. After
considering Patent Owner’s arguments, we are still persuaded that, for the
reasons given in our Institution Decision and summarized supra, our initial
construction is correct.
Patent Owner does not provide persuasive support for its construction
in the intrinsic record. Thus, Patent Owner does not demonstrate that the
term “dynamic address protocol” appears anywhere in the claims, patent
specification, or the prosecution history. Id. at 3. As Petitioner points out,
IPR2019-00641
Patent 9,756,079 B2
22

in the challenged claims, the term “dynamically” modifies “isolating,” not
“address protocol,” which term does not appear in the claims. Id. Patent
Owner’s construction fails because it would rewrite the claims and
specification to substitute “dynamic address protocol” for “dynamically
isolating.” PO Resp. 14.
We find further support for our construction in the testimony of the
experts for both parties. Patent Owner’s expert, Dr. Medvidovic, agrees that
our construction of “dynamically” alone, as referring to an operation
occurring “when and as needed,” “makes sense” in the context of the patent.
Medvidovic Dep. 33:13–34:6.8 Patent Owner concurs, asserting “a [person
of ordinary skill] would not necessarily disagree with the Board’s
construction of the term ‘dynamically’ to mean ‘an operation that occurs
when and as needed.’” PO Resp. 13 (internal quotes omitted). Dr.
Medvidovic tries to explain this admission by stating “I think the board takes
this term and then uses it in a way that almost invalidates the spirit of this
term in the context of the two patents.” Medvidovic Dep. 34:4–6.
We are not persuaded by this attempted explanation because it is not
supported by the ’079 patent. Instead, we credit the testimony of Dr.
Jakobsson that Patent Owner’s construction “obfuscates, rather than clarifies
the limitation’s meaning.” Jakobsson Supp. Decl. ¶ 14. Dr. Jakobsson
testifies that “dynamic address protocol” has no accepted meaning. Id. This
is consistent with Dr. Medvidovic’s testimony. Medvidovic Dep. 48:15–
50:1. Dr. Medvidovic had difficulty defining “dynamic address protocol,”
testifying that it involves addresses that are not “predetermined.” Id. at

8 Dr. Medvidovic’s testimony refers to related U.S. Patent No. 8,365,272,
which is the subject of IPR2019-00561. Claims 7 and 16 of the ’272 patent,
like claim 1 of the ’079 patent, recite “dynamically isolating.”
IPR2019-00641
Patent 9,756,079 B2
23

48:15–24. Ultimately, he conceded that what “predetermined” means
“would vary depending on context.” Id. at 48:25–49:4.
We are not persuaded by Patent Owner’s argument that under our
construction, “‘dynamically isolating’ can be understood to encompass any
other source of addresses.” PO Resp. 12. Dr. Jakobsson’s testimony on this
issue convinces us that this argument is unavailing. Jakobsson Supp. Decl.
¶ 18. As he explains, “translation could instead occur beforehand, at device
configuration, at which case it would not be dynamic.” Id.
Finally, we address Patent Owner’s criticism that “dynamic isolation”
refers only to “how addresses are selected for translation.” PO Resp. 36–37.
We do not agree with this argument. As Petitioner points out, the word
“dynamically” modifies “isolating,” and refers to when the isolation takes
place. Pet. Reply 3. Our construction of “dynamically isolating,” therefore,
specifies a time of isolating (“when and as needed”) as well as a method.
This definition of “dynamically” is consistent with the extrinsic evidence,
for instance, the technical dictionaries we relied on in our Institution
Decision, which Patent Owner does not challenge. See discussion of Ex.
3002 and Ex. 3003, supra. Thus, our construction of “dynamically
isolating” (in contrast to Patent Owner’s) calls for both “how” and “when”
there is dynamic isolation. It first calls for “the use of DHCP or other source
of addresses in connection with a NAT engine to translate IP addresses.”
This part of the construction describes “how.” It next adds that the isolation
occurs “when and as needed.” This part describes “when.” We find that
Patent Owner’s construction, eliminating the “when,” is inconsistent with
the plain language of the claims.
In sum, we find that our original construction of “dynamically
isolating” is supported by the intrinsic evidence in the ’079 patent, as well as
IPR2019-00641
Patent 9,756,079 B2
24

by the expert testimony and other extrinsic evidence. We disagree with
Patent Owner’s arguments and, therefore, do not adopt Patent Owner’s
proposed construction in place of our original construction.
C. Description of the Prior Art References
1. Sikdar
Sikdar discloses a Reconfigurable Semantic Processor (RSP) used for
implementing a firewall capable of performing network address translation
(NAT) and port address translation (PAT).9 Ex. 1004, 8, 49.10
Figure 20 of Sikdar, which follows, illustrates this operation:

9 The combination of PAT and NAT is sometimes referred to as Network
Address Port Translation (NAPT). Jakobsson Decl. ¶ 61; Ex. 1011 (RFC
2663), 11.
10 Citations to Sikdar (Ex. 1004) refer to the original page numbers and not
the page numbers added by Petitioner.
IPR2019-00641
Patent 9,756,079 B2
25

Figure 20 of Sikdar is a diagram showing how RSP 100 is used for NAT and
PAT. Id. at 4. Figure 20 shows private network 24 and public network 12,
separated by firewall 1062. Id. at 49. RSP 100 can be programmed for
NAT/PAT operations that convert IP addresses and port numbers for packets
traveling thru firewall 1062 between public IP addresses that are used for
transporting the packet over public network 12 and private IP addresses that
are used for transporting the packet over the private network 24. Id. The
private IP addresses and their corresponding port numbers are stored in
lookup table 1064. Id. at 50.11
Sikdar explains that typically there are multiple unique private IP
addresses associated with different network processing devices operating in
private network 24. “However, only one, or a few, public IP addresses may
be used to represent the multiple private IP addresses.” Id. at 49.12 This
protects the identity of internal machines in private network 24 and reduces
the number of public addresses required to map to multiple private addresses
in private network 24. Id. at 49–50.
RSP 100 is also configured to convert public IP address 1058 for an
incoming packet 1061 into private IP address 1074. Id. Private IP address
1074 is then used to route internal packet 1076 to an associated network
processing device 1078 in private network 24. Id. RSP 100 also receives

11 The parties agree that in Figure 20 of Sikdar, the heading of column 1068
in Lookup Table 1064, “Public IP Add[resses], is incorrect and should be
“Private IP Add[resses].” Hearing Tr. 10:13–18; Medvidovic Decl. ¶ 60 n.1.
12 Several words in the sentence starting at the bottom of page 49 of Sikdar
(Page 51 of Exhibit 1004) are illegible. The complete sentence, shown on
Page 128 of Exhibit 1005, is: “This public-private address process protects
the identity of internal machines in private network 24 and reduces the
number of public addresses required to map to multiple private addresses in
private network 24.”
IPR2019-00641
Patent 9,756,079 B2
26

packet 1072 from local device 1078 in private network 24 that contains a
private IP address 1070. Id. If packet 1072 is directed to endpoint 1056 in
public network 12, RSP 100 converts private IP address 1070 into public IP
address 1052 that is used to route packet 1050 over public network 12 to
endpoint 1056. Id.
The details of NAT/PAT operation in Sikdar are shown in Figures 22
and 23. Id. at 4, 51. When packet 1072 is being sent, the RSP replaces
private IP source address 1070 for the packet with public source IP address
1052 that includes associated port number 1054. Id. at 51. For incoming
packet 1061, the RSP replaces the public IP destination address 1058 for the
packet with the identified private IP address 1074. Id. at 52.
2. Wright
Wright is titled “Administration of Protection of Data Accessible by a
Mobile Device.” Ex. 1014, (54). Wright discloses protecting data on a
client mobile computing device by a server computer within an enterprise
network or on a separate mobile computing device. Id. at Abstract. Wright
describes security tools that provide different security policies to be
enforced, based on a location associated with a network environment in
which a mobile device is operating. Id. Wright also describes methods for
detecting the location of the mobile device. Id.
The security tools in Wright also provide for enforcing different
policies based on security features such as the type of connection, wired or
wireless, over which data is being transferred, the operation of anti-virus
software, or the type of network adapter card. Id. The different security
policies provide enforcement mechanisms that may be tailored based upon
the detected location or active security features associated with the mobile
device. Id.
IPR2019-00641
Patent 9,756,079 B2
27

Petitioner relies on Figure 2A of Wright, which follows:

Pet. 59. Figure 2A shows server system 200 that includes memory 242.
Ex. 1014 ¶¶ 53–54. The security system provides security services to
remote mobile client devices. Id. ¶ 53. Memory 242 stores the security
policies and other security information. Id. ¶ 110. The server includes
policy management module 236, which manages security policies. Id. ¶ 55.
3. RFC 2616
This document “specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements.” Ex. 1006, 1. More specifically, the document defines the
protocol referred to as HTTP/1.1. Id. A version of HTTP has been used on
the World Wide Web since 1990. Id. Among other things, RFC 2616
IPR2019-00641
Patent 9,756,079 B2
28

describes the information fields that are available in HTTP requests used to
return web pages to Internet web browsers. Pet. 45–46; Ex. 1006, 31 et seq.
RFC 2616 discloses that HTTP requests may include header-fields,
which allow the client to pass additional information about the client itself to
the server. Ex. 1006, 34–35 (request from client to server), 38–39 (request
header fields). One of these fields, the “User-Agent” field, contains
information about the user agent originating the request. Id. at 145. The
user agent is the client that initiates the request, often browsers. Id. at 9.
III. ANALYSIS OF THE CHALLENGED CLAIMS
The Petition challenges claims 1, 6, and 7 of the ’079 patent.
Petitioner asserts unpatentability of the claims based obviousness.
A. Obviousness
A claim is unpatentable under 35 U.S.C. § 103(a) if the differences
between the claimed subject matter and the prior art are such that the subject
matter, as a whole, would have been obvious at the time the invention was
made to a person having ordinary skill in the art to which said subject matter
pertains. KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 406 (2007).
The question of obviousness is resolved on the basis of underlying
factual determinations, including (1) the scope and content of the prior art;
(2) any differences between the claimed subject matter and the prior art;
(3) the level of skill in the art; and (4) where in evidence, so-called
“secondary considerations” may be found, including commercial success,
long-felt but unsolved needs, failure of others, and unexpected results.
Graham v. John Deere Co., 383 U.S. 1, 17–18 (1966) (“the Graham
factors”).
IPR2019-00641
Patent 9,756,079 B2
29

Patent Owner presents evidence on the fourth Graham factor. PO
Resp. 41–44. We, therefore, consider secondary considerations infra.
B. Claim 1: Sikdar and APA, APA and Sikdar
Petitioner presents this challenge to claim 1 as two separate grounds.
In one (“Ground 1”), Sikdar is the primary reference. Pet. 12–35. In the
second (“Ground 2”), APA is the primary reference. Id. at 35–44.
We focus first on the challenge to claim 1 in which the APA is the
primary reference (Ground 2).
1. APA and Sikdar
Petitioner’s element-by-element analysis of claim 1 in relation to
Sikdar and APA with APA as the primary reference (Ground 2), appears at
pages 35–45 of the Petition. Petitioner supports this analysis with testimony
from its expert, Dr. Jakobsson. Jakobsson Decl. ¶¶ 116–137.
Petitioner relies on the APA for all elements of claim 1 except
element 1.4 (“an address translation engine configured to translate between
the application address and an external address”) and a portion of elements
1.5 and 1.6 (the “address translation” element). Pet. 55–64. For the address
translation engine limitation, 1.4, Petitioner relies only on Sikdar. Id. at 37.
Petitioner’s argument that all elements of claim 1 are disclosed in this
combination is persuasive. The only material difference we discern between
the APA of Figure 18 of the ’079 patent and the elements of claim 1 is the
inclusion, in claim 1, of an address translation engine to translate the IP
addresses. See Pet. 4–5 (The ’079 patent proposes solving purported
problems of prior art firewalls “by adding a NAT engine 1945 to the
computer of Figure 18, as shown . . . in the patent’s Figure 19, where ‘IP
address x’ is translated to ‘IP address z.’”). Thus, relying on Petitioner’s
element-by-element analysis and the supporting testimony from Dr.
IPR2019-00641
Patent 9,756,079 B2
30

Jakobsson, we find that for the reasons given there and in this Decision,
Figure 18 of the ’079 patent and the accompanying description teach or
suggest the following aspects of claim 1: preamble “computer system” (even
if limiting),13 “at least one processor and memory,” the “application
associated with an application address,” “network interface” and “driver”
(excluding the “address translation engine”). Id. at 35–45; Jakobsson Decl.
¶¶ 117–137. For example, Dr Jakobsson testifies that Figure 18 of the ’079
patent (the APA) shows a computer including an operating system,
applications, and NICs. Jakobsson Decl. ¶ 117. He testifies that the APA
inherently discloses a processor and memory. Id. ¶ 118. He testifies that the
APA discloses applications 1 through m, and at least one application has an
IP address (IP address x). Id. ¶ 120. He testifies the APA discloses NICs 1
through n. Id. ¶ 121. He testifies that the APA discloses an intermediate
driver that automatically forwards incoming data packets to the firewall. Id.
¶ 129.
Claim element 1.4 requires “an address translation engine configured
to translate the application address and an external address.” Ex. 1001,
25:21–23. Petitioner contends the description in Sikdar of “NAT/PAT
operations” in connection with Figure 20 meets this limitation. Pet. 24, 37.

13 Patent Owner asserted in district court that the preamble is not limiting.
See Pet. Reply 5–6 (citing Exs. 1025–1028). We agree with Patent Owner’s
analysis in its district court submissions. See, e.g., Ex. 1025, 19–23
(analyzing “A computer system” as not limiting) (quoting Am. Med. Sys.,
Inc. v. Biolitec, Inc., 618 F.3d 1354, 1358–59 (Fed. Cir. 2010): “A preamble
is not regarded as limiting, however, when the claim body describes a
structurally complete invention such that deletion of the preamble phrase
does not affect the structure or steps of the claimed invention.”) (internal
quotes omitted).
IPR2019-00641
Patent 9,756,079 B2
31

For the reasons that follow, we agree and find that Sikdar teaches or
suggests the claimed “address translation engine.”
Petitioner asserts: “Sikdar discloses that ‘the RSP 100 can be
programmed for NAT/PAT operations that convert IP addresses [and] port
numbers.” Pet. 24 (citing Ex. 1004, 49, Fig. 20 (reproduced supra)
(alteration in original)). Further referring to Figure 20 of Sikdar, Petitioner
asserts “[t]he translated IP address and port number are used on the public
network 12 and therefore are an external address. The RSP therefore is an
address translation engine.” Id. (citations omitted). Petitioner continues:
“Similarly, Sikdar also discloses that the RSP translates ‘private IP address’
1070 to ‘public IP address’ 1052 (an external address), which is associated
with port number 1054, which the RSP generates.” Id. (citing Ex. 1004, 50).
For the reasons given by Petitioner, we find that Sikdar teaches an address
translation engine configured to translate between private application IP
addresses and an external IP address. We will discuss infra Patent Owner’s
assertion at the oral argument that Sikdar does not disclose “application
addresses.” Hearing Tr. 63:7–17.
Relying on testimony from Dr. Jakobsson, Petitioner argues that it
would have been obvious to add the functionality of a network address
translation engine, as taught by Sikdar, to the APA, represented by the prior
art software-based firewall in Figure 18. Pet. 37 (citing Jakobsson Decl.
¶ 123). Petitioner asserts: “Motivation to do so arises from Sikdar, which
discloses that NAT and PAT functionality can be integrated with a firewall.”
Id. at 38. Petitioner argues further: “Additional motivation arises from the
’079 patent’s Figures 17 and 20, both of which are admitted prior art and
show network address translation occurring in a firewall.” Id. at 39.
IPR2019-00641
Patent 9,756,079 B2
32

Patent Owner’s response to Ground 2 challenges the rationale to
combine the references in the way proposed by Petitioner in that Ground.
PO Resp. 30–32. Patent Owner contends that it “makes no sense” to
incorporate Sikdar’s NAT engine in the APA. Id. at 31. Patent Owner
asserts: “Petitioner’s argument that a [person of ordinary skill] would have
modified the [APA] to include Sikdar’s alleged ‘network address translation
engine’ fails for the same reason that it would not be implemented within
Sikdar’s laptop 25C/1078.” Id. (citing Medvidovic Decl. ¶ 90). Patent
Owner continues: “That is, traditional NAT/PAT devices like those
disclosed in Sikdar and FIG. 17 of the ‘079 Patent, operate by utilizing two
NICs, one for interfacing with a public network and another for interfacing
with a private network.” Id. Patent Owner concludes: “For at least these
reasons, Petitioner’s argument that ‘a [person of ordinary skill] would have
recognized that any address translation functionality implemented in
hardware could readily be implemented in software’ is meritless.” Id. at 48
(quoting Pet. 39).
We disagree with Patent Owner’s argument and find that a person of
ordinary skill would have been motivated to add NAT/PAT capability to the
prior art network system of Figure 18, having a software-based firewall. Pet.
37–40; Pet. Reply 15–16. As Petitioner points out, the RSP “does not
include any NICs . . ., which are a separate hardware component.” Pet.
Reply 16. We agree with Petitioner that Patent Owner’s argument is not
convincing.
More importantly, however, Patent Owner’s argument fails because,
in Ground 2, Petitioner does not propose combining “any device containing
two NICs with the APA.” Id. Petitioner proposes combining “the RSP’s
NAT/PAT functionality with the APA.” Id. (citing Pet. 37–40) (emphasis
IPR2019-00641
Patent 9,756,079 B2
33

added). “The test for obviousness is not whether the features of a secondary
reference may be bodily incorporated into the structure of the primary
reference . . . . Rather, the test is what the combined teachings of those
references would have suggested to those of ordinary skill in the art.” In re
Keller, 642 F.2d 413, 425 (CCPA 1981); see also In re Sneed, 710 F.2d
1544, 1550 (Fed. Cir. 1983) (“[I]t is not necessary that the inventions of the
references be physically combinable to render obvious the invention under
review.”); and In re Nievelt, 482 F.2d 965, 968 (CCPA 1973) (“Combining
the teachings of references does not involve an ability to combine their
specific structures.”).
Finally, we find that Petitioner’s combination of the APA and Sikdar
in Ground 2 also proposes making a software modification to the APA to
provide NAT/PAT functionality, making it unnecessary to combine the RSP
hardware with the APA. Id. at 16–17 (citing Pet. 37–40; Jakobsson Supp.
Decl. ¶ 42).
We disagree, therefore, with Patent Owner’s argument that a person of
ordinary skill would not have been motivated to add NAT/PAT capability to
the prior art network system of Figure 18, having a software-based firewall.
Patent Owner’s argument that there was no motivation to modify Figure 18
in light of Sikdar is unconvincing.
We are, instead, persuaded by Petitioner’s evidence of a strong
motivation to modify the APA to include NAT/PAT conversion. Jakobsson
Decl. ¶¶ 123–128. We find that using NAT/PAT conversion for the purpose
of protecting private IP addresses was well-known in the art prior to the ’079
patent, and in fact is described as such in the ’079 patent. Jakobsson Decl.
¶¶ 61, 123–124; Ex. 1001, Fig. 17, 18:59–65. Similarly, we find that the
advantages of using NAT/PAT conversion to protect the identity of
IPR2019-00641
Patent 9,756,079 B2
34

computers operating on a private network and reducing the number of
external IP addresses required were well-known, supported by expert
testimony and the RFCs. Jakobsson Decl. ¶ 125; Ex. 1004, 49–50; Exs.
1010, 1011. Also, we find that the benefits of adding NAT/ PAT translation
to firewalls were well-known in the prior art, and in fact acknowledged in
the ’079 patent. Jakobsson Decl. ¶ 126; Ex. 1001, 19:3–9; Ex. 1004, 49–50,
Fig. 20.
We find, therefore, that adding NAT/PAT conversion to protect
private IP addresses, as described in Sikdar, to the computer system shown
in Figure 18 of the ’079 patent would have amounted to application of a
known technique to a known system to achieve predictable results.
Jakobsson Decl. ¶ 127. “[I]f a technique has been used to improve one
device, and a person of ordinary skill in the art would recognize that it would
improve similar devices in the same way, using the technique is obvious
unless its actual application is beyond that person’s skill.” KSR Int’l Co.,
550 U.S. at 401.
Furthermore, we find that a person of skill would have had a
reasonable expectation of success in making these modifications to the APA,
as the ’079 patent itself suggests by describing prior art firewalls with NAT
capability. See Ex. 1001, Fig. 17. We credit Dr. Jakobsson’s testimony on
this issue. Jakobsson Decl. ¶ 126 (“Although firewall 1715 in Figure 17 is
‘hardware-based,’ this would not discourage a [person of ordinary skill]
from implementing NAT and PAT in the [APA’s] ‘software-based’ firewall
because a [person of ordinary skill] would have recognized that any address
translation functionality implemented in hardware could readily be
implemented in software.”).
IPR2019-00641
Patent 9,756,079 B2
35

We find further support for this conclusion in the relatively high level
of skill in the relevant art, namely, “a bachelors’ degree in computer science,
electrical engineering, or a comparable field of study, plus at least two years
of professional experience with computer security systems and networks, or
the equivalent.” See supra. We find that making this modification would
have been within the skill level of such an individual. Jakobsson Supp.
Decl. ¶ 42 (“My opinions in this regard do not require combining the RSP
hardware into the APA (although a [person of ordinary skill] could do so)
because I also propose incorporating the RSP’s NAT/PAT functionality into
the APA as software.”).
Patent Owner’s response contends further that the APA (either alone
or combined with Sikdar) “fails to disclose ‘an address translation engine
configured to translate between the application address and an external
address.’” PO Resp. 30. Patent Owner made the same argument in
IPR2019-00561, regarding a similar limitation recited in claim 1 of related
U.S. Patent No. 8,365,272.14 As noted supra, the oral hearing in IPR2019-
00561 was consolidated with the oral hearing in this case. When pressed at
the oral hearing, Patent Owner’s counsel explained its argument in these
terms:
THE BOARD: . . . I’ve got Claim 1 of ‘272 and now you’re
going to tell me how that claim is distinguished from
conventional firewalls, right?
. . . .
COUNSEL: Okay. So for example, you have to have an
application that’s associated with an application address.

14 In the ’272 patent, claim 1 recites “an application associated with an
application address” and “a network address translation engine configured to
translate between the application address and the public address.” IPR2019-
00561, Ex. 1001, 24:64, 25:1–3.
IPR2019-00641
Patent 9,756,079 B2
36

Sikdar doesn’t disclose that at all. It never discloses any type of
application that’s associated with an address.
Hearing Tr. 49:16–24. Patent Owner’s asserted distinction between the
APA and the challenged claims is that prior art conventional firewalls,
including the APA, are “completely agnostic as to the applications that are
on a particular computer. They just don’t care.” Id. at 43:15–17. We are
not persuaded by this argument.
As Petitioner pointed out at the hearing, nothing in the similar
language of claim 1 of the ’272 patent requires that the claimed computer be
“application sensitive,” or have knowledge of the applications. Id. at
79:14–16. Contrast the lack of any recitation indicating application
sensitivity in claim 1 of the ’079 and ’272 patents with claim 6, discussed
infra, directed to the “hybrid firewall” embodiment, which the ’079 patent
specifically describes as “application sensitive.” Ex. 1001, 22:7–12. Thus,
claim 6 depends from claim 1 and includes a hybrid firewall limitation not
present in claim 1, specifically, “wherein the computer system is configured
to send data packets identifying the application to the firewall, and the
firewall is configured to handle both network-level security and application-
level security.” Id. at 25:48–26:3. Compare also the description of the APA
of Figure 18 with the hybrid firewall embodiment of Figure 21, calling for
“each packet comprising data identifying the application . . . associated with
the packet.” Ex. 1001, 22:50–51.
Claim 1 of the ’079 patent, similar to claim 1 of the ’272 patent, does
recite translating an “application address.” Id. at 25:17. At the hearing,
Patent Owner’s counsel identified an IP address as an example of an
“application address”:
IPR2019-00641
Patent 9,756,079 B2
37

THE BOARD: . . . An “application address” would be what?
What would be an example of an application address?
COUNSEL: Well, the patent provides an example saying that
it’s an IP address of the application.
Hearing Tr. 65:15–18. As discussed supra, IP addresses direct packets of
data to specific computers, while TCP port numbers identify specific
applications. Jakobsson Decl. ¶¶ 56–57; see also Dr. Medvidovic’s
testimony comparing IP addresses to apartment buildings and applications
to a particular apartments in the building:
A computer is like an apartment building, so an IP address is the
address for the apartment building. An application is a particular
apartment in that building. So in order to actually get the data to
the application it is not enough just to get to the building, you
also need to know in this particular context what port it is
communicating through so once you get it to the computer you
can also get it to the appropriate application.
Medvidovic Dep. 20:23–21:6.
Thus, in the context of the ’079 patent, we find that the “application
address” in claim 1 refers to the IP address of the computer on which the
application is running. This is illustrated in Figures 18 and 19, reproduced
supra, showing applications 1835 and 1935, respectively, having the same
IP address x, indicating the applications are running on a computer with IP
address x. And it is consistent with counsel’s statement at the hearing,
quoted supra, and with the description of Figure 19 in the specification,
which states: “In this way, the network system 1900 is able to isolate the IP
and MAC addresses of internal computers/applications from the external
network 1905.” Ex. 1001, 20:35–37 (emphasis added). Expressed in terms
of Dr. Medvidovic’s analogy, the applications in the ’079 patent share the
same apartment building, but not the same apartment, and therefore have the
same IP address.
IPR2019-00641
Patent 9,756,079 B2
38

Thus, we are unconvinced of any difference material to our
understanding of claim 1 of the ’079 patent between the address translation
described in Sikdar and that recited in claim 1. In both cases, internal IP
addresses are translated into an external IP address to provide address
isolation. Therefore, we see no basis for distinguishing the application
addresses of claim 1 from the private IP addresses translated into a public IP
address in Sikdar. Nor do we find that the firewall described in Sikdar is
any more or less “application sensitive” than the firewalls shown in Figures
18 or 19 of the ’079 patent and described in the specification.
In any case, Petitioner points to numerous applications disclosed in
Sikdar that would have IP addresses, as well as TCP addresses or port
numbers. Pet. 17–19; Jakobsson Decl. ¶¶ 77–83. These include email, AV
software, Command Line Interface software, and Windows applications
such as Internet Explorer. Id. Petitioner contends each of these applications
would “necessarily and inherently” have had associated application
addresses or otherwise incoming packets would have no way of reaching
them. Pet. 21 (citing Jakobsson Decl. ¶ 81). For this additional reason, we
find that the APA-Sikdar combination discloses the claimed translation of
application addresses.
In sum, for the reasons given, we find that the combination of the
APA and Sikdar, as described in Ground 2 of the Petition, teaches or
suggests each element of claim 1, and that a person of ordinary skill would
have combined the relevant teachings of those references with a reasonable
expectation of success.
2. Sikdar and APA
In the Ground 1 challenge to claim 1, Petitioner relies on Sikdar alone
to meet claim elements 1.1 through 1.4 (Pet. 17–26), and Sikdar and APA to
IPR2019-00641
Patent 9,756,079 B2
39

meet claim elements 1.5 and 1.6 (id. at 26–35). Thus, for example,
Petitioner relies on Sikdar’s disclosure of laptops 25C and 1078, which can
include the RSP, to meet claim element 1.1, reciting “at least one processor
and memory.” Id. at 17.
Claim element 1.2 calls for “an application associated with an
application address.” Petitioner relies on Sikdar’s disclosure that laptop
users may connect to URL links corresponding to “different Internet
locations.” Pet. 17 (citing Ex. 1004, 45). Petitioner then identifies several
applications, including web browsers and email clients, that would have
been available in light of the network data packet protocols disclosed in
Sikdar. Id. at 17–19. Although Sikdar does not expressly disclose an
application such as Internet Explorer by name, relying testimony from Dr.
Jakobsson, Petitioner contends it would have been obvious to include an
application such as a web browser or email application on laptops 25C and
1078. Id. at 19 (citing Jakobsson Decl. ¶ 78).
For the recited “application address” Petitioner relies on the
discussion in Sikdar of addressing network data packets using a combination
of IP address and port number (“socket address”). Id. at 20. This socket
address acts as an application address. Id. Accordingly, Petitioner argues
Sikdar discloses an application address for at least each application that
communicates across the network. Id. Relying on testimony from Dr.
Jakobsson, Petitioner contends “Sikdar does not disclose an application that
would not have such an associated application address.” Id. (citing
Jakobsson Decl. ¶ 79). Alternatively, Petitioner contends Sikdar’s express
disclosure of network communications using TCP/IP supports this argument.
Id. at 20–22.
IPR2019-00641
Patent 9,756,079 B2
40

Petitioner asserts claim element 1.3 (“a network interface coupled to
receive incoming data packets from and transmit outgoing data packets to an
external network”) is met by laptops 1078 and 25C in Sikdar. Pet. 23.
Sikdar states those devices can include an RSP having input and output ports
for receiving and transmitting packet data streams. Id. at 22–23.
Claim element 1.4 calls for “an address translation engine configured
to translate between the application address and an external address.” Ex.
1001, 25:21–23. To meet this element Petitioner relies on Sikdar’s
disclosure of NAT and PAT operation, described supra. Pet. 24–26. Sikdar
discloses that “the RSP 100 can be programmed for NAT/PAT operations
that convert IP addresses [and] port numbers.” Ex. 1004, 49; Fig. 20
(“NAT/PAT”). Petitioner argues that a person of ordinary skill would have
understood that “NAT” and “PAT” refers to translation of an IP address and
TCP port number, and thus, in light of Petitioner’s contention that the IP
address and TCP port number act as an application address, this NAT/PAT
operation discloses application address translation. Jakobsson Decl. ¶ 87;
Pet. 24.
The translated IP address and port number in Sikdar are used on the
public network 12 and therefore are an external address. Ex. 1004, Fig. 20.
Petitioner concludes the RSP, therefore, is an address translation engine
executing software that translates between application addresses and
external addresses. Pet. 24–25.
Finally, claim elements 1.5 and 1.6, are directed to “a driver for
automatically forwarding the outgoing data packets to the address translation
engine to translate the application address to the external address” (1.5)
which is also “coupled to transmit the incoming data packets to a firewall
configured to reject the incoming data packets if the incoming data packets
IPR2019-00641
Patent 9,756,079 B2
41

include malicious content” (1.6). Ex. 1001, 25:24–26, 25:29–32. Petitioner
relies on intermediate driver 1820 in the ’079 patent Figure 18 (the APA),
described supra, to meet the “driver” limitation in both claim elements 1.5
and 1.6. Pet. 26, 32. For example, according to Petitioner, “[i]t would have
been obvious for a [person of ordinary skill] at the time of the alleged
invention of the ’079 patent to combine the teachings of the [APA] with
Sikdar to include in Sikdar a driver for automatically forwarding outgoing
and incoming data packets to Sikdar’s address translation engine software
module.” Id. at 26. Petitioner relies on the RSP in Sikdar to meet the
firewall feature of the claims. Id. at 29–32. Petitioner asserts “[i]t would
have been obvious for a [person of ordinary skill] at the time of the alleged
invention of the ’079 patent to combine the teachings of the [APA] with
Sikdar to include in Sikdar a driver for transmitting incoming data packets to
the firewall implemented in the RSP. . . .” Id. at 32.
Patent Owner focuses its opposition on two features of the claim.
First, Patent Owner focuses on the preamble to claim 1, reciting “a computer
system.” PO Resp. 17–23. Patent Owner contends that “Sikdar in view of
the APA fails to teach or suggest the claimed computer system.” Id. at 17.
Petitioner responds that in making this argument, Patent Owner “assumes
that the preamble is limiting.” Pet. Reply 5. Petitioner goes on to point out
that this implicit argument that the preamble is limiting “contradicts” Patent
Owner’s position in the district court litigation, where Patent Owner took the
opposite position that the preamble was not limiting. Id. We discuss this
issue in Section III.B.1, supra, and conclude that based on Patent Owner’s
analysis and argument to the district court, the preamble is not limiting. See,
e.g., Ex. 1025, 22–23 (analyzing “A computer system” as not limiting)
(citing Am. Med. Sys., Inc. v. Biolitec, Inc., 618 F.3d 1354, 1358–59 (Fed.
IPR2019-00641
Patent 9,756,079 B2
42

Cir. 2010): “A preamble is not regarded as limiting, however, when the
claim body describes a structurally complete invention such that deletion of
the preamble phrase does not affect the structure or steps of the claimed
invention.”) (internal quotes omitted). Moreover, Petitioner contends that
even assuming claim 1’s preamble is limiting, Sikdar’s laptops 25C (in
Figure 1) and 1078 (in Figure 20) meet the limitation. Pet 17; Pet. Reply 6–
11.
Patent Owner’s second argument focuses on the “driver” limitation of
claim elements 1.5 and 1.6. PO Resp. 25–30. Patent Owner contends that
“Petitioner itself concedes that Sikdar does not disclose the use of drivers.”
Id. at 16. Further, Patent Owner contends there is “no motivation” to
combine Sikdar and the APA: “[T]here is also no teaching in [APA] that
Petitioner points to that would motive a [person of ordinary skill] to combine
Sikdar with the drivers described by [APA].” Id. (citing Medvidovic Decl.
¶ 76). Citing expert testimony, Patent Owner reasons: “Sikdar’s RSP is
configured to send and receive data between computers at the network level
rather than receiving data from a driver located within a computer.” Id.
(citing Medvidovic Decl. ¶ 69).
Petitioner responds to this argument of “no motivation to combine” by
referring back to the Petition. Pet. Reply 15 (citing Pet. 26–28). We are not
convinced by these arguments insofar as they are directed to adding the
driver to Sikdar. For example, the Petition states: “A [person of ordinary
skill] would understand that the driver could be configured to forward data
packets (both incoming and outgoing) to any module (hardware or software)
willing to receive them, including the RSP software module that performs
NAT and PAT.” Pet. 27 (citing Jakobsson Decl. ¶ 93) (emphasis added).
The Petition further asserts: “A [person of ordinary skill] would understand
IPR2019-00641
Patent 9,756,079 B2
43

that the RSP could be configured to forward outgoing packets in the same
manner that it forwards incoming packets.” Id. (emphasis added).
We do not find such statements compelling evidence of a motivation
to combine. Showing that a reference “could” have been modified does not
demonstrate a motivation or rationale for making the modification or
combination. See Belden Inc. v. Berk-Tek LLC, 805 F.3d 1064, 1073 (Fed.
Cir. 2015) (“[O]bviousness concerns whether a skilled artisan not only could
have made but would have been motivated to make the combinations or
modifications of prior art to arrive at the claimed invention.” (emphasis
original)).
Nor do we find Petitioner’s cursory references to “common sense,”
“applying a known technique,” or “choosing from a finite number of
identifiable, predictable conclusions” (Pet. 27–28) compelling evidence,
without further record support for its arguments.
In short, we are not convinced that Petitioner has demonstrated by a
preponderance of the evidence that it would have been obvious to modify
Sikdar to provide the driver from the APA to meet the requirement of the
claim for a driver forwarding data packets to and from the address
translation engine in Sikdar. Instead, we find more compelling Patent
Owner’s argument that it would “change the operating principle of Sikdar”
and is “the product of hindsight.” PO Resp. 29–30.
Accordingly, we are persuaded that Petitioner has not demonstrated
that claim 1 would have been obvious over Sikdar and APA, where Sikdar is
the primary reference (Ground 1).
C. Claim 7: Sikdar and RFC 2616, Sikar and Wright
These challenges are referred to in the Petition as Grounds 3 and 4.
Pet. 3. Petitioner provides an element-by-element analysis of claim 7 in
IPR2019-00641
Patent 9,756,079 B2
44

relation to Sikdar and RFC 2616 (Ground 3) at pages 46–58 of the Petition,
and a similar analysis of claim 7 in relation to Sikdar and Wright (Ground 4)
at pages 60–63. Petitioner supports these analyses with testimony from Dr.
Jakobsson. Jakobsson Decl. ¶¶ 138–179.
The two grounds are similar. In each, Petitioner relies on Sikdar to
meet elements 7.1 (network interface), 7.2 (firewall), and 7.4 (address
translation engine). Pet. 46, 48, 57. Petitioner’s analysis for these claim
elements in relation to Sikdar is similar to its Ground 1challenge to claim 1,
with Sikdar as a primary reference, specifically, the analysis relating to
elements 1.3, 1.4 and 1.6. See id. at 2, 24, 29. There are, however, some
differences.
Claim element 7.2 includes “a firewall in communication with the
network interface, the firewall configured to perform both network-level
security and application-level security on incoming data packets.” Pet. 48.
Also, claim element 7.4 calls for “an address translation engine configured
to translate the at least one application address associated 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 network.” Id. at 57 (emphasis added).
Petitioner contends that the “firewall limitation” of claim element 7.2
is met by Sikdar’s firewall 1062. Id. at 48. Petitioner further argues that the
firewall and RSP in Sikdar meet the requirement of being “configured to
perform both network-level security and application-level security on
incoming data packets.” Id. at 49. To provide network-level security, “the
RSP ‘monitors all incoming packets . . . from the public IP network’ and
‘provides Denial of Service (DoS) filtering of TCP packets’ (network-level
security).” Id. (quoting Ex. 1004, 7, 11–13).
IPR2019-00641
Patent 9,756,079 B2
45

For providing application-level security, Petitioner relies on Sikdar’s
disclosure of “security functionality” provided by the RSP. Id. at 49–50.
According to Petitioner, “[a person of ordinary skill] would have understood
that such intrusion-detection is application-level security because it is based
on the data being associated with an email application.” Id. (citing
Jakobsson Decl. ¶ 149).
To meet the claimed “application identifier” in element 7.3, Petitioner
relies on RFC 2616 in one ground (Pet. 52–57) and Wright in the second (id.
at 60–63). In RFC 2616, Petitioner relies on the “user-agent” HTTP header
field as disclosing an application identifier. Id. at 53–54. Petitioner relies
alternatively on Wright’s disclosure of an “application parameter” that is
used as an application identifier. Id. at 61; Ex. 1014 ¶ 193.
To meet the “dynamically isolating” limitation in 7.4, Petitioner
points to Sikdar’s address translation engine: “Such translation dynamically
isolates the applications of laptops 1078 and 25C from public network 12
because it hides those applications’ addresses from the public network as the
packets pass through the RSP.” Pet. 57–58 (citing Jakobsson Decl. ¶ 165).
Patent Owner’s response to both grounds is directed to the
“dynamically isolating” limitation in claim element 7.3. PO Resp. 32–40.
Patent Owner asserts, “rather than relying on its construction of
‘dynamically isolating,’ the Board instead relied on a separate construction
of ‘dynamic’ which clouded its analysis and detracts from teachings of the
‘079 Patent.” Id. at 32.
Patent Owner also challenges the sufficiency of Petitioner’s analysis
of “dynamic isolation” in Sikdar:
[A person of ordinary skill] would recognize that this analysis
does not demonstrate that Sikdar’s NAT/PAT technique involves
IPR2019-00641
Patent 9,756,079 B2
46

“the use of DHCP or other source of addresses in connection with
a NAT engine to translate IP addresses,” let alone “the use of
DHCP or other dynamic source of addresses in connection with
a NAT engine to translate IP addresses.”
Id. at 34 (emphasis omitted). Patent Owner continues by challenging Dr.
Jakobsson’s testimony: “Contrary to Dr. Jakobsson’s assertions, a [person of
ordinary skill] would also not characterize all NAT/PAT operations as
‘dynamic’ or find that a network’s mere inclusion of Sikdar’s NAT discloses
or suggests “dynamic isolation” as claimed within the context of the ‘079
Patent.” Id. at 36–37 (citing Medvidovic Decl. ¶ 100). Patent Owner
continues its attack on the sufficiency of Petitioner’s evidence: “Further
highlighting the novel nature of the ‘079 Patent, Petitioner relied on
evidence that demonstrates that the allegedly ‘traditional’ use of NAT/PAT
includes static isolation techniques rather than dynamic isolation in the
claimed fashion.” Id. at 38. Patent Owner summarizes:
Sikdar, either alone or in combination with [RFC 2616], fails to
disclose or suggest “a network address translation engine
configured to translate the at least one application address of the
one or more applications to a public address, thereby
dynamically isolating the one or more applications from the
external network,” as claimed.
Id. at 39.
Similarly, for the challenge based on Sikdar and Wright, Patent
Owner refers back to its argument on Sikdar and RFC 2616, and asserts:
“Sikdar, either alone or in combination with Wright, fails to disclose or
suggest all of the recited limitations of claim 7 as claimed.” Id. at 40.
Our construction of “dynamically isolating” specifically refers, as a
possible source of addresses, to using DHCP, which is “a TCP/IP protocol
that enables PCs and workstations to get temporary or permanent IP
addresses (out of a pool) from centrally-administered servers.” Ex. 3001
IPR2019-00641
Patent 9,756,079 B2
47

(Newton’s Telecom Dictionary). See discussion of DHCP, supra. There is
no dispute that Sikdar does not explicitly disclose the use of DHCP as a
source of addresses in connection with the address translations performed by
the RSP.
Dr. Jakobsson provides testimony to rebut Patent Owner’s argument
that Petitioner’s analysis is insufficient for its failure to identify a “source of
addresses” in Sikdar, as required by our construction of “dynamically
isolating.” Jakobsson Supp. Decl. ¶ 47. In this rebuttal testimony, Dr.
Jakobsson does not directly address Patent Owner’s argument, but instead
refers back to statements in his prior declaration and to the statement in
Sikdar that the SPU “generates the public IP address and port number for the
packet.” Id. (citing Ex. 1004, 51). See discussion infra. He concludes,
without further explanation or analysis, “I therefore have shown that at least
the RSP and its SPU each are a source of addresses used for the disclosed
‘NAT/PAT.’” Id. Dr. Jakobsson’s cross-examination testimony is similarly
conclusory on this issue. Thus, when asked how “the use of DHCP or other
source of addresses” is disclosed in Sikdar, he responded: “Now the public
IP address is generated somewhere. One common choice is to use DHCP,
but as we described and talked about, it doesn’t have to be DHCP, it could
be another source too. . . . It must be one of those options.” Jakobsson II
Dep. 74:17–20, 75:1.
We find this testimony from Dr. Jakobsson’s to be too conclusory and
speculative to provide persuasive evidence as to how the public IP address
disclosed in Sikdar, namely, the IP address of the firewall, is sourced.
As noted supra, in response to Patent Owner’s argument and in
support of its argument identifying the SPU (Semantic Processing Unit) in
Sikdar is a source of IP addresses, Petitioner relies on a statement in Sikdar
IPR2019-00641
Patent 9,756,079 B2
48

that the SPU “generates” the public IP address. See, e.g., Pet. Reply 18;
Jakobsson II Dep. 74:12–16. But we are more persuaded by Patent Owner’s
argument that the public IP address disclosed in Sikdar is not “generated” by
the SPU using a source of addresses. Instead, we agree with Patent Owner
that: “[A]s Sikdar explicitly states, the public IP address is not actually
‘generated’ (with DHCP or any other address source). Rather the public IP
address is simply the firewall’s public IP address.” Sur-reply 12.
We find that Sikdar’s disclosure differs from the ’079 patent’s
disclosure of dynamic addressing in 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. Ex. 1004, 50 (“The RSP 100 receives
the packet 1072 and converts the private source IP address 1070 to the
public IP address 1052 associated with firewall 1062.”). In contrast, we find
that the ’079 patent discloses that the NAT engine uses DHCP to translate
internal IP and MAC addresses embedded in the outgoing data
communications into multiple external IP and MAC addresses, which it then
substitutes for the internal IP and MAC addresses in the data
communications. Ex. 1001, 21:35–41. Further, we find that, unlike the ’079
patent’s disclosure of using DHCP to provide addresses, Sikdar does not
disclose the source of the firewall IP address, and Dr. Jakobsson fails to
provide persuasive testimony supported by credible evidence identifying its
source, instead relying on speculative statements such as “it must be one of
those options.” Jackobsson II Dep. 75:1.
We, therefore, conclude that Petitioner has not demonstrated by a
preponderance of the evidence that Sikdar discloses the translation of IP
addresses “using DHCP or other source of addresses,” as our claim
construction requires.
IPR2019-00641
Patent 9,756,079 B2
49

After considering all the evidence and arguments, we find that
Petitioner fails to demonstrate that Sikdar discloses “a network address
translation engine configured to translate the at least one application address
of the one or more applications to a public address, thereby dynamically
isolating the one or more applications from the external network.”15
We have considered Petitioner’s argument that Sikdar meets the
requirement for dynamic isolation because it operates to provide public IP
addresses “on the fly” or “in real time.” Pet. Reply 18–19; Jakobsson Supp.
Decl. ¶ 49 (“I opined that Sikdar discloses the ‘dynamically isolating’
limitation in part because its NAT/PAT translation occurs when and as
needed (i.e., on the fly), as the packets are passing through the RSP.”
(emphasis omitted)). We are not persuaded by this argument. As discussed
supra, in Sikdar, the public IP address assigned to the packets is the IP
address of the firewall. While the packets may pass through the firewall “on
the fly” and “in real time,” their public IP address is not determined “on the
fly.” Instead, the same firewall IP address is used.
Accordingly, we are persuaded that Petitioner has not demonstrated
that claim 7 is obvious over Sikdar and RFC 2616 or Sikdar and Wright.
C. Claim 6: Sikdar, APA, and RFC 2616; Sikdar, APA, and Wright
These challenges to claim 6 are referred to in the Petition as Grounds
5 and 6, respectively. Pet. 3. Claim 6 recites: “The computer system of
claim 1, wherein the computer system is configured to send data packets
identifying the application to the firewall, and the firewall is configured to
handle both network-level security and application level security.” Ex.

15 We find that an alternative embodiment of Sikdar in which “one or more
private IP addresses have an associated individual public IP address” (Ex.
1004, 50) is not relevant to this decision.
IPR2019-00641
Patent 9,756,079 B2
50

1001, 25:48–26:3. Petitioner’s analysis of each of these grounds
incorporates its analysis of claim 1 from Ground 3, in which Sikdar is the
primary reference. Pet. 63, 64.
We observe that by incorporating these arguments, Petitioner is
specifically relying on modifying Sikdar to include a driver, discussed supra
in connection with our analysis of the Ground 1 challenge to claim 1, in
which Sikdar is the primary reference. Id. at 25–30. Thus, with the regard
to the addition of RFC 2616 to the combination of Sikdar and APA in
Ground 5, Petitioner confirms that it relies on modifying Sikdar to include
the driver: “[T]he proposed modifications to Sikdar regarding the use of a
driver described for limitations 1.5 and 1.6 in Ground 1 are entirely
compatible with the proposed modification to Sikdar . . . . All the
obviousness analysis applicable to the combination of Sikdar and the [APA]
still applies if Sikdar is also combined with [RFC2616], and vice versa.”
Pet. 64. Petitioner makes a similar statement concerning its Ground 6
challenge to claim 6 based on Sikdar, APA, and Wright. Id. at 65.
Patent Owner responds by referring back to its arguments opposing
Petitioner’s analysis of claim 1. PO Resp. 41.
In analyzing Petitioner’s Ground 1 challenge to claim 1, supra, we
found that Petitioner had not demonstrated a motivation to modify Sikdar in
light of the APA to include a driver. See supra, Section III.B.2. Because
Petitioner incorporates its analysis from Ground 1, and specifically the
driver modification to Sikdar, into its Ground 5 and 6 challenges to claim 6,
we find that Petitioner’s challenges to claim 6 based on Sikdar and the APA,
further combined with either RFC2616 or Wright, fail for the same reasons
given above as to Petitioner’s Ground 1 challenge to claim 1. Specifically,
we have found that Petitioner failed to demonstrate that a person of ordinary
IPR2019-00641
Patent 9,756,079 B2
51

skill would not have modified Sidkar to include the driver disclosed in the
APA. See supra, Section III.B.2.
Thus, we find that Petitioner has not demonstrated by a preponderance
of the evidence that claim 6 would have been obvious over Sikdar in light of
the APA, further combined with either RFC2616 or Wright.
We have not considered a challenge to claim 6 in which, similar to
the Ground 2 challenge to claim 1, the APA is the primary reference. That
challenge was not presented by the Petition, and we therefore do not
consider it in this analysis. Acceleration Bay, LLC v. Activision Blizzard
Inc., 908 F.3d 765, 775 (Fed. Cir. 2018) (Board did not abuse its discretion
in declining to consider the cited paragraphs in reply declaration raising a
new obviousness argument that could have been made in the petition).
D. “Objective Indicia of Non-obviousness”
Patent Owner asserts that the patentability of the challenged claims is
supported by “objective indicia” (also called “secondary considerations”) of
non-obviousness, including long-felt need, failure of others, and skepticism
by experts in the industry. PO Resp. 42–44; see Graham, 383 U.S. at 17–18.
Before reaching a decision on obviousness of claim 1, we must weigh these
secondary considerations. In re Cyclobenzaprine Hydrochloride Extended-
Release Capsule Patent Litig., 676 F.3d 1063, 1075–76 (Fed. Cir. 2012).
“The patentee bears the burden of showing that a nexus exists.” WMS
Gaming Inc. v. Int’l Game Tech., 184 F.3d 1339, 1359 (Fed. Cir. 1999). To
determine whether the patentee has met that burden, we consider the
correspondence between the objective evidence and the claim scope. Fox
Factory, Inc. v. SRAM, LLC, 944 F.3d 1366, 1373 (Fed. Cir. 2019) (citation
omitted); Lectrosonics, Inc. v. Zaxcom, Inc., Case IPR2018-01129, Paper 33
IPR2019-00641
Patent 9,756,079 B2
52

(Jan. 24, 2020) (precedential) (addressing Fox Factory and nexus to
objective indicia of non-obviousness).
Patent Owner cites no testimonial evidence in support of its assertions
of secondary considerations, but relies instead on statements in the ’079
patent itself, as well as two publications: one, a Technology News article
(Ex. 2007); the other, a Forrester report (Ex. 2008). According to Patent
Owner, these show “[t]he industry confirmed that there was a long
recognized problem with regard to mobile security that others failed to
solve.” PO Resp. 42.
Further, Patent Owner asserts “the recognition of a problem, long-felt
need, and failure by others all demonstrate that the ‘079 Patent was not
obvious.” Id. at 43. Patent Owner also asserts: “The industry also expressed
skepticism as to the capabilities of [mobile device management] solutions
that existed in 2013.” Id. (citing Ex. 2007, the Technology News article).
Patent Owner makes no attempt to relate these statements to the patent
claims.
Petitioner asserts: “The cornerstone of all types of secondary
considerations is that there must be a ‘nexus’ between the merits of the
claimed invention and the evidence being relied upon.” Pet. Reply 23.
Petitioner contends Patent Owner has not established a nexus between its
cited secondary considerations evidence and the merits of ’079 patent’s
challenged claims. Id. at 23, 25.
We agree with Petitioner that Patent Owner has failed to establish the
required nexus to its claims. “In order to accord substantial weight to
secondary considerations in an obviousness analysis, the evidence of
secondary considerations must have a nexus to the claims, i.e., there must be
a legally and factually sufficient connection between the evidence and the
IPR2019-00641
Patent 9,756,079 B2
53

patented invention.” Fox Factory, Inc., 944 F.3d at 1373 (internal quotes
omitted).
We agree also that Patent Owner has not provided convincing
evidence supporting the existence of such objective indicia. To demonstrate
long felt need, a patentee must point to an “articulated identified problem
and evidence of efforts to solve that problem” which were, before the
invention, unsuccessful. Tex. Instruments v. Int’l Trade Comm’n, 988 F.2d
1165, 1178 (Fed. Cir. 1993). Patent Owner’s reliance on generalities fails to
provide us with persuasive evidence of an “articulated identified problem,”
much less evidence of failed efforts to solve that problem. For example,
Patent Owner relies on statements in the ’079 patent that an industry
conference in December 2005 “highlighted” mobile security, and “no
complete solutions were presented.” PO Resp. 42 (citing Ex. 1001, 2:28–
32). Patent Owner provides no further details on this conference. Patent
Owner also cites a news article referring generally to “employees using
devices for personal purposes” to show “higher risk of security issues.” Id.
at 42–43 (citing Ex. 2007, 3).16 We have considered this evidence and do
not find it sufficiently detailed or specific to convince us of the existence of
a long felt need that others failed to meet.
Similarly, Patent Owner has produced no testimony from experts or
others expressing industry skepticism. Instead, Patent Owner relies on
generalized statements from a news article concerning the need for “data
encryption and antimalware software,” and on statements in its own patent.
Id. at 43–44; see In re Magna Electronics, Inc., 611 F. App’x. 969, 973
(Fed. Cir. 2015) (“Nor can Magna substantiate its claim of skepticism of

16 Citation is to page numbering provided by Patent Owner.
IPR2019-00641
Patent 9,756,079 B2
54

experts. As we have noted, such arguments often require a showing of
technical infeasibility or manufacturing uncertainty.”).
We find that, for the reasons given, Patent Owner’s evidence of
secondary factors is insubstantial and unconvincing, and we therefore give it
minimal weight in considering the obviousness of any of the challenged
claims.
IV. CONCLUSION
Based on the arguments and evidence presented during trial, Petitioner
has not demonstrated by a preponderance of the evidence that either claim 6
or 7 of the ’079 patent is unpatentable under 35 U.S.C. §103. Petitioner has
demonstrated by a preponderance of the evidence that claim 1 is
unpatentable under § 103.
A summary of our conclusions is set forth in the table reproduced
below.

Claim 35 U.S.C. § Reference(s)/Basis
Claim(s)
Shown
Unpatentable
Claim(s)
Not shown
Unpatentable
1

103 Sikdar, APA

1
1

103 APA, Sikdar 1
7 103 Sikdar, RFC2616

7
7

103 Sikdar, Wright 7
6

103 Sikdar, APA,
RFC2616
6
6

103 Sikdar, APA,
Wright
6
Overall
Outcome
1

7, 6
IPR2019-00641
Patent 9,756,079 B2
55

V. ORDER
Upon consideration of the record before us, it is:
ORDERED that claims 6 and 7 of the ’079 patent are not determined
to be unpatentable;
FURTHER ORDERED that claim 1 of the ’079 patent is determined
to be unpatentable; and
FURTHER ORDERED that because this is a Final Written Decision,
parties to this proceeding seeking judicial review of our decision must
comply with the notice and service requirements of 37 C.F.R. § 90.2.17

17 Should Patent Owner wish to pursue amendment of the challenged
claims in a reissue or reexamination proceeding subsequent to the
issuance of this decision, we draw Patent Owner’s attention to the April
2019 Notice Regarding Options for Amendments by Patent Owner
Through Reissue or Reexamination During a Pending AIA Trial
Proceeding. See 84 Fed. Reg. 16,654 (Apr. 22, 2019). If Patent Owner
chooses to file a reissue application or a request for reexamination of
the challenged patent, we remind Patent Owner of its continuing
obligation to notify the Board of any such related matters in updated
mandatory notices. See 37 C.F.R. § 42.8(a)(3), (b)(2).
IPR2019-00641
Patent 9,756,079 B2
56

For PETITIONER:

Robert Buergi
James Heintz
DLA PIPER LLP
robert.buergi@dlapiper.com
jim.heintz@dlapiper.com

For PATENT OWNER:
James Hannah
Jeffrey Price
Michael Lee
KRAMER LEVIN NAFTALIS & FRANKEL LLP
jhannah@kramerlevin.com.
jprice@kramerlevin.com
mhlee@kramerlevin.com