International Business Machines Corporation

Patent Trials and Appeals Board

May 17, 2021

2019005591 (P.T.A.B. May. 17, 2021)

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/359,088 11/22/2016 Mark McGloin AUS920140070US3 1381
63608 7590 05/17/2021
David H. Judson
Law Office of David H. Judson
7244 N. Janmar Drive
Dallas, TX 75230
EXAMINER
ANDERSON, MICHAEL D
ART UNIT PAPER NUMBER
2432
NOTIFICATION DATE DELIVERY MODE
05/17/2021 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):
mail@davidjudson.com
PTOL-90A (Rev. 04/07)
UNITED STATES PATENT AND TRADEMARK OFFICE
BEFORE THE PATENT TRIAL AND APPEAL BOARD
Ex parte MARK MCGLOIN, JOHN DOUGLAS CURTIS,
PETER OTTO MIERSWA, RUSSELL L. HOLDEN, and
OLGIERD STANISLAW PIECZUL
Appeal 2019-005591
Application 15/359,088
Technology Center 2400
Before MAHSHID D. SAADAT, ALLEN R. MacDONALD, and
NABEEL U. KHAN, Administrative Patent Judges.
MacDONALD, Administrative Patent Judge.
DECISION ON APPEAL
STATEMENT OF THE CASE
Pursuant to 35 U.S.C. § 134(a), Appellant1 appeals from the
Examiner’s decision to reject claims 1–18. We have jurisdiction under
35 U.S.C. § 6(b).
We affirm.

1 We use the word Appellant to refer to “applicant” as defined in 37 C.F.R.
§ 1.42(a). Appellant identifies the real party in interest as International
Business Machines Corporation. Appeal Br. 1.
Appeal 2019-005591
Application 15/359,088
2
CLAIMED SUBJECT MATTER
Claim 1 is illustrative of the claimed subject matter (emphasis,
formatting, and bracketed material added):
1. A method of minimizing application-level denial-of-service
attacks with respect to compute resources in a multi-
tenant shared infrastructure, the method comprising:
[A]. profiling anticipated application behavior in
response to one or more requests to generate an
application profile having at least one workload
constraint, the application profile including a
mapping of a request type to a workload and a
workload limit;
[B]. upon receipt of a request, and prior to execution,
determining whether execution of the request
satisfies the at least one workload constraint in
the application profile by evaluating whether the
request is predicted to result in a workload that
exceeds the workload limit;
[C]. responsive to determining whether execution of the
request satisfies the at least one workload
constraint in the application profile, taking a given
action;
[D]. wherein the steps are carried out in software
executing in a hardware element.
REFERENCES
The Examiner relies on the following prior art:
Name Reference Date
Liu US 8,504,504 B2 Aug. 6, 2013

