CUPP Computing AS

Patent Trials and Appeals Board

Jul 6, 2020

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

Trials@uspto.gov Paper No. 27
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-00561
Patent 8,365,272 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-00561
Patent 8,365,272 B2

2

I. INTRODUCTION
A. Background
Trend Micro Inc. (“Petitioner”) filed a Petition requesting inter partes
review of claims 1, 7, and 16 (the “challenged claims”) of U.S. Patent
No. 8,365,272 B2 (Ex. 1001, the “’272 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 20, “Sur-reply”). In addition, Patent
Owner filed a Motion to Exclude. Paper 21. We deny that motion in a
separate Order entered concurrently.
On April 20, 2020, we held a consolidated oral hearing with IPR2019-
00641, involving related U.S. Patent No. 9,756,079, and a transcript of the
hearing is included in the record. Paper 26 (“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 ’272 patent is unpatentable. We further
IPR2019-00561
Patent 8,365,272 B2

3

determine that Petitioner has not demonstrated that claims 7 and 16 are
unpatentable.
B. Related Proceedings:
Petitioner identifies the following district court proceedings
concerning the ’272 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 ’272
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. 1007 (“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-00561
Patent 8,365,272 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. 1007, 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. Ports can be thought of as separate channels on each
computer. Id. at 10. 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. 1010 (“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

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-00561
Patent 8,365,272 B2

5

because the internal addressing must be kept private from the external
network.” Id. at 2.
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.”
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. 1018 (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 ’272 Patent
The ’272 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:14–16.
According to the ’272 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:45–64; Fig. 17. According to the ’272 patent,
IPR2019-00561
Patent 8,365,272 B2

6

hardware-based firewalls were an improvement over PC software-based
firewalls running on internal computers. Id. at 18:65–19:3.
1. “Dynamic Isolation” Embodiment
The ’272 patent describes an embodiment under the heading
“Dynamic Isolation.” Ex. 1001, 18:45–21:31. The description of this
embodiment begins with a discussion of Figure 18 of the ’272 patent.
Figure 18 shows a “prior art” network system having a software-based
firewall. Id. at 19:4–5. Figure 18 follows:

Figure 18 is a block diagram illustrating prior art network system
1800 having a software-based firewall. Id. at 19:4–5. 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:5–8.
IPR2019-00561
Patent 8,365,272 B2

7

As described in the patent, prior art software-based firewall networks
such as that shown in Figure 18 include NDIS driver 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:7–15.
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:17–22. 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
1835 and the external network 1805).” Id. at 19:25–29.
Figure 19 of the ’272 patent shows a network system that “performs
dynamic address isolation, in accordance with an embodiment.” Id. at
19:30–32. Figure 19 (annotated by the Board) follows:

2 See Pet. 11–12 for a description of the OSI model.
IPR2019-00561
Patent 8,365,272 B2

8

Figure 19 is described as “a block diagram illustrating a network
system that performs dynamic address isolation.” Ex. 1001, 4:29–30. The
network shown in Figure 19 has the same general configuration as prior art
network 1800 of Figure 18, reproduced supra. That is, Figure 19’s network
system 1900 (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:32–
41.
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-00561
Patent 8,365,272 B2

9

annotated Figure, that contains a translations table for IP addresses. Id. at
19:41–43.
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:52–57.
As shown in Figure 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.
at 19:57–65.
After NAT engine 1945 translates the IP address, intermediate driver
1920 directs each incoming data packet to firewall 1925. Id. at 20:4–6.
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:6–8. 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:9–11.
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:12–14. 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-00561
Patent 8,365,272 B2

10

back from NAT engine 1945 and routes each data packet to external network
1905. Id. at 20:14–21.
2. “Hybrid Firewall” Embodiment
A separate embodiment of the ’272 patent is described under the
heading “Hybrid Firewall.” Ex. 1001, 21:35–24:60. The description begins
with a discussion of Figure 20 of the patent. Id. at 21:35–64. 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:35–36. 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:36–39. Each personal computer 2015 comprises personal firewall 2035
IPR2019-00561
Patent 8,365,272 B2

11

(denoted as 2035a, 2035b, etc.) and application 2040 (denoted as 2040a,
2040b, etc.). Id. at 21:42–44.
Network firewall 2010 comprises first NIC 2020, NAT gateway 2025,
and second NIC 2030. Id. at 21:39–42. 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. Network firewall
2010 performs a similar translation on the MAC addresses3 of the personal
computers 2015. Id. at 21:50–52.
According to the ’272 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:52–59.
Further according to the ’272 patent, personal firewall 2035 also
performs security measures such as antivirus, anti-spyware, anti-adware, etc.
“Because 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 21:60–64.
Figure 21 shows network system 2100 with a “hybrid fire wall.”
Ex. 1001, 21:65–66. Figure 21 follows:

3 The MAC (Media Access Control) address is an identifier assigned to a
computer by its manufacturer. Ex. 1019, 42:6–8.
IPR2019-00561
Patent 8,365,272 B2

12

Figure 21 shows network system 2100 comprising hybrid firewall
2110 in accordance with an embodiment of the ’272 patent. Id. at 21:65–67.
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 21:67–22:3. 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:7–8.
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:9–11. 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-00561
Patent 8,365,272 B2

13

2115b (denoted as IP address y) into public IP address z, thus hiding the IP
addresses of the personal computers. Id. at 22:15–21. The network firewall
2110 performs a similar translation on the MAC addresses of the personal
computers 2115. Id. at 22:21–23.
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 of Figure 20, it can stop
malicious code before it enters the system 2100. Id. at 22:24–28. “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:28–31.
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:32–35. This enables hybrid firewall 2110 to “act as a personal firewall
2035 to handle application-level security.” Id. at 22:35–38.
E. Illustrative Claims
The ’272 patent has 19 claims. Claims 1, 7, and 16 are independent
claims, and the only claims challenged in the Petition. Pet. 3. Claim 1
recites4:
1. A computer, comprising:
[1.1] a processor and memory;
[1.2] an application associated with an application address;

4 Paragraph numbering in accordance with the Petition has been added to the
claims.
IPR2019-00561
Patent 8,365,272 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] a network address translation engine configured to translate
between the application address and a public address; and
[1.5] a driver coupled to the network interface, the driver for
automatically forwarding the outgoing data packets to the
network address translation engine to translate the application
address to the public address, and for automatically forwarding
the incoming data packets to the network address translation
engine to translate the public 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
mobile device 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 mobile
device security policy.
Ex. 1001, 24:62–25:18.
Claim 7 recites:
7. A system, comprising:
[7.1] a network interface coupled to an external network;
[7.2] a firewall in communication with the network interface, the
firewall configured to handle both network-level security and
application-level security;
[7.3] a computer in communication with the firewall, the
computer having one or more applications, each of the one or
more applications associated with at least one application
address, and the computer being configured to send to the
firewall data packets identifying the one or more applications to
the firewall; and
[7.4] 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;
IPR2019-00561
Patent 8,365,272 B2

15

[7.5] the firewall being configured to:
reject the data packets if the data packets include malicious
content according to a mobile device security policy; and
[7.6] allow the data packets to pass to the one or more
applications if the data packets do not include malicious content
according to the mobile device security policy.
Id. at 25:34–56 (emphasis added).
Claim 16 is a method claim that is similar to claim 7. Claim 16
recites:
16. A method within a computer of processing outgoing data,
the method comprising:
[16.1] receiving the outgoing data from an application, the
application being associated with an internal address;
[16.2] translating, using a network address translation engine
within the computer, the internal address into a public address;
[16.3] routing, using a driver within the computer, at least a
subset of the outgoing data to an external network using the
public address, thereby dynamically isolating the internal
address from the external network; and
[16.4] providing, using a network interface within the computer,
the subset of the outgoing data to the external network.
Id. at 26:37–48 (emphasis added).
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. U.S. Patent App. Pub. No. 2005/0055578 A1 (Ex. 1006, “Wright”)
Pet. 3.
In addition, Petitioner relies on admitted prior art (APA), specifically
Figure 18 of the ’272 patent, reproduced supra, and the accompanying
description in the specification. Pet. 38–39.
IPR2019-00561
Patent 8,365,272 B2

16

Both parties rely on expert testimony. Petitioner has submitted a
Declaration of Dr. Markus Jakobsson (Ex. 1018, “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. 1019, “Medvidovic Dep.”).
Finally, Petitioner has submitted Dr. Medvidovic’s declaration (Ex.
1026) and deposition testimony (Ex. 1028) from the district court action
involving the ’272 patent.
G. Asserted Grounds of Unpatentability
Petitioner asserts the challenged claims are unpatentable on the
following grounds:
Claim(s)
Challenged
Statutory Basis5 References
7 35 U.S.C. § 103 Sikdar, Wright
1, 16 35 U.S.C. § 103 Sikdar, APA
1, 16 35 U.S.C. § 103 APA, Sikdar
Pet. 3

5 Because the effective filing date of the application from which the ’272
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-00561
Patent 8,365,272 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 ’272 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 ‘272 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 ’272 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-00561
Patent 8,365,272 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. 10.
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. 10. 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.
IPR2019-00561
Patent 8,365,272 B2

19

In our Decision instituting review, we agreed with Patent Owner that
we did not need to construe this term. Only terms that are in 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” (claims 7 and 16)
Neither party initially requested construction of the limitation
“dynamically isolating” appearing in claims 7 and 16. Ex. 1001, 25:47–48,
26:46, 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. 12, 21. Thus, we provided a construction of this term in
our Institution Decision, as it was necessary to our evaluation of this
argument. Institution Dec. 11.
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.46 recites “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.” Id. (citing Ex. 1001, 25:45–49). We further observed
that the language of claim 7 describes “dynamically isolating” as a result of

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

IPR2019-00561
Patent 8,365,272 B2

20

the translation by the network translation engine of “at least one application
address of the one or more applications to a public address.” Id.
We referred to the specification of the ’272 patent, specifically, the
section headed “Dynamic Isolation,” describing Figure 19 of the ’272 patent
as “a network system 1900 that performs dynamic address isolation.” Id.
(citing Ex. 1001, 19:30–31). 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:52–65).
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. at
12–13.
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
IPR2019-00561
Patent 8,365,272 B2

21

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:
“Pertaining to an operation that occurs at the time it is needed rather than at
a predetermined or fixed time.” Id. (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. (quoting Ex. 3003). Thus, for our
Institution Decision, we construed “dynamically” as used in “dynamically
isolating” in the ’272 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. 1009 (RFC 3022), 3–4.
Patent Owner disputes this construction. PO Resp. 13–15. 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 13. Thus, Patent Owner
proposes the following construction: “[A person of ordinary skill] would
understand the term ‘dynamically isolating’ in the context of the ‘272 Patent
to mean ‘the use of a dynamic address protocol to isolate applications.’” Id.
at 15 (citing Medvidovic Decl. ¶ 54).
Petitioner contends our initial construction is correct and we should
“reject” Patent Owner’s construction. Pet. Reply 2. After considering
Patent Owner’s arguments, we are still persuaded that, for the reasons given
IPR2019-00561
Patent 8,365,272 B2

22

in our Institution Decision and summarized supra, our initial construction is
correct.
Patent Owner does not provide persuasive support in the intrinsic
record for its construction. Thus, Patent Owner does not demonstrate that
the term “dynamic address protocol” appears anywhere in the claims, patent
specification, or the prosecution history. As Petitioner points out, in the
challenged claims, the term “dynamically” modifies “isolating,” not
“address protocol,” which term does not appear in the claims. Id. at 3.
Patent Owner’s construction fails because it would rewrite the claims and
specification to substitute “use of a dynamic address protocol” for
“dynamically isolating.” PO Resp. 15.
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 ’272
patent. Medvidovic Dep. 33:13–34:6. 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. 14 (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 ’272 patent. Instead, we credit the testimony of Dr.
Jakobsson that Patent Owner’s proposed construction “obfuscates, rather
than clarifies the limitation’s meaning.” Jakobsson Supp. Decl. ¶ 14. Dr.
IPR2019-00561
Patent 8,365,272 B2

23

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 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 that under our
construction, “‘dynamically isolating’ can be understood to encompass any
other source of addresses.” PO Resp. 13. Dr. Jakobsson’s testimony on this
issue convinces us that this argument is unavailing. Jakobsson Supp. Decl.
¶ 19. 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 argument that “dynamic isolation”
refers only to “how addresses are selected for translation operations.” PO
Resp. 24–25. 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
IPR2019-00561
Patent 8,365,272 B2

24

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 ’272 patent, as well as
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.
3. “the subset” (claim 16)
The term “subset” appears twice in claim 16. The first occurrence
refers to “routing . . . at least a subset of the outgoing data to an external
network.” Petitioner asks us to “reject Patent Owner’s argument that ‘the
subset’ must be a ‘proper subset’ i.e., a set that is less than the full set of
outgoing data.” Pet. Reply 5.
Addressing this term in our Institution Decision, based on the claim
language “at least a subset of the outgoing data,” we rejected Patent Owner’s
argument. Institution Dec. 25–26. We observed that the inclusion of “at
least” modifying “subset” expands the phrase to read on providing any
portion of the outgoing data, up to and including all the data. Id. at 26
(citing MagSil Corp. v. Hitachi Global Storage Techs. Inc., 687 F.3d 1377,
1383 (Fed. Cir. 2012) (“Here, the claim term ‘change in the resistance by at
least 10%’ is very similar to the ‘open-ended’ term in Fisher because it has a
lower threshold, but not an upper limit.”) (citing In re Fisher, 427 F.2d 833
(CCPA 1970)).
IPR2019-00561
Patent 8,365,272 B2

25

Petitioner cites dictionary definitions and other additional authorities
to support this conclusion. Pet. Resp. 5–6 (citing, e.g., Exs. 1022, 1023,
1024). For example, A Dictionary of Computing defines “subset” as “[a] set
T whose members are all members of S …,” and contrasts it with a “proper
subset.” Ex. 1023, 3. We find further support for our construction in these
dictionary definitions.
The second occurrence of “subset” in claim 16 refers to
“providing . . . the subset of the outgoing data to the external network.”
Patent Owner contends that “Petitioner reads out any distinctions between
‘at least a subset’ and ‘a subset’ recited in the claims.” PO Resp. 45–46.
Further, Patent Owner asserts “the ‘providing’ step of the recited claims
requires ‘the subset,’ and not ‘at least a subset,’ of outgoing data to be
provided to the external network.” Id. at 47.
We are not persuaded by this argument. Instead, we find that the
antecedent in claim 16 for “the subset of the outgoing data” is the earlier-
recited “at least a subset.” This is supported by the authorities cited by
Petitioner, as well as the standard practice in claim drafting of signaling an
antecedent by using “said” or “the.” The Federal Circuit has observed that
while it is not always a rule that “the reference to an antecedent absolutely
requires a term to be consistently construed across uses,” “[a] word or phrase
used consistently throughout a claim should be interpreted consistently.”
Microprocessor Enhancement Corp. v. Texas Instruments Inc., 520 F.3d
1367, 1375 (Fed. Cir. 2008) (citations and internal quotations omitted).
We, therefore, find that the two references to “subset” in claim 16
should be construed broadly enough to read on providing any portion of the
outgoing data, up to and including all the data, and not a proper subset.
IPR2019-00561
Patent 8,365,272 B2

26

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).7 Ex. 1004, 8, 49.8
Figure 20 of Sikdar, which follows, illustrates this operation:

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

7 The combination of PAT and NAT is sometimes referred to as Network
Address Port Translation (NAPT). Jakobsson Decl. ¶ 61; Ex. 1010 (RFC
2663), 11.
8 Citations to Sikdar (Ex. 1004) refer to the original page numbers and not
the page numbers added by Petitioner.
IPR2019-00561
Patent 8,365,272 B2

27

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.9
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.10 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. RSP 100 also receives packet
1072 from local device 1078 in private network 24 that contains a private IP

9 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.
10 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-00561
Patent 8,365,272 B2

28

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. 1006, (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-00561
Patent 8,365,272 B2

29

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

Pet. 16. Figure 2A shows server system 200 that includes memory 242.
Ex. 1004 ¶¶ 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.
III. ANALYSIS OF THE CHALLENGED CLAIMS
The Petition challenges claims 1, 7, and 16 of the ’272 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
IPR2019-00561
Patent 8,365,272 B2

30

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”).
Patent Owner presents evidence on the fourth Graham factor. PO
Resp. 50–52. We, therefore, consider secondary considerations infra.
B. Sikdar and Wright (Claim 7)
Petitioner contends claim 7 would have been obvious over “Sikdar in
light of Wright.” Pet. 3. Petitioner’s analysis of claim 7 in relation to Sikdar
and Wright appears at pages 12–37 of the Petition. Petitioner supports its
analysis with testimony from its expert, Dr. Jakobsson. Jakobsson Decl.
¶¶ 67–119.
Petitioner summarizes its analysis as follows: “Sikdar discloses a
‘Reconfigurable Semantic Processor’ (‘RSP’) . . . that may perform network
address translation (‘NAT’) and port address translation (‘PAT’), in addition
to firewall functionality such as network-level security and application-level
security.” Pet. 14. Further, “Wright discloses a security system 200 that
provides security services to laptops and other mobile devices that may be in
or out of a private enterprise network.” Id. at 15.
IPR2019-00561
Patent 8,365,272 B2

31

Petitioner presents an element-by-element analysis, contending that
each element of claim 7 is disclosed by Sikdar and Wright. Pet. 16–37. For
example, claim element 7.1 calls for “a network interface coupled to an
external network.” Referring to Figure 20, reproduced supra, Petitioner
contends Sikdar meets this limitation: “A [person of ordinary skill] would
understand that Sikdar’s Figure 20 discloses that the RSP’s input port 120
and output port 152 are coupled to public network 12 because Sikdar
discloses the RSP processing incoming packet 1061 from that network and
sending outgoing packet 1050 to that network.” Pet. 17 (internal quotes
omitted).
Claim element 7.2 calls for “a firewall in communication with the
network interface, the firewall configured to handle both network-level
security and application-level security.” Again referring to Figure 20 of
Sikdar, Petitioner asserts: “In Figure 20, Sikdar discloses firewall 1062 (a
firewall) that is in communication with the network interfaces referenced
above because it receives incoming packet 1061 from public network 12 via
those interfaces.” Pet. 18 (internal quotes omitted).
Claim element 7.3 calls for “a computer in communication with the
firewall, the computer having one or more applications, each of the one or
more applications associated with at least one application address, and the
computer being configured to send to the firewall data packets identifying
the one or more applications to the firewall.” Again referring to Figure 20 of
Sikdar, Petitioner identifies laptop computer 1078 as meeting this element.
Pet. 21. Petitioner contends the applications on the laptop (e.g., email) meet
the requirements of the claim for “one or more applications.” Id. at 21–24.
The “application address” limitation is met by the “socket address” of each
IPR2019-00561
Patent 8,365,272 B2

32

TCP/IP packet, consisting of an IP address (identifying the device) and TCP
port number, which together identify the application address. Jakobsson
Decl. ¶ 57; Pet. 9–10, 25.
Alternatively, with respect to the “firewall data packets identifying the
one or more applications to the firewall,” Petitioner contends that Wright
discloses use of an “application identifier.” Pet. 27–28.
Claim element 7.4 requires “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.” Petitioner contends the
description in Sikdar of “NAT/PAT operations” in connection with Figure
20 meets this limitation. Id. at 31.
Petitioner asserts: “Sikdar discloses that ‘the RSP 100 can be
programmed for NAT/PAT operations that convert IP addresses [and] port
numbers.’” Id. (citing Ex. 1004, 49, Fig. 20 (reproduced supra)). 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
a public address. 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.” Id. (citations omitted).
Patent Owner responds by challenging the sufficiency of this analysis:
“[A person of ordinary skill] would recognize that this analysis does not
demonstrate that Sikdar’s NAT/PAT technique involves ‘the use of DHCP
or other source of addresses in connection with a NAT engine to translate IP
addresses,’ let alone ‘the use of a dynamic address protocol to isolate
IPR2019-00561
Patent 8,365,272 B2

33

applications,’ as the term is properly construed.” PO Resp. 21–22 (citing
Medvidovic Decl. ¶ 73). Further, Patent Owner argues: “Given Petitioner’s
failure in this respect, Petitioner cannot now rely on the Board to supply its
own logic and provide its own arguments.” Id. at 22 (citation omitted).
Our construction of “dynamically isolating” specifically refers to
using “DHCP or other source of addresses.” Institution Dec. 12. 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 (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
IP addresses” in Sikdar. Jakobsson Supp. Decl. ¶ 27. In this rebuttal
testimony, Dr. Jakobsson does not directly address Patent Owner’s
argument, but instead refers back to 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. 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
IPR2019-00561
Patent 8,365,272 B2

34

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 discussed supra, in support of its argument that the SPU (Semantic
Processing Unit) in Sikdar is a source of IP addresses, Petitioner relies on
the statement in Sikdar that the SPU “generates” the public IP address. See,
e.g., Pet. Reply 7 (citing Ex. 1004, 51); Jakobsson II Dep. 74:12–16 (same).
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 7.
We find that Sikdar differs from the ’272 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 ’272
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–
26. Further, we find that, unlike the ’272 patent’s disclosure of using DHCP
IPR2019-00561
Patent 8,365,272 B2

35

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.” Jakobsson 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.
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.”11
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 realtime.” Pet. Reply 7–8; Jakobsson Supp.
Decl. ¶ 29 (“I contend that Sikdar discloses the ‘dynamically isolating’
limitation in part because its NAT/PAT operation 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

11 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-00561
Patent 8,365,272 B2

36

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
claim 7 is obvious over Sikdar and Wright.
C. Sikdar and APA (Claims 1 and 16)
Petitioner presents this challenge to claims 1 and 16 as two separate
grounds. In one (“Ground 2”), Sikdar is the primary reference. Pet. 39–52.
In the second (“Ground 3”), APA is the primary reference. Id. at 53–67.
1. Claim 1
We focus first on the challenge in which the APA is the primary
reference (“Ground 3”). This is consistent with Petitioner’s presentation at
the oral hearing, which focused on Ground 3. See Hearing Tr. 8:26–9:4
(“Ground three is important and it invalidates Claims 1 and 16”).
We note that, unlike claims 7 and 16, claim 1 does not recite
“dynamically isolating.” Nor is claim 1 (unlike claim 7) directed to the
“hybrid firewall” embodiment, discussed supra, in which an “application
sensitive” firewall is capable of performing both network and personal
firewall security measures. Ex. 1001, 22:28–31. In that sense, claim 1 is
broader that the other challenged claims.
Petitioner’s element-by-element analysis of claim 1 in relation to the
combinations of Sikdar and APA appears at pages 39–47 and 53–64 of the
Petition. In the Ground 3 challenge to claim 1, with APA as the primary
reference, Petitioner relies on the APA for all claim elements except
elements 1.4 (“a network address translation engine configured to translate
between the application address and a public address”) and a portion of
elements 1.5 and 1.6 (the “network address translation” element discussed
IPR2019-00561
Patent 8,365,272 B2

37

supra). Pet. 55–64. For the network address translation engine limitation,
Petitioner relies only on Sikdar. Id. at 55.
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 ’272 patent and the elements of claim 1 is the
inclusion, in claim 1, of a network translation engine to translate the IP
addresses. See Pet. 4 (“The ’272 patent proposes solving this purported
problem by adding a NAT engine 1945 to the computer of Figure 18, as
shown below 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 Dr. Jakobsson’s supporting testimony, we find that for the reasons given
there and summarized in this Decision, Figure 18 of the ’272 patent and the
accompanying description teaches or suggests the following aspects of claim
1: preamble “computer” (even if limiting),12 “processor and memory,”
“application associated with an application address,” “network interface,”
and “driver” (excluding the “network address translation engine”). Id. at
53–64; Jakobsson Decl. ¶¶ 159–181. For example, Dr. Jakobsson testifies
that Figure 18 of the ’272 patent (the APA) shows a computer including an
operating system, applications, and NICs. Jakobsson Decl. ¶ 159. He
testifies that the APA inherently discloses a processor and memory. Id.

12 Patent Owner asserted in district court that the preamble is not limiting.
See Pet. Reply 12–13 (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” 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-00561
Patent 8,365,272 B2

38

¶ 160. He testifies that the APA discloses applications 1 through m, and at
least one application has an IP address (IP address x). Id. ¶ 162. He testifies
the APA discloses NICs 1 through n. Id. ¶ 163. He testifies that the APA
discloses an intermediate driver that automatically forwards incoming data
packets to the firewall. Id. ¶ 171
Petitioner asserts the element missing in Figure 18, the network
address translation engine, is taught or suggested by Sikdar. Id, at 55, 58–
59. We agree and find that Sikdar teaches or suggests the claimed “network
address translation engine.” In analyzing claim 7, supra, we discussed the
operation of Sikdar’s NAT/PAT conversion and concluded that while Sikdar
discloses isolation of internal IP addresses by translating them to an external
IP address, Sikdar does not teach or suggest “dynamically isolating”
applications from the external network. However, as stated previously,
“dynamically isolating” is not a limitation in claim 1. For the reasons
discussed supra in connection with claim 7, we find that Sikdar teaches a
network address translation engine for translating between private
application IP addresses and a public IP address. We will discuss infra
Patent Owner’s additional 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 prior art
software-based firewall in Figure 18. Pet. 55 (citing Jakobsson Decl. ¶ 165).
Petitioner argues: “Motivation to do so arises from Sikdar, which discloses
that NAT and PAT functionality can be integrated with a firewall.” Id. at
56. Petitioner argues further: “Additional motivation arises from the ’272
IPR2019-00561
Patent 8,365,272 B2

39

patent’s Figures 17 and 20, both of which are admitted prior art and show
network address translation occurring in a firewall.” Id. at 57.
Patent Owner’s response to Ground 3 challenges the rationale to
combine the references in the way proposed by Petitioner in that Ground.
PO Resp. 48–49. Patent Owner contends that it “makes no sense” to
incorporate Sikdar’s NAT engine in the APA. Id. at 48. 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. ¶ 116). Patent
Owner continues: “That is, traditional NAT/PAT devices like those
disclosed in Sikdar and FIG. 17 of the ‘272 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.
(quoting Jakobsson I Decl. ¶ 168).
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. 55–58; Pet. Reply 23–25. As Petitioner points out, the RSP “does not
include any NICs . . ., which are a separate hardware component.” Pet.
Reply 24. We agree with Petitioner that Patent Owner’s argument is not
convincing.
IPR2019-00561
Patent 8,365,272 B2

40

More importantly, however, Patent Owner’s argument fails because in
Ground 3, 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. at 24–25 (citing Pet. 55–58)
(emphasis 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, Petitioner’s combination of the APA and Sikdar in Ground 3
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 25 (citing Pet. 55–58; Jakobsson Supp. Decl.
¶ 65).
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
IPR2019-00561
Patent 8,365,272 B2

41

Decl. ¶¶ 164–170. We find that using NAT/PAT conversion for the purpose
of protecting private IP addresses was well-known in the prior art to the ’272
patent, and in fact is described in the ’272 patent. Jakobsson Decl. ¶ 61; Ex.
1001, Fig. 17, 18:45–51. Similarly, we find the advantages of using
NAT/PAT conversion to protect the identity of 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. Ex. 1004,
49–50; Jakobsson Decl. ¶ 128; Ex. 1009, 1010. Also, we find the benefits of
adding NAT/ PAT translation to firewalls were well-known in the prior art,
and in fact acknowledged in the ’272 patent. Jakobsson Decl. ¶ 126; Ex.
1001, 18:56–62; 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 ’272 patent would have amounted to application of a
known technique to a known system to achieve predictable results.
Jakobsson Decl. ¶ 175. “[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 ’272 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. ¶ 168 (“Although firewall 1715 in Figure 17 is
‘hardware-based,’ this would not discourage a [person of ordinary skill]
IPR2019-00561
Patent 8,365,272 B2

42

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.”).
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 (whether or
not combined with Sikdar) “fails to disclose ‘a network address translation
engine configured to translate between the application address and a public
address.’” Pet. Reply 48. When pressed at the oral hearing, Patent Owner’s
counsel explained that theory 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.
Sikdar doesn’t disclose that at all. It never discloses any type of
application that’s associated with an address.
IPR2019-00561
Patent 8,365,272 B2

43

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 language of claim
1 of the ’272 patent requires that the claimed computer be “application
sensitive,” or have knowledge of the applications. Hearing Tr. 79:14–16.
Contrast the lack of any recitation indicating application sensitivity in claim
1 with claim 7, directed to the “hybrid firewall” embodiment, which the ’272
patent specifically describes as “application sensitive.” Ex. 1001, 22:28–31.
Thus, claim 7 includes a hybrid firewall limitation not present in claim 1,
specifically, “a firewall . . . configured to handle both network-level security
and application-level security.” 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:34–35.
Claim 1 of the ’272 patent does recite translating “application
addresses.” At the hearing, Patent Owner’s counsel identified an IP address
in the ’272 patent as an example of an “application address”:
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
IPR2019-00561
Patent 8,365,272 B2

44

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 ’272 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:22–24 (emphasis added). Expressed in terms
of Dr. Medvidovic’s analogy, the applications in the ’272 patent share the
same apartment building, but not the same apartment, and therefore have the
same IP address.
Thus, we are unconvinced of any difference material to our
understanding of claim 1 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
IPR2019-00561
Patent 8,365,272 B2

45

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 ’272 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. 21–23; Jakobsson Decl. ¶¶ 88–91. 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. 25 (citing Jakobsson Decl. ¶ 95). 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 APA
and Sikdar as described in Ground 3 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.
Because Ground 3 is dispositive of the obviousness challenges to this
claim, we do not address the challenge in which Sikdar is the primary
reference (“Ground 2”).
2. Claim 16
Petitioner provides an element-by-element analysis of claim 16 in
relation to Sikdar and the APA (Ground 2) and the APA and Sikdar (Ground
3). Pet. 47–52 (Ground 2), 64–67 (Ground 3). Claim 16, a method claim,
IPR2019-00561
Patent 8,365,272 B2

46

differs from claim 1, including that it recites “dynamically isolating.” Claim
element 16.3 recites “routing, using a driver within the computer, at least a
subset of the outgoing data to an external network using the public address,
thereby dynamically isolating the internal address from the external
network.” Pet. 48 (emphasis added).
In one challenge (Ground 2), Sikdar is the primary reference and
supplies the teachings of routing and dynamic isolation of internal addresses,
while the APA discloses the NDIS driver routing outgoing data packets to
the external network. Id. at 48–49. In the second challenge (Ground 3), the
APA is the primary reference and provides the teaching of routing using a
driver. Id. at 65. In both challenges, however, Petitioner relies on Sikdar to
meet the “dynamically isolating” limitation. Pet. 48, 65. For example, in
Ground 3, Petitioner asserts: “It would have been obvious to a [person of
ordinary skill] to incorporate the Sikdar NAT (and PAT) functionality into
the [APA] . . . . Doing so would dynamically isolate the internal address (IP
address X) from the external network by translating it to a different, public
address.” Pet. 65 (internal quotes omitted). In Ground 2, Petitioner relies
also on Sikdar to meet the “dynamically isolating” limitation: “Sikdar
discloses that the RSP can dynamically isolate the internal address from the
external network by routing the outgoing data with the public address to the
external network.” Id. at 48.
Patent Owner responds to these challenges to claim 16 with arguments
similar to those presented with respect to the other challenged claims. First,
responding to Ground 3, Patent Owner argues that the references fail to
disclose “a network address translation engine.” PO Resp. 48. Similar to
the arguments for claim 1, for claim 16, Patent Owner asserts the APA and
IPR2019-00561
Patent 8,365,272 B2

47

Sikdar would not have been combined because of the two NICs in Sikdar
and Sikdar’s input and output ports. Id. These arguments are not persuasive
for the reasons already given in our discussion of claim 1.
Also unavailing is Patent Owner’s argument based the claim language
“at least a subset of the outgoing data.” PO Resp. 45–47. This argument is
predicated on our acceptance of Patent Owner’s proposed construction of
“subset” in claim 16 as a “proper subset.” See discussion supra. As we
have rejected Patent Owner’s proposed construction, we see no merit in this
argument.
Of greater merit is Patent Owner’s argument that Sikdar fails to teach
or suggest “dynamically isolating.” PO Resp. 44. We found, with respect to
claim 7, supra, that Petitioner had failed to demonstrate by a preponderance
of the evidence that Sikdar teaches or suggests the dynamic isolation
required by claim 7. We reach the same conclusion with respect to claim
16’s requirement for “dynamically isolating,” for the reasons already given.
We, therefore, determine that Petitioner has not succeeded in demonstrating
by a preponderance of the evidence that claim 16 would have been obvious
over the combination of Sikdar and the APA.
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. 50–52. 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.
IPR2019-00561
Patent 8,365,272 B2

48

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).
Patent Owner cites no testimonial evidence in support of its assertions
of secondary considerations, but relies instead on statements in the ’272
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. 50.
Further, Patent Owner asserts “the recognition of a problem, long-felt
need, and failure by others all demonstrate that the ‘272 Patent was not
obvious.” Id. at 52. 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 responds that this evidence “should be given no weight.”
Pet. Reply 26. Petitioner asserts “Patent Owner has not established a nexus
between its cited secondary considerations evidence and the merits of ’272
IPR2019-00561
Patent 8,365,272 B2

49

patent’s challenged claims (as opposed to mobile security or network
security generally).” Id. (emphasis original).
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
patented invention.” Fox Factory, Inc., 944 F.3d at 1373 (internal quotes
omitted); Lectrosonics, Inc. v. Zaxcom, Inc., Case IPR2018-01129, Paper 33
(Jan. 24, 2020) (precedential) (addressing Fox Factory and nexus to
objective indicia of non-obviousness).
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 ’272 patent that an industry
conference in December 2005 “highlighted” mobile security, and “no
complete solutions were presented.” PO Resp. 39 (citing Ex. 1001, 2:14–
18). 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 51 (citing Ex. 2007, 3). We have considered this evidence and do not find
IPR2019-00561
Patent 8,365,272 B2

50

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 of presenting independent
evidence of known technical or manufacturing problems that would result in
skepticism by experts, 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. PO Resp. 52. See In re
Magna Electronics, Inc., 611 Fed.App’x. 969, 973 (Fed. Cir. 2015) (“Nor
can Magna substantiate its claim of skepticism of 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 7
or 16 of the ’272 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.

IPR2019-00561
Patent 8,365,272 B2

51

V. ORDER
Upon consideration of the record before us, it is:
ORDERED that claims 7 and 16 of the ’272 patent are not determined
to be unpatentable;
FURTHER ORDERED that claim 1 of the ’272 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. 14

13 Because we find that Petitioner has demonstrated that claim 1 would have
been obvious in light of APA and Sikdar, is it unnecessary for us to reach
this alternative ground of unpatentability proposed by Petitioner for claim 1.
See supra.
14 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
Claim(s) 35 U.S.C. § Reference(s)
Claim(s)
Shown
Unpatentable
Claim(s)
Not shown
Unpatentable
7

103 Sikdar,
Wright

7
1, 16

10313 Sikdar, APA 16
1, 16 103 APA, Sikdar

1 16
Overall
Outcome
1

7, 16
IPR2019-00561
Patent 8,365,272 B2

52

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

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).