Twitter, Inc.

Patent Trials and Appeals Board

Oct 4, 2021

2021005026 (P.T.A.B. Oct. 4, 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/675,319 08/11/2017 Wendy Ran Wei 0124-057001 5156
135246 7590 10/04/2021
BRAKE HUGHES BELLERMANN LLP
P.O. Box 1077
Middletown, MD 21769
EXAMINER
WHEATON, BRADFORD F
ART UNIT PAPER NUMBER
2193
NOTIFICATION DATE DELIVERY MODE
10/04/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):
docketing@brakehughes.com
uspto@brakehughes.com
PTOL-90A (Rev. 04/07)
UNITED STATES PATENT AND TRADEMARK OFFICE
BEFORE THE PATENT TRIAL AND APPEAL BOARD
Ex parte WENDY RAN WEI and SIWEI SHEN
Appeal 2021-005026
Application 15/675,319
Technology Center 2100
Before JEAN R. HOMERE, PHILLIP A. BENNETT, and
SCOTT RAEVSKY, Administrative Patent Judges.
BENNETT, 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–20. Non-Final Act. 1. We have
jurisdiction under 35 U.S.C. § 6(b).
We affirm in part.

1 “Appellant” refers to “applicant” as defined in 37 C.F.R. § 1.42(a).
Appellant identifies the real party in interest as Twitter, Inc. Appeal Br. 2.
Appeal 2021-005026
Application 15/675,319

2
CLAIMED SUBJECT MATTER
The claims are directed to using an API call sequence recorded on a
frontend component device to ascertain whether an account creation request
in a social media platform is anomalous. Spec. Abstract. Claim 1,
reproduced below, is illustrative of the claimed subject matter:
1. A method comprising:
receiving, in a computer system, an account creation
request for a social media platform, the account creation request
created and sent to the computer system using a frontend
component;
receiving, from the frontend component, an application
programming interface (API) call sequence associated with the
account creation request, the API call sequence made to an API
of the frontend component and reflecting API calls registered by
the frontend component in connection with creation of the
account creation request, and timings of the registered API calls;
applying an API call sequence model to the received API
call sequence, the API call sequence model generated by
providing training API call sequences to a machine learning
component; and
in response to the application of the API call sequence
model indicating that the received API call sequence is
anomalous, taking at least one action with regard to the account
creation request, or with regard to an account created in response
to the account creation request.
Appeal Br. 17 (Claims Appendix).
REFERENCES2
The Examiner cites the following references:

2 Citations herein to the references are to the first named inventor only.
Appeal 2021-005026
Application 15/675,319

3
Name Reference Date
Basso US 2004/0179522 A1 Sept. 16, 2004
Reno US 2015/0350174 A1 Dec. 3, 2015
Douglas US 2016-0314458 A1 Oct. 27, 2016
Khan US 2016/0342453 A1 Nov. 24, 2016
Daniel US 2017/0026318 A1 Jan. 26, 2017
Banerjee US 2017/0039196 A1 Feb. 9, 2017
Pidathala US 9,690,874 B1 June 27, 2019
REJECTIONS
Claims 1, 5–11, 14, and 16–203 stand rejected under 35 U.S.C. § 103
as being unpatentable over Reno, Banerjee, and Pidathala. Non-Final
Act. 3–13.
Claims 2–4 stand rejected under 35 U.S.C. § 103 as being
unpatentable over Reno, Banerjee, Pidathala, and Khan. Non-Final Act. 13–
15.
Claim 12 stands rejected under 35 U.S.C. § 103 as being unpatentable
over Reno, Banerjee, Pidathala, and Basso. Non-Final Act. 15–16.
Claim 13 stands rejected under 35 U.S.C. § 103 as being unpatentable
over Reno, Banerjee, Pidathala, and Douglas. Non-Final Act. 16–17.
Claim 15 stands rejected under 35 U.S.C. § 103 as being unpatentable
over Reno, Banerjee, Pidathala, and Daniel. Non-Final Act. 17–18.
ISSUES
First Issue: Has the Examiner erred in finding the Reno, Banerjee,
and Pidathala combination teaches or suggests “receiving . . . an application

3 The non-final Office Action includes claim 15 in the statement of rejection.
However, claim 15 is not addressed under this rejection, and instead is
substantively addressed under a separate rejection heading.
Appeal 2021-005026
Application 15/675,319