REJECTION
The Examiner rejects claims 1–18 under 35 U.S.C. § 102(a)(1) as
being anticipated by Liu. Final Act. 4.
Appeal 2019-005591
Application 15/359,088
3
Appellant does not separately argue claims 2 and 7–18, and instead
relies upon its argument regarding claims 1 and 3–6. See Appeal Br. 4.
Except for our ultimate decision, we do not discuss the §102(a)(1) rejection
of claims 2 and 7–18 further herein.
OPINION
We have reviewed the Examiner’s rejection in light of Appellant’s
Appeal Brief and Reply Brief arguments.
A. Claim 1
Liu discloses a system and method for discovery and classification of
denial of service attacks in a distributed computing system, where local
agents are employed on nodes to detect resource-related events. See Liu at
Abstract. The Examiner found that Liu teaches all of the elements of claim
1. See Final Act. 4–5.
1. First Argument
Appellant raises the following argument in contending the Examiner
erred in rejecting claim 1 under 35 U.S.C. § 102(a) (1).
[T]he notion of actually “profiling anticipated application
behavior” is absent from the Liu teaching . . . as the approach
there just assumes the existence of a “knowledge base” with
relevant (to Liu) information. . . . Even if one concedes that the
Liu knowledge base includes an “application profile” generally,
the claim element is more specific in that it requires “profiling”
of “anticipated application behavior in response to one or more
requests.” Thus, the claim element here describes explicitly how
the application profile is generated, whereas Liu just assumes the
existence of “membership functions.” The teaching does not
provide that any such membership function is generated “in
response to one or more requests” and certainly not based on a
“mapping of a request type to a workload and a workload limit”
as also positively recited. ... Liu’s “knowledge base” is neither
explicitly nor necessarily based on “profiling anticipated
Appeal 2019-005591
Application 15/359,088
4
application behavior” and does not provide for a profile that
includes “a mapping of a request type to a workload and a
workload limit.”
Appeal Br. 9–10 (emphasis added).
In the Examiner’s Answer, the Examiner further found:
In order to profile the anticipated application behavior as argued,
the system must comprise some data base or source to compare
the application behavior. [Liu teaches] in Col. 9/lines 12-17 that
an adaptive flood control mechanism may be invoked (e.g., by
sending messages other nodes) in order to prevent an attack
from propagating to neighboring nodes, according to an attack
tree for the distributed system and/or individual nodes thereof.
In other words, the system goes [through] each node looking for
an anticipated application behavior. Fig. 1 explicitly illustrates
this process.
Ans. 5–6 (emphasis added).
Responding to the findings in the Examiner’s Answer, Appellant
further argues:
The claim element here is an active one, namely, “profiling
anticipated application behavior.” Liu’s “knowledge base” may
be the result of some activity, but Liu itself does not explain
what that activity is. In the rebuttal, the Examiner now references
FIG. 1 (which is reproduced in the Answer), as well as the text
in Liu Column 9, lines 12-17 concerning an “adaptive flood
control mechanism” that Liu may invoke to prevent an attack
from propagating to neighborhood nodes ... (See, Answer, at
pages 5-6). The relevance of this citation (to the claim phase
“profiling anticipated application behavior”) is not particularly
clear, as the claim element “profiling anticipated … ” refers to
something happening in advance of a denial-of-service attack,
not the actual response to the attack itself.
Reply Br. 2 (emphasis added).
We are unpersuaded by Appellant’s argument. As the Examiner
found, Liu discloses a method for performing identification and prevention
of distributed denial of service attacks, where an initial attack tree and/or
Appeal 2019-005591
Application 15/359,088
5
overlay network is generated depending on predicted, current, or historical
system configuration, on simulation data, or on training data, where the
attack tree is a model of progression or likely progression of an attack from
one node to another in the distributed system. See Ans. 5–6; see also Liu
2:54–59, 8:13–21. As the attack tree models the progressive behavior of a
resource-related event, Liu’s generation of an attack tree teaches “profiling
anticipated application behavior.” Liu further teaches a knowledge base that
is consulted to determine if a resource-related event matches a known attack
pattern. See Liu 8:34–37. As the knowledge base also models the
anticipated behavior of the resource-related event, Liu’s generation of a
knowledge base also teaches “profiling anticipated application behavior.”
Liu additionally teaches updating the knowledge base in response to a
request to update the knowledge base (i.e., feedback on the accuracy of an
attack classification of the knowledge base). See Liu 11:35–12:4.
Therefore, Liu’s generating and updating an attack tree and a knowledge
base teaches the claimed “profiling anticipated application behavior in
response to one or more requests to generate an application profile having at
least one workload constraint.”
2. Second Argument
Appellant also raises the following argument in contending the
Examiner erred in rejecting claim 1.
[W]hile Liu does provide generating an event message when a
workload limit is reached (FIG. 3, steps 420 and 430), this does
not teach or require an “application profile” that includes a
“mapping of a request type” to a workload, let alone a “request
type” to both a “workload and a workload limit.” Indeed, steps
410 and 420 as depicted in described make no distinction(s)
concerning the type of request being made.
Appeal Br. 11 (emphasis added).
Appeal 2019-005591
Application 15/359,088
6
In response to Appellant’s argument, the Examiner further found:
Liu . . . teaches this limitation in Col. 19 which states “FIG. 8
illustrates a method for modifying attack trees and/or overlay
networks, according to one such embodiment. In this example,
an attack tree and/or overlay network may be
constructed/mapped for a given distributed system . . . as in 800.
For example, an initial attack tree and/or overlay network may
be constructed based on . . . a known or assumed workload . . . .
At some point, the system may receive feedback indicating a
change in . . . the workload . . . as in 810. For example, event
driven messages received from data collection agents, or
messages received in response to an attack class discovery probe
may indicate that . . . the workload has increased or decreased,
. . . . In response to this feedback, the system may be configured
to automatically modify the attack tree and/or overlay network
for the system, dependent on the change, as in 820. In some
embodiments, reinforcement learning techniques may be applied
to the building and updating of attack trees and/or the overlay
networks used in attack discovery and/or flood control. For
example, when the value of a state of one of the nodes of the
system changes, a state action value mapping tor the system may
indicate that a change should be made to the attack tree and/or
overlay network.”
Ans. 6–7 (emphasis in original).
In response, Appellant further argues:
[T]he Examiner’s new reliance on FIG. 8 and the associated text
fares no better than the original findings. As noted, the claim
element refers specifically to “mapping of a request type to
[both] a workload and a workload limit.” The text in FIG. 8
refers only to a “workload” and the notion of some “mapping”
for the system based on receiving feedback regarding a change
in that workload. But partial nomenclature overlaps (such as the
Examiner is now newly-relying upon) do not establish
anticipation, which requires an exact correspondence between
the claim element and the explicit or necessarily-present subject
matter. An attack tree is not a “workload limit” and neither is
an “overlay network.” The notion of “request type” or its
Appeal 2019-005591
Application 15/359,088
7
mapping to a workload and a workload limit is nowhere found
in this text[.]
Reply Br. 4 (emphasis added).
We are unpersuaded by this argument as well. As the Examiner
found, Liu discloses a method for modifying attack trees and/or overlay
networks, where an initial attack tree is constructed based on a known,
expected, or assumed system configuration, a known or assumed workload,
or simulation or training data. See Ans. 6; see also Liu 19:1–11. Liu further
discloses the system received feedback indicating a change in the system
configuration, the workload, and/or the state of one or more nodes in the
system, where the change in workload indicates that the workload has
increased or decreased, and automatically modifying the attack tree and/or
overlay network for the system, and where a state-action value mapping for
the system indicates a change should be made to the attack tree and/or
overlay network. See Ans. 6–7; see also Liu 19:11–29. As further disclosed
in Liu, detecting a change in workload involves indicating that a threshold
value of the workload is reached or that a threshold rate of change has been
reached. See Liu 12:36–42. The state-action value mapping of the attack
tree and/or overlay network teaches the claimed “mapping of a request type
to a workload and a workload limit.”
Additionally, Liu discloses a knowledge base that is utilized to
determine if observed behavior within the system matches a known attack
pattern, where the knowledge base includes attack patterns based on several
kernel parameters (e.g., CPU utilization, disk utilization, memory utilization,
I/O resource utilization, I/O ratio, network packet ratio, state packet ratio, or
some other parameter). See Liu 7:9–28. Liu also discloses an example
utilization of a knowledge base involving a standard profile based on an
Appeal 2019-005591
Application 15/359,088
8
expected transaction load of a banking application. See Liu 12:56–13:17.
Liu’s attack pattern which includes a mapping an application to an expected
transaction load, or other expected kernel parameter, also teaches the
claimed “mapping of a request type to a workload and a workload limit.” In
light of the above, Liu’s attack tree and knowledge base teach “the
application profile including a mapping of a request type to a workload and a
workload limit.”
3. Third Argument
Appellant additionally raises the following argument in contending
the Examiner erred in rejecting claim 1.
[T]he “probability determination” (step 320 in FIG. 3) is a
determination regarding whether an attack is in progress and/or
is imminent (C10L65-66). While this computation may be based
on weighted parameter values (e.g., CPU usage, I/O usage,
memory usage, resource trends) or workload values (C11L1-5),
the claim element is referring to something else, namely,
“whether execution of the request ... is predicted to result in a
workload that exceeds the workload limit.” This is not an attack
prediction; rather, the earlier portion of the claim references that
the profile includes the request type, workload and workload
limit, and this “determining” portion analyzes those constraints.
Liu teaches looking at a workload profile but only after the
information layer has received the event message and is seeking
to evaluate whether an attack is underway. The claim element of
making a [prediction] whether “the request” execution will
“result in a workload that exceeds the workload limit” is not
described.
Appeal Br. 11–12 (emphasis added).
In response to Appellant’s argument, the Examiner further found:
Col. 19 [states]:
For example, event driven messages received from
data collection agents, or messages received in
response to an attack class discovery probe may
Appeal 2019-005591
Application 15/359,088
9
indicate that . . . the workload has increased or
decreased . . .. In response to this feedback, the
system may be configured to automatically modify
the attack tree and/or overlay network for the
system, dependent on the change, as in 820. In
some embodiments, reinforcement learning
techniques may be applied to the building and
updating of attack trees and/or the overlay
networks used in attack discovery and/or flood
control. For example, when the value of a state of
one of the nodes of the system changes, a state
action value mapping for the system may indicate
that a change should be made to the attack tree
and/or overlay network[.]
This section of Liu clearly tells us that the probability
determination does indeed determine whether the attack is in
progress or imminent ([Fig.8/item 810 – Fig.8/item 820]). Liu’s
system responds by making a change if it sees a change or state
of one of the nodes of the system changes which is clearly
profiling anticipation behavior.
Ans. 8 (emphasis in original).
In response, Appellant further argues:
[T]he new argument also fails, because reinforcement learning
per se does not necessarily require determining “whether
execution of the request ... is predicted to result in a workload
that exceeds the workload limit.” Rather, the notion of
reinforcement as described refers to building/updating attack
trees/overlay networks based on what actually happened
previously when the Liu system fought off an actual attack. This
is not a predictive type solution, but rather one in which real
attack mitigation data is used for the purported after-the-fact
learning.
Reply Br. 4–5 (emphasis added).
This argument is not persuasive either. As the Examiner found, Liu
discloses receiving feedback indicating a change in system configuration,
workload, and/or state of nodes, and automatically modifying the attack tree
Appeal 2019-005591
Application 15/359,088
10
and/or overlay network for the system in response to the feedback. See
Ans. 8; see also Liu 19:10–29. Liu further discloses monitoring a workload
and either determining if a threshold value or threshold rate of change is
detected. See Liu 12:36–39. Liu additionally discloses simulating actions
that produce changes in system configuration, workload, and/or state of
nodes. See Liu 5:32–38, 26:15–18, 29:19–22. By simulating an action that
produces a change in workload, Liu’s system predicts whether the action
results in a workload that exceeds a workload limit. Thus, Liu’s
determination of change in system workload based on threshold or threshold
rate involving a simulation of the change in system workload teaches the
claimed “evaluating whether the request is predicted to result in a workload
that exceeds the workload limit.”
4. Fourth Argument
Appellant further argues Liu’s distributed computing system is not
identified for use “in a multi-tenant shared infrastructure,” as claim 1
explicitly requires. Appeal Br. 8. In its Reply Brief, Appellant indicates that
“Applicant hereby withdraws this argument.” Reply Br. 1. In light of
Appellant’s withdrawal of this argument, we do not reach the merits of this
argument. However, assuming arguendo that Appellant did not withdraw
this argument, this argument would not be persuasive because the phrase “in
a multi-tenant shared infrastructure,” recited in claim 1, is a statement of the
intended use of the recited method. A statement of intended use cannot
distinguish over the teachings of the applied reference, which teaches all of
the recited limitations and is capable of performing the recited function. See
In re Schreiber, 128 F.3d 1473, 1477 (Fed. Cir. 1997). We note that “[a]n
intended use or purpose usually will not limit the scope of the claim because
such statements usually do no more than define a context in which the
Appeal 2019-005591
Application 15/359,088
11
invention operates.” Boehringer Ingelheim Vetmedica, Inc. v. Schering-
Plough Corp., 320 F.3d 1339, 1345 (Fed. Cir. 2003).
5. Fifth Argument
Appellant also argues the Examiner presents several arguments in the
Examiner’s Answer that were not previously presented in the Final Office
Action. See Reply Br. 2–5. Essentially, Appellant is arguing that the
Examiner’s arguments in the Examiner’s Answer constitute a new ground of
rejection. We refuse to designate the arguments in the Examiner’s Answer
as a new ground of rejection because the arguments did not change the basic
thrust of the rejection. See In re Kronig, 539 F.2d 1300, 1303 (CCPA 1976);
see also In re Jung, 637 F.3d 1356, 1364-65 (holding that additional
explanation responding to arguments offered for the first time “did not
change the rejection, and [A]ppellant had fair opportunity to respond”).
Further, the failure to designate a rejection as a new ground of rejection is a
petitionable issue, rather than an appealable issue, and Appellant has failed
to petition that the rejection be designated a new ground of rejection. See
MPEP § 1207.03(b) (“37 CFR 41.40 sets forth the exclusive procedure for
an appellant to request review of the primary examiner’s failure to designate
a rejection as a new ground of rejection via a petition to the Director under
37 CFR 1.181,” emphasis added).
B. Claim 3
Claim 3 recites, inter alia, “allocat[ing] processing or storage in the
multi-tenant shared infrastructure to simulate how execution of the request
affects availability of the compute resources.” In contending the Examiner
erred in rejecting claim 3, Appellant argues:
[T]he subject matter in claims 3, 9 and 15 concerning allocating
“processing or storage ... to simulate how execution affects
Appeal 2019-005591
Application 15/359,088
12
availability of the compute resources”) is not an active
monitoring operation, which is the function of the Liu data
collection agent (that “monitors state, resource usage and
workload”). . . .Liu’s agent 410 is actively monitoring and
providing event messages to the information layer. There is
nothing being simulated by the agent, let alone by allocating
“processing or storage ... to simulate” to facilitate a
determination of what could happen. Liu’s agent 410 is operating
in real-time as an activity monitor and event message generator
to inform other components of that system.
Appeal Br. 13 (emphasis added).
This argument is not persuasive either. As previously described, Liu
teaches simulating the execution of a request to determine an effect on the
availability of computer resources. See Liu 5:32–38, 12:29–39, 19:10–29,
26:15–18, 29:19–22. Liu further teaches re-allocating memory or other
resources in response to different attack patterns. See Liu 7:31–33. Thus,
we agree with the Examiner that Liu teaches the aforementioned limitation
of claim 3.
C. Claim 4
Claim 4 recites, inter alia, “wherein the anticipated application
behavior characterizes legitimate behavior for each of one or more tenant
applications in the multi-tenant shared infrastructure.” In contending the
Examiner erred in rejecting claim 4, Appellant argues:
[T]he data collection agent 410 operates in real-time as an
activity monitor. No explicit “application behavior” is being
profiled in advance, let alone “anticipated application
behavior.” It follows that because neither the agent 410 nor any
other Liu component is generating a profile “prior to execution,”
the application behavior that is captured by the agent is simply
what the agent sees, and there is no characterization one way or
the other otherwise disclosed or suggested.
Appeal Br. 13 (emphasis added).
Appeal 2019-005591
Application 15/359,088
13
This argument is also unpersuasive. As previously described, Liu
teaches a standard profile based on an expected transaction load of a banking
application. See Liu 12:56–13:17. The standard profile is an example of
application behavior characterized as legitimate behavior for an application.
Thus, we agree with the Examiner that Liu teaches the aforementioned
limitation of claim 4.
D. Claim 5
Claim 5 recites, inter alia, “wherein the anticipated application
behavior is profiled as a machine-encoded data set.” In contending the
Examiner erred in rejecting claim 5, Appellant argues:
Liu does not generate a profile of “anticipated application
behavior” “prior to execution” as required by the parent claim.
Further, the notion of “encoding” is not provided by the mere
fact of Liu’s “probability determination,” which simply
analyzes parameters and workflow data. Whether that data is or
is not “machine-encoded” is not also provided for in the explicit
or inherent teachings.
Appeal Br. 14 (emphasis added).
This argument is also not persuasive of Examiner error. Liu teaches
that the repository of known attack patterns is stored as data representing
known attack patterns. See Liu at 7:9–19. Liu’s stored data representing the
known attack patterns teaches the claimed “anticipated application behavior
. . . profiled as a machine-encoded data set.” Thus, we agree with the
Examiner that Liu teaches the aforementioned limitation of claim 5.
E. Claim 6
Claim 6 recites, inter alia, “wherein the determining step executes a
number of application operations in a separate execution thread to determine
if the number of application operations in the workload exceeds the
Appeal 2019-005591
Application 15/359,088
14
workload limit.” In contending the Examiner erred in rejecting claim 6,
Appellant argues:
The notion of the “determining step [executing] a number of
application operations in a separate execution thread to
determine if the number of application operations in the
workload exceeds the workload limit” is not provided by Liu’s
probability determination. How the probability determination is
carried out is not described, and whether or not a “separate
execution thread” is used is not explained in the teaching.
Appeal Br. 14 (emphasis added).
This argument is not persuasive. Liu discloses monitoring a state of
process/thread executing. See Liu 12:20–23. Liu further discloses data
collection agents executable on separate computer nodes and information
layer agents executable on separate master nodes. See Liu 9:52–10:8. The
aforementioned disclosures teach the claimed “execut[ing] a number of
application operations in a separate execution thread.” Thus, we agree with
the Examiner that Liu teaches the aforementioned limitation of claim 6.
CONCLUSION
The Examiner has not erred in rejecting claims 1–18 as being
anticipated under 35 U.S.C. § 102(a)(1).
The Examiner’s rejection of claims 1–18 as being unpatentable under
anticipated under 35 U.S.C. § 102(a)(1) is affirmed.
DECISION SUMMARY
In summary:
Claims
Rejected
35 U.S.C.
§
Reference(s)/Basis Affirmed Reversed
1–18 102(a)(1) Liu 1–18

Appeal 2019-005591
Application 15/359,088
15
TIME PERIOD FOR RESPONSE
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