Amazon Technologies, Inc.

Patent Trials and Appeals Board

Apr 30, 2020

15013452 - (D) (P.T.A.B. Apr. 30, 2020)

UNITED STATES PATENT AND TRADEMARK OFFICE
UNITED STATES DEPARTMENT OF COMMERCE
United States Patent and Trademark Office
Address: COMMISSIONER FOR PATENTS
P.O. Box 1450
Alexandria, Virginia 22313-1450
www.uspto.gov
APPLICATION NO. FILING DATE FIRST NAMED INVENTOR ATTORNEY DOCKET NO. CONFIRMATION NO.
15/013,452 02/02/2016 Gregory A. Rubin 170105-1142 6471
71247 7590 04/30/2020
Client 170101 c/o
THOMAS HORSTEMEYER, LLP
3200 WINDY HILL RD SE
SUITE 1600E
ATLANTA, GA 30339
EXAMINER
LAKHIA, VIRAL S
ART UNIT PAPER NUMBER
2431
NOTIFICATION DATE DELIVERY MODE
04/30/2020 ELECTRONIC
Please find below and/or attached an Office communication concerning this application or proceeding.
The time period for reply, if any, is set in the attached communication.
Notice of the Office communication was sent electronically on above-indicated "Notification Date" to the
following e-mail address(es):
docketing@thomashorstemeyer.com
uspatents@tkhr.com
PTOL-90A (Rev. 04/07)
UNITED STATES PATENT AND TRADEMARK OFFICE
____________

BEFORE THE PATENT TRIAL AND APPEAL BOARD
____________

Ex parte GREGORY A. RUBIN
____________

Appeal 2019-001833
Application 15/013,452
Technology Center 2400
____________

Before JEFFREY S. SMITH, JASON V. MORGAN, and
JAMES B. ARPIN, Administrative Patent Judges.

ARPIN, Administrative Patent Judge.

DECISION ON APPEAL
Appellant1 appeals under 35 U.S.C. § 134(a), the Examiner’s final
rejections of claims 2–21. Final Act. 2.2 Claim 1 is cancelled. Appeal

1 “Appellant” here refers to “applicant” as defined in 37 C.F.R. § 1.42.
Appellant identifies the real party-in-interest as Amazon Technologies, Inc.,
the assignee of record, which is a subsidiary of Amazon.com, Inc. Appeal
Br. 2.
2 In this Decision, we refer to Appellant’s Appeal Brief (“Appeal Br.,” filed
September 14, 2018) and Reply Brief (“Reply Br.,” filed December 26,
2018); the Final Office Action (“Final Act.,” mailed February 16, 2018), the
Advisory Action (“Adv. Act.,” mailed May 3, 2018), and the Examiner’s
Answer (“Ans.,” mailed November 5, 2018); and the Specification (“Spec.,”
filed February 2, 2016). Rather than repeat the Examiner’s findings and
determinations and Appellant’s contentions in their entirety, we refer to
these documents.
Appeal 2019-001833
Application 15/013,452

2

Br. 16 (Claims App.). We have jurisdiction under 35 U.S.C. § 6(b).
We affirm.
STATEMENT OF THE CASE
Appellant’s claimed invention relates to methods and systems “for
dynamically updating access policies for computing nodes on a network
upon discovering attacks on the network.” Spec. ¶ 11. In particular, such
methods and systems
monitor[] for network attacks [by] monitor[ing] dropped
communications and traffic from allocated computing nodes.
[C]ustomers using the computing nodes define and specify
groups of one or more source nodes that are authorized to
communicate with groups of one or more destination nodes, such
as when a source node and destination node both belong to a
common group of nodes, as illustrated in FIG. 4. Unauthorized
communications to a computing node are dropped or discarded
by the data transmission manager associated with the computing
node. In this implementation, a target class of computing nodes
includes allocated computing nodes with dropped
communications by the Network Diagnostic System 145.
Id. ¶ 38, Fig. 4; see id. ¶¶ 13, 16, 39, 40, 42.
As noted above, claims 2–21 stand rejected. Claims 2, 8, and 15 are
independent. Appeal Br. 16 (claim 2), 18 (claim 8), 20 (claim 15) (Claims
App.). Claims 3–7 depend directly or indirectly from claim 2, claims 9–14
depend directly from claim 8, and claims 16–21 depend directly or indirectly
from claim 15. Id. at 16–22.
Each of claims 2 and 15 recites “[a] method,” and claim 8 recites “[a]
system, comprising: at least one computing device comprising a processor
and memory; and a data transmission system manager executable in the at
least one computing device, the data transmission system manager
Appeal 2019-001833
Application 15/013,452