4
programming interface (API) call sequence associated with the account
creation request, the API call sequence made to an API of the frontend
component and reflecting API calls registered by the frontend component in
connection with the creation of the account creation request,” as recited in
claim 1?
Second Issue: Has the Examiner erred in combining the teachings of
Reno and Banerjee?
Third Issue: Has the Examiner erred in finding Khan teaches or
suggests “wherein applying the API call sequence model comprises an
evaluation of whether the received API call sequence is missing a particular
API call of the frontend component,” as recited in claim 2?
Fourth Issue: Has the Examiner erred in finding Reno teaches or
suggests “some of the training API call sequences correspond to valid
account creation requests and others of the training API call sequences
correspond to invalid account creation requests,” and that “the particular API
call is identified for use in the evaluation based on the particular API call
having a greater frequency of occurrence for the valid account creation
requests than for the invalid account creation requests,” as recited in
claim 3?
Fifth Issue: Has the Examiner erred in finding Khan teaches or
suggests “in response to determining that the received API call sequence is
missing the particular API call of the frontend component, evaluating
whether the received API call sequence is missing a neither particular API
call of the frontend component,” as recited in claim 4?
Sixth Issue: Has the Examiner erred in finding Reno teaches or
suggests “wherein evaluating the timing of the API calls comprises
Appeal 2021-005026
Application 15/675,319

5
determining whether a temporal separation of the API calls is randomized,”
as recited in claim 7?
Seventh Issue: Has the Examiner erred in finding Basso teaches or
suggests “the connection between the API calls and the creation of the
account creation request comprises that at least one of the API calls was
registered by the frontend component during a predefined period of time
after the account generation request was generated,” as recited in claim 12?
Eighth Issue: Has the Examiner erred in finding Daniel teaches or
suggests “applying the updated API call sequence model to a previous
account creation request, including at least the received account creation
requests,” as recited in claim 15?
ANALYSIS
First Issue
The Examiner rejects claim 1 as obvious over Reno, Banerjee, and
Pidathala. Non-Final Act. 4–7. The Examiner finds Reno teaches most
limitations of the claims, but does not teach the first “receiving” step of
claim 1 in its entirety. Non-Final Act. 5. The Examiner relies on Banerjee
and Pidathala to address this deficiency. Non-Final Act. 6–7. Specifically,
the Examiner finds Banerjee teaches receiving a request sent using a
frontend component (Non-Final Act. 6), and that Pidathala teaches account
creation requests in a social media platform (Non-Final Act. 7).
Appellant contends the Examiner has erred because the cited
references do not teach or suggest “that a frontend component should
forward an ‘API call sequence’ with an account creation request.” Appeal
Br. 6. Appellant asserts that the claims require that “the frontend component
in the present subject matter provides both the ‘account creation request’ and
Appeal 2021-005026
Application 15/675,319

6
the ‘API call sequence’ to the computer system, [with] the API call sequence
‘reflecting API calls registered by the frontend component in connection
with creation of the account creation request, and timings of the registered
API calls.’” Appeal Br. 6.
Because the claim requires both an account creation request and a
separate API call sequence, Appellant urges that neither “Reno nor Banerjee
discloses forwarding of an API call sequence according to the present
subject matter.” Appeal Br. 8. With respect to Reno, Appellant argues
“Reno’s API transaction requests are not ‘made to’ Reno’s API client
nodes . . . , and they are also not ‘registered by’ Reno’s API client nodes.”
Appeal Br. 8. Instead, according to Appellant, Reno’s “API transaction
requests are what the API client nodes . . . seek to send to the application
servers” and the “API client nodes are not forwarding any API call
sequences made to them or that they may have received.” Appeal Br. 8.
Appellant further asserts that Banerjee is deficient because it merely
describes the receipt of data at a frontend application that is sent to a server
for processing. Appeal Br. 8. Appellant argues that “the Examiner’s
position that the data forwarded by Banerjee’s frontend application system
125 includes API call sequences received by the frontend application system
amounts to nothing but guesswork.” Reply Br. 3. According to Appellant,
“[i]nstead of pointing to where Banerjee allegedly teaches the subject matter
at issue, the Examiner merely speculates that Banerjee’s data ‘can include’
such received API call sequences.” Reply Br. 3.
We are not persuaded the Examiner has erred.
We begin with claim interpretation. “[T]he PTO gives a disputed
claim term its broadest reasonable interpretation.” In re Bigio, 381 F.3d
Appeal 2021-005026
Application 15/675,319

7
1320, 1324 (Fed. Cir. 2004). Appellant’s claim 1 recites that a method in
which a computer system receives an account creation request for a social
media platform from a frontend component, and also receives an API call
sequence associated with the account creation request. The Specification
describes that the frontend component may be “a software application (e.g.,
an ‘app’) that is being executed on a smartphone.” Spec. ¶ 28. The
Specification further describes that “[t]he frontend component 106 can be
designed to have a number of application programming interfaces (APIs).
The APIs can relate to any or all interactions that a user can have with
frontend component 106.” Spec. ¶ 34. The Specification further explains
that “the invocation of an API can be referred to as an API call, and two or
more such API calls that take place on a particular user device—that is, are
registered by the same frontend component—can be referred to as an API
call sequence.” Spec. ¶ 34 (reference number omitted). In light of this
description in the Specification, we conclude that the phrase “frontend
component” encompasses any application running on a computer system.
We further conclude the phrase “API call sequence” encompasses two or
more API calls made to or by a specific application. With those
interpretations in mind, we consider the Examiner’s rejection.
Reno relates to “API risk assessment” in which “[a] risk assessment
score is generated based on comparison of content of [an] API transaction
request to content of earlier API transaction requests” which “indicates
trustworthiness of the API transaction request.” Reno Abstract. Reno
teaches that “[d]eliverability of the API transaction request to a destination
node for processing is controlled based on the risk assessment score.” Reno
¶ 3. The Examiner finds that Reno teaches “receiving an application
Appeal 2021-005026
Application 15/675,319

8
programming interface (API) call sequence request, the API call sequence
request reflecting API calls registered by a component in connection with
the request, and timings of registered API calls.” Non-Final Act. 5 (citing
Reno ¶¶ 19, 47). We discern no error in these findings.
As we noted above, in light of the Specification, the phrase “API call
sequence” is broadly, but reasonably, interpreted as meaning “two or more
API calls.” Reno teaches that the “API risk assessment equipment receives
API transaction requests (e.g., Web service API calls, RESTful API
transactions, etc.) through one or more data networks from applications
processed by one or more API client nodes.” Reno ¶ 19 (reference numeral
omitted). Thus, Reno teaches receiving multiple API calls (i.e., an API call
sequence), and because those received API calls (the API call sequence) are
“from applications processed by one or more API client nodes” (Reno ¶ 19),
the API call sequence reflects API calls registered by a component in
connection with the request. Reno further teaches that when communicating
API transaction information for evaluation, either “the entire API transaction
request or information characterizing the API transaction” may be
communicated for evaluation. Reno ¶ 27.
Reno further teaches that in generating a risk assessment score for the
API requests, a request “followed by another request within a threshold
elapsed time” may be indicative of a fraudulent API request. Reno ¶ 47.
This capability of Reno indicates that “timings of registered API calls” are
received by the API risk assessment equipment.
Appellant argues the API calls described in Reno are not API call
sequences because they are not “made to an API of the frontend component”
and they do not “reflect API calls registered by the frontend component.”
Appeal 2021-005026
Application 15/675,319

9
Appeal Br. 8. We do not find this argument persuasive for two reasons.
First, as we noted above, Reno teaches that the system may send
“information characterizing the API transaction.” Information
characterizing the API transaction “reflects” the API calls made and
registered by Reno’s client nodes. Second, the Examiner does not rely
exclusively on Reno as teaching these aspects of the claim. Instead, the
Examiner finds that Reno does not specifically teach that the API call
sequence is received “from the frontend component,” nor does it specifically
teach that the API call sequence is “made to an API of the frontend
component.” The Examiner cites Banerjee in this regard. Specifically, the
Examiner finds that Banerjee’s description of data transmission and
interaction between a frontend application system and a server teaches an
API call sequence “made to an API of the frontend component” and received
“from the frontend component.” Non-Final Act. 6 (ciring Banerjee ¶¶ 18,
19). Banerjee describes the use of a frontend application system in a larger
client/server environment. See Banerjee ¶ 18; Figure 1. Banerjee teaches
that the frontend applications system is “capable of integrating the various
systems and products interacting with the frontend application system.”
Banerjee ¶ 18 (reference numbers omitted). Banerjee further teaches that the
interactions between the frontend application system and other systems
“may be in the form of internal application programming interface (API)
calls.” Banerjee ¶ 19.
Appellant argues that “a person of ordinary skill in the art would not
consider the data sent in Banerjee to be an ‘API call sequence’ according to
the present subject matter.” Appeal Br. 8. We disagree. As noted above,
“API call sequence” is properly understood to mean two or more API calls,
Appeal 2021-005026
Application 15/675,319