3

configured to” perform functions, substantially as recited in claim 2. Id. at
16, 18, 20. The Examiner relies on the same references and substantially
similar arguments in rejecting claims 2, 8, and 15. Final Act. 11–12
(claim 2), 13–15 (claim 8), 16–18 (claim 15). Appellant relies on
substantially the same contentions and evidence in contesting the rejection
of claims 2, 8, and 15; and Appellant does not contest the rejections of
claims 3–7, 9–14, and 16–21 separately from the rejection of claims 2, 8,
and 15. See Appeal Br. 4–14. Therefore, because the issues regarding
independent claim 2 are dispositive with respect to the obviousness
rejections, we focus our analysis on independent claim 2 and the disputed
and overlapping limitations recited in independent claims 8 and 15.
Claim 2, reproduced below with disputed limitations emphasized, is
representative.
2. A method comprising:
monitoring, by a network diagnostic system, a data
communication dropped by a first transmission manager
servicing a first virtual machine allocated to a user;
determining, by the network diagnostic system, that the
dropped data communication is a form of network attack by
tracking a number of attempted data communications from a
source of the dropped data communication against virtual
machine nodes in a target class and comparing the number
against a threshold value; and
causing, by the network diagnostic system, a list of one or
more internet protocol addresses associated with the source of
the dropped data communication to be generated and sent to at
least one second transmission manager servicing at least one
second virtual machine that is not part of the target class, wherein
the at least one second transmission manager is configured to
drop communications from an internet protocol address
contained on the list.
Appeal 2019-001833
Application 15/013,452

4

Id. at 16 (emphases added).
REFERENCES AND REJECTIONS
The Examiner relies upon the following references in rejecting the
claims:
Name3 Number Issued/Publ’d Filed
Weis US 2007/0016663 A1 Jan. 18, 2007 July 14, 2005
Xiao US 2010/0251334 A1 Sept. 30, 2010 May 14, 2010
Narayanaswamy US 2011/0055921 A1 Mar. 3, 2011 Oct. 28, 2009
Annamalaisami US 2011/0320617 A1 Dec. 29, 2011 June 24, 2010
Rubin ’348 US 8,499,348 B1 July 30, 2013 Dec. 28, 2010
Rubin ’319 US 9,258,319 B1 Feb. 9, 2016 June 28, 2013
Specifically, claims 2–21 stand rejected under the judicially-created doctrine
of obviousness-type double patenting in view of claims 1–20 of Rubin ’348
and in view of claims 1–18 of Rubin ’319. Final Act. 3–10. Claims 2, 3, 7,
8, 10–12, and 14–19 also stand rejected as unpatentable under 35 U.S.C.
§ 103 over the combined teachings of Narayanaswamy and Annamalaisami.
Id. at 10–19. Further, claims 4, 5, 13, 20, and 21 stand rejected as
unpatentable under 35 U.S.C. § 103 over the combined teachings of
Narayanaswamy, Annamalaisami, and Xiao (id. at 20–22); and claims 6 and
9 stand rejected as unpatentable under 35 U.S.C. § 103 over the combined
teachings of Narayanaswamy, Annamalaisami, and Weis (id. at 22–23).
Appellant contests the obviousness rejection of independent claim 2
(Appeal Br. 5–10) and relies on the alleged deficiencies in that rejection to
overcome the rejections of the other independent claims and of the