10
which, as we noted above, is taught by Reno’s API transaction requests.
The Examiner relies on Banerjee to show that it was known in the art for
frontend applications to communicate via API calls. That is, Banerjee
demonstrates that it was known in the prior art for API calls to be made to a
frontend application and registered by that frontend application for the
purpose of communicating those API calls to other systems.
As noted above, the Examiner finds that the combined teachings of
Reno and Banerjee do “not specifically disclose that the request is associated
with an account creation request for a social media platform,” and cites
Pidathala as teaching “API calls associated with creating accounts for social
media platforms.” Non-Final Act. 7 (citing Pidathala col. 7, ll. 51–59). We
agree with the Examiner that Pidathala’s teachings, in combination with
those of Reno and Banerjee, are sufficient to demonstrate obviousness of the
argued limitation. Pidathala relates to “a social platform for developing
informed local communities.” Pidathala col. 1, ll. 13–15. Pidathala
describes that users can sign up for its social platform using API calls from
other social media sites. Pidathala col. 7, ll. 51–63. Appellant argues that
“Pidathala does not teach or suggest ‘an account creation request for a social
media platform’” because “Pidathala does not state that the system 100
mentioned is a social media platform.” Appeal Br. 11. We disagree because
Pidathala teaches that “the present invention provides a social platform for
developing informed communities.” Pidathala Abstract. Pidathala further
teaches that “the present invention can be embodied in an informed
communities system 100.” Because Pidathala teaches that the invention
provides a social platform, and because Pidathala further teaches that the
invention is embodied in an informed communities system, we agree with
Appeal 2021-005026
Application 15/675,319

11
the Examiner that the system described in Pidathala is a social media
platform.
In sum, Reno demonstrates that it was known in the art to receive API
call sequences which reflect API calls registered by an application, along
with the timing of those API calls. Banerjee demonstrates that it was known
in the art for frontend applications transmit data and interact with other
system via API calls. Finally, Pidathala shows that it was known in the art
for social media account creation requests to be implemented via API calls
from applications. Taken together, we agree with the Examiner that a
person of ordinary skill in the art, possessing these teachings of Reno,
Banerjee, and Pidathala, would have found it obvious to configure Reno’s
API risk assessment process to evaluate API calls made in the context of
social media account creation requests, as claimed. Therefore, we are not
persuaded that the cited references fail to teach, suggest, or otherwise render
obvious the argued limitation.
Second Issue
In combining the teachings of Reno and Banerjee, the Examiner finds:
[I]t would have been obvious to one of ordinary skill in the art
before the effective filing date to incorporate the frontend
forwarding of API calls of Banerjee into the API call system of
Reno, for the purpose to increase in usability by allowing for
more real time interaction with other various systems thus having
more up to date information for use, as taught by Banerjee
[0003], [0018] and [0027].
Non-Final Act. 6. In the Answer, the Examiner additionally explains:
As it is seen in the teachings of Banerjee [0003], [0018] and
[0027] an interaction of a frontend application system that allows
for interaction with various systems and products thus viewed as
providing additional uses thus increasing overall usability by
allowing for more real time interaction with other various system
Appeal 2021-005026
Application 15/675,319

12
thus having more up to date information for use and thus viewed
as a reason for motivation for modification to include the
teachings of the Banerjee reference.
Ans. 5.
Appellant argues against the combination, asserting that “the
Examiner’s reasoning fails to support the rejection because the ‘data’ that
Banerjee sends to the server system appears to be entirely comparable with,
perhaps fully equivalent to, the API transaction request that Reno sends.”
Appeal Br. 9–10.
We are not persuaded of error in the combination. As an initial
matter, Appellant cites no authority or case law that holds that because two
references overlap in certain respects, they are not combinable. Moreover,
Appellant’s argument does not explain why the reasoning provided by the
Examiner is erroneous. As the Examiner explains, Banerjee teaches the use
of frontend systems that interact via API calls, which would have benefitted
Reno’s risk assessment process by allowing it to be applied to in the
additional context of API calls made in frontend systems. As a result, we
are not persuaded the Examiner erred in combining the teachings of Reno
with those of Banerjee, and we sustain the rejection of claim 1.
Third Issue
Claim 2 depends from claim 1 and recites “wherein applying the API
call sequence model comprises an evaluation of whether the received API
call sequence is missing a particular API call of the frontend component.”
Appeal Br. 17 (Claims Appendix). The Examiner finds that Khan’s
description of comparing API call sequences to determine the success or
failure of an API call teaches this limitation. Non-Final Act. 13–14 (citing
Appeal 2021-005026
Application 15/675,319

13
Khan ¶ 35). Combining Khan with the remaining references, the Examiner
reasons:
[I]t would have been obvious to one of ordinary skill in the art
before the effective filing date to incorporate the teachings of
Khan, showing the being able to determine missing information
of API calls in use of determination of verification/success of the
call, into the API call system of Reno as modified by Banerjee
and Pidathala, for the purpose of increasing usability by
increasing ease of identification of unsuccessful API calls, as
taught by Khan [0035].
Non-Final Act. 14.
Appellant argues Khan is deficient because “Khan here describes that
‘specific events’ can be identified as missing” which “contrasts with the
present subject matter with evaluates whether a ‘particular API call of the
frontend component’ is missing from ‘the received API call sequence.’”
Appeal Br. 12. Appellant further argues that Khan is not combinable with
the other references because it relates to identifying a root cause of an
unsuccessful API call, while the “present subject matter seeks to counteract
‘misuse’ of social media platforms.” Appeal Br. 12 (citing Spec. ¶ 3).
We are not persuaded of error. The cited portion of Khan describes
evaluating sequences of events of API calls for the purpose of anomaly
detection. Khan ¶ 35 (“[A] reference sequence of the state identifiers for
each API call is stored in the state library that can then be compared with an
actual log sequence generated in response to operation of the services for
anomaly detection.”) (“Further, because the expected operation is compared,
specific events can be identified as missing.”). Appellant’s argument is not
persuasive because Appellant does not sufficiently explain why Khan’s
evaluation of missing events from API calls does not teach the recited
“missing API call.” For example, in a case where an API call includes API
Appeal 2021-005026
Application 15/675,319

14
subroutines (for example, in a nested API call), a missing subroutine would
constitute a missing API call. We agree with the Examiner that Khan’s
analysis of log sequences of API calls teaches, or at least suggests, analyzing
API calls to determine if its generated log sequence indicates a specific,
expected API is missing. We, therefore, sustain the rejection of claim 2.
Fourth Issue
Claim 3, depends from claim 2 and recites:
wherein some of the training API call sequences correspond to
valid account creation requests and others of the training API call
sequences correspond to invalid account creation requests, and
wherein the particular API call is identified for use in the
evaluation based on the particular API call having a greater
frequency of occurrence for the valid account creation requests
than for the invalid account creation requests.
Appeal Br. 17 (Claims Appendix).
The Examiner rejects claim 3, relying on Reno and Khan. Non-Final
Act. 14. More specifically, the Examiner relies on Reno’s description of
using a neural network model that is trained based on comparison of
similarities and differences among API requests including pattern
recognition and to train a non-linear analytical. Non-Final Act. 14 (citing
Reno ¶¶ 70–71). The Examiner relies on Khan to show that it was known to
determine when a particular API is missing. Ans. 6–7 (citing Khan ¶ 35).
Appellant argues the Examiner has erred because Reno teaches
training based on the content of the request, and not on “the presence or
absence of a ‘particular API call’ in the evaluation.” Appeal Br. 13.
We are not persuaded of error. Appellant argues that Reno merely
teaches a training model that is based on the content of API requests, and not
on the presence or absence of requests. However, as the Examiner states in
Appeal 2021-005026
Application 15/675,319