3 All reference citations are to the first named inventor only.
Appeal 2019-001833
Application 15/013,452

5

dependent claims (id. at 11–14). Because we determine that affirmance of
the rejection of independent claim 2 is dispositive with respect to the
obviousness rejections; except for our ultimate decision, we do not discuss
the merits of the rejections of claims 3–21 further herein. We review the
appealed rejection of independent claim 2 for error based upon the issues
identified by Appellant, and in light of the contentions and evidence
produced thereon. Ex parte Frye, 94 USPQ2d 1072, 1075 (BPAI 2010)
(precedential). For the reasons given below, we affirm the Examiner’s
rejections.
ANALYSIS
1. Non-Provisional, Obviousness-Type Double Patenting Rejection
As noted above, the Examiner rejects claims 2–21 under the
judicially-created doctrine of obviousness-type double patenting in view of
claims 1–20 of Rubin ’348 and in view of claims 1–18 of Rubin ’319. Final
Act. 3–10. Appellant does not contest this rejection. Therefore, because
each of Rubin ’348 and Rubin ’319 is an issued patent, we summarily affirm
this rejection.
2. Obviousness of Claim 2 over Narayanaswamy and Annamalaisami
As noted above, the Examiner rejects independent claim 2 as obvious
over the combined teachings of Narayanaswamy and Annamalaisami. Final
Act. 11–12. In particular, the Examiner finds Narayanaswamy teaches or
suggests “determining, by the network diagnostic system, that the dropped
data communication is a form of network attack by tracking a number of
attempted data communications from a source of the dropped data
communication against . . . nodes in a target class and comparing the number
Appeal 2019-001833
Application 15/013,452

6

against a threshold value.” Id. at 11 (citing Narayanaswamy, Figs. 2, 5, 6;
¶¶ 36, 46, 47); see Appeal Br. 16 (Claims App.). The Examiner further finds
that Annamalaisami teaches or suggests “dropped packets detected on
Virtual machine.” Final Act. 12 (citing Annamalaisami, Fig. 4A, ¶¶ 149,
150, 152–159, 163, 168). Thus, the Examiner finds that Narayanaswamy
and Annamalaisami together teach or suggest the “determining” step, as
recited in claim 2.
In particular Narayanaswamy discloses:
[Intrusion detection and prevention (IDP)] 10 applies the
attack definitions to the elements and the protocol-specific
anomalies identified by the protocol decoders to detect and
prevent network attacks. For example, a system administrator
may specify a compound network attack that includes the
protocol anomaly of repeated [File Transfer Protocol (FTP)]
login failure and a pattern that matches a login username of
“root.” In this manner, the system administrator may combine
pattern analysis with protocol anomalies to define complex
attack definitions. In the event of a network attack, IDP 10 takes
one or more programmed actions, such as automatically
dropping packet flows associated with the application-layer
communications within which the network attack was detected.
Narayanaswamy ¶ 36 (emphasis added); see id. ¶¶ 46–47. The “Examiner
interprets the flow of attack analysis as following – packets are dropped and
analyzed as ‘bot attack’ which is similar to detection of network attack.”
Adv. Act. 3; see Ans. 4–5. Appellant disagrees.
Appellant contends, “Narayanaswamy clearly discloses that a network
attack is detected using attack definitions and a programmed response is
performed in response to the detected network attack that can include
dropping packet flows.” Appeal Br. 8 (emphasis added); Reply Br. 6. Thus,
“Narayanaswamy does not determine or detect a network attack on the basis
Appeal 2019-001833
Application 15/013,452

7