15
the Answer, it is Khan, and not Reno, that is not relied upon as teaching the
“particular API call.” Although Appellant argues that Khan does not teach
evaluating whether a particular API call is missing (Reply Br. 6–7), as we
explained in connection with claim 2, we do not find this argument
persuasive. As such, we are not persuaded the Examiner erred in finding the
combination of Reno and Khan teaches or suggests the limitations of
claim 3.
Fifth Issue
Claim 4, depends from claim 2, and additionally recites:
in response to determining that the received API call sequence is
missing the particular API call of the frontend component,
evaluating whether the received API call sequence is missing
another particular API call of the frontend component.
Appeal Br. 18 (Claims Appendix). In rejecting claim 4, the Examiner again
relies on Khan, citing the same portion relied upon for claim 2, and
explaining that Khan’s evaluation of “API call sequence to determine when
specific events/information is missing, [teaches] including a plurality of API
calls of the frontend component as part of [the] determination.” Non-Final
Act. 15 (citing Khan ¶ 35).
Appellant argues the Examiner has erred for the same reasons as
claim 2, and additionally asserts that “[b]ecause Khan does not determine
that a particular API call is missing, Khan similarly cannot, and does not, do
anything ‘in response to’ such a determination that Khan does not perform.”
Appeal Br. 13.
We are not persuaded by Appellant’s arguments. As we noted above,
we disagree with Appellant’s contention that Khan does not determine that a
particular API call is missing. Our reviewing court has held a claim that
Appeal 2021-005026
Application 15/675,319

16
“simply recites repetition of a known procedure until success is achieved,” is
not nonobvious where the repetition is the only difference between the claim
and the prior art. Perfect Web Techs., Inc. v. InfoUSA, Inc., 587 F.3d 1324,
1330 (Fed. Cir. 2009). Here, the claim calls for the repeating the procedure
of evaluating a call sequence for a missing API call. This additional
evaluation amounts to little more than “repetition of a known procedure,”
and consequently is not sufficient to support a conclusion of non-
obviousness. Accordingly, we sustain the rejection of claim 4.
Sixth Issue
Claim 5 depends from claim 1 and recites “wherein applying the API
call sequence model comprises evaluating the timing of the API calls.”
Appeal Br. 18 (Claims Appendix). Claim 7 depends from claim 5 and
further recites “wherein evaluating the timing of the API calls comprises
determining whether a temporal separation of the API calls is randomized.”
Appeal Br. 18 (Claims Appendix). The Examiner rejects claim 7, finding
that Reno’s description of training a non-linear analytical model learning by
identifying patterns and content occurring within a threshold time, teaches
the recited “determining whether a temporal separation of the API calls is
randomized.” Non-Final Act. 8 (citing Reno ¶ 72).4
Appellant argues that “Reno never states that a temporal separation
between API transaction requests may be randomized, let alone that any
determination of such randomness should be performed.” Appeal Br. 14.

4 The Examiner made a typographical error in the rejection of claim 7, citing
to ¶ 27 of Reno instead of ¶ 72. Based on the Examiner’s characterization of
the cited portion of the reference, it seems clear that the intended citation
was ¶ 72.
Appeal 2021-005026
Application 15/675,319