of dropped data communications. Instead, Narayanaswamy discloses that
data communications may be dropped after a network attack is detected.”
Appeal. Br. 11 (referring to the overlapping limitation of claim 8). In
particular, Narayanaswamy discloses, “[i]n the event of a network attack,
IDP 10 takes one or more programmed actions, such as automatically
dropping packet flows associated with the application-layer communications
within which the network attack was detected.” Narayanaswamy ¶ 36; see
id. ¶ 46 (“When stateful inspection engine 28 detects a flood attack, stateful
inspection engine 28 executes a programmed response, such as . . .
instructing forwarding component 31 to drop packets of the packet flow”).
In response to Appellant’s contention,
Examiner notes that argued limitation, of [“]Network
attack detection based on dropped data packets[”]. Examiner
adds that although [“]dropped data packets[”] is known term in
art, the cause for [“]dropped data packets[”] can be A. loss of
power to system or B. malicious user or bot attack or flooding of
data both the causes for [“]dropped data packets[”] are known in
art, however understanding the cause of [“]dropped data
packets[”] is relevant in determining what is the prime factor for
[“]dropped data packets[”]. Examiner notes – how does the
system know that [“]dropped data packets[”] is factor to
determine [“]network attack[”] as it can be scenario A (loss of
power).
Ans. 3–4. The Examiner “interprets claim language in view of specification
and as known of concepts in art,” but fails to provide sufficient evidence
supporting either the response to Appellant’s contention or this interpretation
of the claim language. Ans. 4 (citing Spec., Fig. 4B, ¶¶ 61–63).
Consequently, we do not find the Examiner’s response persuasive. See
Reply Br. 4–5.
Nevertheless, as noted above, claim 2 recites “determining . . . that the
Appeal 2019-001833
Application 15/013,452

8

dropped data communication is a form of network attack by tracking a
number of attempted data communications from a source of the dropped data
communication against virtual machine nodes in a target class and
comparing the number against a threshold value” Appeal Br. 16 (Claims
App.) (emphases added). Consequently, in order to assess the Examiner’s
combination of the teachings of Narayanaswamy and Annamalaisami, we
must interpret the claim terms “the dropped data communication” and
“attempted data communications.” The Specification describes
“communications include transmissions of data (e.g., messages, data packets
or frames, etc.) between nodes hosted on the same physical machine or
distinct physical machines over one or more networks.” Spec. ¶ 11. We
understand that such communications also may occur between the same or
distinct virtual machines. See id. ¶ 12. As the Specification explains,
network attacks may be detected by monitoring dropped communications.
See id. ¶¶ 38–40 (quoted above). More specifically, the Specification
explains that
customers using the computing nodes define and specify groups
of one or more source nodes that are authorized to communicate
with groups of one or more destination nodes . . . . Unauthorized
communications to a computing node are dropped or discarded
by the data transmission manager associated with the computing
node.
Id. ¶ 38 (emphases added). Further, the Specification explains:
The determination of authorization by the [transmission
manager] may, for example, be based at least in part on defined
data transmission policies that specify groups of one or more
source nodes that are authorized to communicate with groups of
one or more destination nodes, such as when a source node and
destination node both belong to a common group of nodes.
Id. ¶ 13 (emphasis added). Moreover, the Specification explains:
Appeal 2019-001833
Application 15/013,452

9

In the absence of specified access policies and/or the ability to
determine that a particular initiated data transmission is
authorized, some embodiments may provide default access
policies and/or authorization polices, such as to deny all data
transmissions unless determined to be authorized, or instead to
allow all data transmissions unless determined to not be
authorized.
Id. ¶ 16 (emphasis added); see MICROSOFT COMPUTER DICTIONARY, 43 (5th
ed. 2002) (“authorization n. In reference to computing, especially remote
computers on a network, the right granted an individual to use the system
and the data stored on it. Authorization is typically set up by a system
administrator and verified by the computer based on some form of user
identification, such as a code number or password. Also called: access
privileges, permission.”). Thus, under its broadest reasonable interpretation,
we interpret the claim term “the dropped data communication” to include
any communication dropped or otherwise discarded due to a lack of
authorization. See id. ¶ 18.
As noted above, claim 2 recites determining that the dropped data
communication is a form of attack “by tracking a number of attempted data
communications from a source of the dropped data communication against
virtual machine nodes in a target class and comparing the number against a
threshold value.” Appeal Br. 16 (Claims App.). With respect to the claim
term “attempted data communications,” the Specification explains:
Additional responses to a detected network attack may
also be executed in various embodiments. Possible responses
include collecting information on the suspicious
communications, such as when, where, which, and how many
episodes or incidents have been attempted by the source of the
communications, changing access rights, spoofing replies to the
source, providing reports to an owner of the source and/or to
owner(s) of nodes that have been attacked, publish an identity of
Appeal 2019-001833
Application 15/013,452