17
We are not persuaded the Examiner has erred. Reno discloses:
[T]he non-linear analytical model 808 can learn overtime to
identify particular content or patterns of content occurring in a
sequence of API transaction requests from a same source node
100 and/or occurring across a plurality of API transaction
requests from different source nodes 100 within a threshold time
(e.g., simultaneously occurring or nearly simultaneously
occurring) that are indicative of a greater or lesser risk.
Reno ¶ 72. Although Reno does not explicitly refer to evaluating the
randomness of temporal separation, it would have nonetheless been obvious.
The artisan of ordinary skill is “a person of ordinary creativity, not an
automaton,” (KSR Int'l Co. v. Teleflex, Inc., 550 U.S. 398, 421 (2007)), who
is not “compelled to adopt every single aspect of [a reference’s] teaching
without the exercise of independent judgment” (Lear Siegler, Inc. v.
Aeroquip Corp., 733 F.2d 881, 889 (Fed. Cir. 1984)). Reno teaches that
simultaneously occurring and nearly simultaneously occurring requests
could be indicative of an anomalous or non-anomalous behavior. Reno ¶ 72.
Thus, Reno demonstrates that it was known in the art to evaluate the specific
timing, i.e., the temporal separation, of API calls to determine anomalous
requests. Given that a person of ordinary skill in the art is “not an
automaton,” we agree with the Examiner that Reno at least suggests
considering randomness in the timing of the requests to make a
determination regarding its legitimacy. Accordingly, we sustain the
rejection of claim 7.
Seventh Issue
Claim 12 depends from claim 1, and additionally recites “wherein the
connection between the API calls and the creation of the account creation
request comprises that at least one of the API calls was registered by the
Appeal 2021-005026
Application 15/675,319

18
frontend component during a predefined period of time after the account
generation request was generated.” Appeal Br. 19 (Claims Appendix).
The Examiner relies on Basso for claim 12. Non-Final Act. 15–16
(citing Basso ¶ 18). The Examiner finds that Basso “is used to show the
specifics of being able to register an API call thus viewed as within the
unlimited predefined time period as it occurs.” Ans. 8.
Appellant argues “the claim specifies this connection to comprise that
at least one of the API calls was registered by the frontend component
during a predefined period of time ‘after’ the account generation request was
generated.” Appeal Br. 14. Appellant further asserts that “Basso does not
teach or suggest any account creation request, let alone that the API calls
should have a connection to the creation of the account request wherein at
least of one of the API calls was registered by the frontend component
‘after’ generation of the account generation request.” Appeal Br. 14–15.
We are persuaded the Examiner has erred. The cited portion of Basso
describes registering API calls in connection with software initialization.
Basso ¶ 18 (“Process 300 performs a registration step 305 when the SPAS
software is initialized. Each NPAS component registers with DMS. The
NPAS component registers each API call within the component with the set
of versions supported by the specific API call.”). Basso further describes
that after a first registration step, a second registration step “is performed
during application initialization in which the user management function
registers with the DMS.” Basso ¶ 18. However, we do not discern any
teaching or suggestion in Basso that API calls are registered after any
specific time. Rather, Basso merely teaches that there may be multiple
registration steps during which API calls are registered.
Appeal 2021-005026
Application 15/675,319

19
The Examiner suggests that Basso’s multi-step registration process
may be “viewed as within the unlimited predefined time period as it occurs.”
However, we do not agree with the Examiner that an unlimited time period
can be a “pre-defined” time period as claimed. As such, we are persuaded
the Examiner has not sufficiently shown that the cited references teach or
suggest “that at least one of the API calls was registered by the frontend
component during a predefined period of time after the account generation
request was generated,” as recited in claim 12, and we do not sustain its
rejection.
Eighth Issue
Claim 15 recites “applying the updated API call sequence model to a
previous account creation request, including at least the received account
creation requests.” Appeal Br. 20 (Claims Appendix). The Examiner relies
on Daniel’s disclosure that “the system can train a machine-learning model
using previous requests and interactions between users and agents to
improve agent efficiency and reduce user wait time.” Non-Final Act. 18
(citing Daniel ¶ 99).
Appellant argues that “Daniel describes that a machine-learning
model can be trained ‘using previous requests.’ By contrast, claim 15 recites
that ‘the updated API call sequence model’ is being applied ‘to a previous
account creation request.’” Appeal Br. 15. According to Appellant, “the
API call sequence model has already been updated according to the language
of claim 15 before it is applied to the previous account creation request”
while “Daniel . . . describes that a machine-learning model ‘can be trained.’”
Appeal Br. 15.
Appeal 2021-005026
Application 15/675,319

20
We are persuaded of error. As Appellant correctly argues, claim 15
recites that the updated API call sequence model is applied to an earlier
account creation request. That is, when the API call sequence model is
updated, an earlier received account creation request is newly considered
under the updated model. The cited portion of Daniel discloses that prior
requests may be used to train a machine-learning model. Daniel ¶ 99.
However, we do not discern any teaching in Daniel that the updated
machine-learning model may then be applied to a previously-received
request, nor does the Examiner provide any explanation or reasoning for
why doing so would have been obvious to a person of ordinary skill in the
art. Without such an explanation, we are constrained by the record to
reverse the rejection of claim 15.
Remaining Claims
Appellant presents no separate arguments for patentability of any
other claims. Accordingly, we sustain the Examiner’s rejections of these
claims for the reasons stated with respect to the independent claims from
which they depend. See 37 C.F.R. § 41.37(c)(1)(iv).
CONCLUSION
We affirm in part the Examiner’s decision to reject the claims.

Appeal 2021-005026
Application 15/675,319

21
DECISION SUMMARY
Claims
Rejected
35 U.S.C.
§
Reference(s)/Basis Affirmed Reversed
1, 5–11, 14,
16–20
103 Reno, Banerjee,
Pidathala
1, 5–11, 14,
16–20

2–4 103 Reno, Banerjee,
Pidathala, Khan
2–4
12 103 Reno, Banerjee,
Pidathala, Basso
12
13 103 Reno, Banerjee,
Pidathala, Douglas
13
15 103 Reno, Banerjee,
Pidathala, Daniel
15
Overall
Outcome
1–11, 13,
14, 16–20
12, 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-IN-PART