10

the source to community blacklists accessible from external
network 170, and taking a counteraction against the source to
attempt to disable the source.
Spec. ¶ 54 (emphasis added); see id. ¶ 19. Thus, under its broadest
reasonable interpretation, we interpret the claim term “attempted data
communications” to include additional unauthorized communications, after
an initial dropped or otherwise discarded communication, from the same
source.
Narayanaswamy discloses, “a system administrator may specify a
compound network attack that includes the protocol anomaly of repeated
FTP login failure and a pattern that matches a login username of ‘root.’”
Narayanaswamy ¶ 36 (emphasis added); see Final Act. 11 (citing
Narayanaswamy, Figs. 2, 5, 6, ¶¶ 36, 46–47); Adv. Act. 2 (citing
Narayanaswamy ¶¶ 46–47); Ans. 4–5 (citing Narayanaswamy ¶¶ 36, 46–47).
Further, Narayanaswamy discloses that the number of such login failures,
e.g., connections, may be compared against a threshold in determining an
attack. Narayanaswamy ¶ 87 (“However, when either or both of the number
of connections and/or the rate at which connection requests are received
exceeds connections threshold 54 (‘YES’ branch of 102) for one of nodes 8,
such as node 8A, attack detection module 52 transitions to stage two of the
analysis. In general, attack detection module 52 transitions to stage two with
respect to each of nodes 8 for which attack detection module 52 determines
connections exceed connections threshold 54.”); see Final Act. 11 (citing
Narayanaswamy ¶¶ 86–90).
The Examiner finds that Narayanaswamy’s “FTP login failure”
teaches or suggests an unauthorized data communication, which is dropped
or otherwise discarded; and, because the Narayanaswamy discloses
Appeal 2019-001833
Application 15/013,452

11

monitoring repeated FTP login failures, the Examiner finds that that
Narayanaswamy counts these failed data communication attempts. See Final
Act. 11; Adv. Act. 2–3; Ans. 4–5. Further, the Examiner finds
Narayanaswamy discloses that these repeated, unauthorized, data
communication attempts may be compared to a threshold to determine an
attack, as recited in claim 2. See Final Act. 11. We agree.
Although Appellant correctly observes that Narayanaswamy discloses
dropping packet flows after an attack has been detected (see Appeal Br. 7–8;
Reply Br. 5–6), for the reasons given above, we do not understand the
Examiner to rely on such post detection responses to teach or suggest the
“dropped data communication” or the “attempted data communications,” as
recited in claim 2 and as interpreted above. Thus, the Examiner persuades
us Narayanaswamy teaches or suggests determining an attack from the
initial and repeated, unauthorized (i.e., dropped) data communications and
the comparison of their number to a threshold.
The Examiner asserts that Annamalaisami also teaches or suggests
detecting an attack based on dropped communications. Adv. Act. 3
(“Further – Examiner notes that second reference also teaches similar
limitation.”); see Ans. 5. Annamalaisami discloses, “[i]n still other
embodiments, the detector may determine that the packet 620 should be
refused based on previous unsuccessful attempts by the client 102 to
transmit data to a sever 106. In still other embodiments, the [denial of
service (DoS)] engine may determine to refuse the packet responsive to
referencing a tracking mechanism for previously dropped or flagged
clients.” Annamalaisami ¶ 260 (emphases added); see Adv. Act. 3. The
Examiner finds that
Appeal 2019-001833
Application 15/013,452

12

Annamalaisami teaches analysis of network attack as – detection
of packets which have been dropped by checking their status in
hash table by DOS engine and therefore the packets are refused
transmission in network. Where DOS engine is (denial of service
attack) engine, which examines dropped packets and refuses
transmission. This limitation further covers the claimed
limitation and argument by applicant that references do not teach
'dropped data communication as network attack.
Adv. Act. 3. The cited portions of Annamalaisami do not appear to teach or
suggest more that the Examiner finds already taught or suggested by
Narayanaswamy. Final Act. 12 (“Narayanaswamy does not teach however
Annamalaisami teaches, virtual machines”); see Ans. 3–9 (The Examiner
relies only on Narayanaswamy to teach or suggest the disputed limitation.).
Consequently, because we are persuaded that Narayanaswamy teaches or
suggests this limitation, we need not rely on Annamalaisami’s teachings
here.
Because we are persuaded the Examiner has shown that
Narayanaswamy and Annamalaisami together teach or suggest this disputed
limitation, we are not persuaded the Examiner erred in rejecting claim 2.
Consequently, we sustain the obviousness rejection of claim 2.
3. The Remaining Claims
As noted above, Appellant challenges the obviousness rejection of
independent claims 8 and 15 for substantially the same reasons as claim 2.
See Final Act. 13–15 (claim 8), 16–17 (claim 15); Appeal Br. 11–13. Each
of claims 3–7, 9–14, and 16–21 depends directly or indirectly from
independent claim 2, 8, or 15. Appeal Br. 16–22 (Claims App.). Because
we are not persuaded the Examiner erred with respect to the obviousness
rejection of claim 2, we also are not persuaded the Examiner erred with
Appeal 2019-001833
Application 15/013,452

13

respect to the obviousness rejections of independent claims 8 and 15 and of
dependent claims 3–7, 9–14, and 16–21, given that these claims also include
the disputed limitations. For this reason, we sustain the obviousness
rejections of those claims.
DECISIONS
1. The Examiner did not err in rejecting claims 2–21 under the
judicially-created doctrine of obviousness-type double patenting in
view of claims 1–20 of Rubin ’348 and in view of claims 1–18 of
Rubin ’319.
2. The Examiner did not err in rejecting claims 2, 3, 7, 8, 10–12, and 14–
19 under 35 U.S.C. § 103 as rendered obvious over the combined
teachings of Narayanaswamy and Annamalaisami.
3. The Examiner did not err in rejecting claims 4, 5, 13, 20, and 21 under
35 U.S.C. § 103 as rendered obvious over the combined teachings of
Narayanaswamy, Annamalaisami, and Xiao
4. The Examiner did not err in rejecting claims 6 and 9 under 35 U.S.C.
§ 103 as rendered obvious over the combined teachings of
Narayanaswamy, Annamalaisami, and Weis.
5. Thus, on this record, claims 2–21 are unpatentable.
CONCLUSION
We affirm the Examiner’s decision rejecting claims 2–21.

Appeal 2019-001833
Application 15/013,452

14

In summary:
Claims
Rejected
35 U.S.C. § Basis/References Affirmed Reversed
2–21 Obviousness-type
double patenting
2–21
2, 3, 7, 8,
10–12,
14–19
103 Narayanaswamy,
Annamalaisami
2, 3, 7, 8,
10–12,
14–19

4, 5, 13, 20,
21
103 Narayanaswamy,
Annamalaisami,
Xiao
4, 5, 13,
20, 21

6, 9 103 Narayanaswamy,
Annamalaisami,
Weis
6, 9
Overall
Outcome
2–21
No time period for taking any subsequent action in connection with
this appeal may be extended under 37 C.F.R. § 1.136(a). See 37 C.F.R.
§ 1.136(a)(1)(iv).
AFFIRMED