BEST, JOHN et al.

Patent Trials and Appeals Board

Mar 6, 2020

15404140 - (D) (P.T.A.B. Mar. 6, 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/404,140 01/11/2017 JOHN BEST BEST_I.00008 4101
101225 7590 03/06/2020
Law Office of John F. Rollins
210 N. Ellis Avenue
Wheaton, IL 60187
EXAMINER
AGWUMEZIE, CHINEDU CHARLES
ART UNIT PAPER NUMBER
3685
NOTIFICATION DATE DELIVERY MODE
03/06/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@rollinsip.com
jfr@rollinsip.com
PTOL-90A (Rev. 04/07)

UNITED STATES PATENT AND TRADEMARK OFFICE
____________

BEFORE THE PATENT TRIAL AND APPEAL BOARD
____________

Ex parte JOHN BEST, EDWIN GONZALEZ, THOMAS STACY and
ELLIOT COTTO
____________

Appeal 2019-003964
Application 15/404,140
Technology Center 3600
____________

Before JEFFREY S. SMITH, TREVOR M. JEFFERSON, and
AMBER L. HAGY, Administrative Patent Judges.

SMITH, Administrative Patent Judge.

DECISION ON APPEAL
Appeal 2019-003964
Application 15/404,140

2
STATEMENT OF THE CASE
This is an appeal under 35 U.S.C. § 134(a) from the rejection of
claims 1–20. We have jurisdiction under 35 U.S.C. § 6(b).
We affirm.

Illustrative Claim
1. A method for implementing automatic updating of user
payment information across multiple vendor websites,
comprising:
providing a user interface to a user device associated with
a user via an account management application running on the
user device, the user interface enabling the user to manage
payment information stored in a plurality of user accounts, each
account associated with a respective one of a plurality of
vendors, the plurality of user accounts being associated with the
user;
receiving, electronically by one or more hardware
processors on the user device associated with the user interface
of the account management application, a first set of inputs
from the user, the first set of inputs comprising instructions to
push payment information associated with the user, the
payment information including credentials that enable each
respective vendor to access payment directly from the user's
financial institution;
receiving, electronically by the one or more hardware
processors on the user device associated with the user interface
of the account management application, a second set of inputs
from the user, the second set of inputs comprising instructions
indicating two or more user accounts for at least two vendor
websites of a plurality of vendor websites with which the
payment information is to be updated, each user account being
associated with the user and with one vendor website of the
plurality of vendor websites;
Appeal 2019-003964
Application 15/404,140

3
requesting, electronically by the one or more hardware
processors on the user device associated with the account
management application and from a token service provider
("TSP") server, tokenized payment information for each
payment method indicated in the payment information that is
associated with the user for each vendor;
receiving, electronically by the one or more hardware
processors on the user device from the TSP server, the
tokenized payment information for each payment method
indicated in the payment information that is associated with the
user for each vendor; and
automatically concurrently pushing, electronically by the
one or more hardware processors on the user device and over
one or more networks in communication with respective remote
servers associated with at least each of the at least two vendor
websites, corresponding tokenized payment information,
including credentials that enable each respective vendor to
access payment directly from the user's financial institution, to
the two or more user accounts, in response to receiving the first
and second sets of inputs from the user, each of the two or more
user accounts being associated with the two or more vendor
websites.

Prior Art
Raj et al. US 2014/0344153 A1 Nov. 20, 2014
Braski et al. US 2016/0117679 A1 Apr. 28, 2016

Examiner’s Rejections
Claims 1–20 stand rejected under 35 U.S.C. § 101 as directed to
patent-ineligible subject matter.
Claims 1–20 stand rejected under 35 U.S.C. § 103 as unpatentable
over Braski and Raj.

Appeal 2019-003964
Application 15/404,140

4
ANALYSIS
35 U.S.C. § 101 Rejection
The Examiner determines claims 1–20 are rejected under 35 U.S.C.
§ 101 because the claimed invention is directed to a judicial exception (i.e.,
an abstract idea) without significantly more. Final Action 3–5; see Alice
Corp. Pty. Ltd. v. CLS Bank Int’l, 573 U.S. 208, 217 (2014) (describing the
two-step framework “for distinguishing patents that claim laws of nature,
natural phenomena, and abstract ideas from those that claim patent-eligible
applications of those concepts”).
The USPTO published revised guidance on the application of § 101.
2019 Revised Patent Subject Matter Eligibility Guidance, 84 Fed. Reg. 50
(January 7, 2019) (“Guidance”). Under the Guidance, the Office first looks
to whether the claim recites:
(1) any judicial exceptions, including certain groupings of
abstract ideas (i.e., (a) mathematical concepts, (b) certain
methods of organizing human activity such as a fundamental
economic principles and practice, commercial or legal
interactions, managing personal behavior, relationships,
interpersonal interactions, (c) mental processes; and

(2) additional elements that integrate the judicial exception into
a practical application (see MPEP § 2106.05(a)–(c), (e)–(h) (9th
ed. 2018).
Only if a claim (1) recites a judicial exception and (2) does not integrate
that exception into a practical application, does the Office then look to
whether the claim:
(3) adds a specific limitation beyond the judicial exception that
is not “well-understood, routine, conventional” in the field (see
MPEP § 2106.05(d)); or

Appeal 2019-003964
Application 15/404,140

5
(4) simply appends well-understood, routine, conventional
activities previously known to the industry, specified at a high
level of generality, to the judicial exception.
See Guidance.
Alice/Mayo—Step 1 (Abstract Idea)
Step 2A–Prongs 1 and 2 identified in the Revised Guidance
Step 2A, Prong One
Appellant contends the Examiner’s 35 U.S.C. § 101 rejection should
be reversed because
[t]he claims in this application represent advancement in
technology including improvements to computing technology.
For example, the claims require, inter alia, the steps of
requesting, electronically by the one or more hardware
processors on the user device associated with a computer
associated with the account management application and from a
token service provider (“TSP”) server, tokenized payment
information for each payment method indicated in the payment
information that is associated with the user for each vendor.
This step alone takes the claim well beyond an abstract idea.
The present claims do not recite fundamental economic
practices, long prevalent in our system of commerce, or
fundamental truths, or building blocks of human ingenuity.
Thus, the present claims are patent eligible.
Appeal Br. 13.
Appellant’s argument is not persuasive. Instead, we agree with the
Examiner’s determination that the claims recite an abstract idea. Final
Action 4; Answer 3.
The Specification discloses:
Various embodiments provide techniques for
implementing automatic updating or pushing of payment
information (which, herein, includes, without limitation, credit
card data, other payment information, account information,
Appeal 2019-003964
Application 15/404,140

6
billing information, and/or the like) to multiple retail and
payment sites (collectively, “vendor websites”).
In some embodiments, a user may log into a master
account (e.g., a single sign-on account, a card management
account, a payment management account, and/or the like), and
may be provided with access to tools or options to manage his
or her payment accounts and information, to manage his or her
vendor accounts, and/or the like within the account. For
example, tools or options to manage the user’s payment
accounts and information might include, without limitation,
tools or options to add a payment method (e.g., add a credit
card, add a debit card, add a checking account, add a savings
account, add a mortgage loan account, add another loan
account, and/or the like), update information for the payment
method (e.g., update expiration date, update card security code,
setup a particular payment method as a default payment
method, etc.), delete a payment method (e.g., delete a credit
card, delete a debit card, delete a checking account, delete a
savings account, delete a mortgage loan account, delete another
loan account, and/or the like), update billing information (e.g.,
update user’s name (if there has been a change of name), update
user’s billing address, update user’s mailing address, update
user’s telephone number, update user’s e-mail address, and/or
the like), and/or the like.
Specification ¶¶ 21–22. The Specification also discloses
In this manner, a user can easily update all relevant
vendor accounts whenever the user changes a payment method
(e.g., credit card), whenever a payment method expires and a
new one issues (e.g., when a credit card expires and a new card
is issued), whenever the user changes addresses, and/or the like,
without having to personally log into each relevant vendor’s
website and change by hand the payment information for the
individual vendor.
Specification ¶ 25.
Claim 1 recites a method for implementing automatic updating of user
payment information across multiple vendor websites, comprising:
Appeal 2019-003964
Application 15/404,140

7
1. receiving instructions to push payment information associated with a user,
the payment information including credentials that enable each respective
vendor to access payment directly from the user’s financial institution;
2. receiving instructions indicating two or more user accounts for at least
two vendor websites with which the payment information is to be updated;
3. requesting tokenized payment information from a token service provider
(“TSP”) server for each payment method indicated in the payment
information that is associated with the user for each vendor;
4. receiving the tokenized payment information from the TSP server; and
5. automatically pushing the tokenized payment information including
credentials that enable each respective vendor to access payment directly
from the user’s financial institution to the two or more user accounts.
Thus, the claim recites steps for automatically updating a user’s
payment information across multiple vendor websites to enable vendors to
access payment directly from the user’s financial institution. Such steps
comprise fundamental economic practices, as well as commercial
interactions, both of which constitute the abstract idea of “certain methods of
organizing human activity.” See Guidance at 52 (Section I(b)); Inventor
Holdings, LLC v. Bed Bath & Beyond, Inc., 876 F.3d 1372, 1378–79 (Fed.
Cir. 2017) (holding that the concept of “local processing of payments for
remotely purchased goods” is a “fundamental economic practice, which
Alice made clear is, without more, outside the patent system”).
Therefore, we conclude the claims recite an abstract idea pursuant to
Step 2A, Prong One of the guidance. See Guidance, Section III(A)(1)
(Prong One: Evaluate Whether the Claim Recites a Judicial Exception).
Appeal 2019-003964
Application 15/404,140

8
Step 2A, Prong Two
Under Prong Two of the Revised Guidance, we must determine
“whether the claim as a whole integrates the recited judicial exception
into a practical application of the exception.” Guidance, Section III(A)(2).
“A claim that integrates a judicial exception into a practical application will
apply, rely on, or use the judicial exception in a manner that imposes a
meaningful limit on the judicial exception, such that the claim is more than a
drafting effort designed to monopolize the judicial exception.” Id.
Appellant contends
Moreover, even if the claims can properly be
characterized as “directed to” an abstract idea, the Answer fails
to provide a complete and proper analysis under Step 2A of the
patent-eligible analysis. As the 2019 PEG makes clear, Step 2A
is a two-prong inquiry, with the second prong being to evaluate
whether the claim recites additional elements that integrate the
exception into a practical application of the exception.
Reply Br. 3–4. Appellant contends
[t]he claimed tokenization and concurrently pushing
steps, which seemed to remain unaddressed by the examiner in
the 101 rejections in the Office Actions, and in the Answer,
represent a technical improvement provided by embodiments of
the invention. These steps provide increased security, as
explained in the patent specification, particularly in paragraph
[0131].
Id. at 5. Paragraph 131 of Appellant’s Specification discloses
The tokenization process provides extended security for
the service provided by the service provider. Instead of pushing
actual credit card numbers to a merchant, a tokenized credit
card number that is specific to that particular merchant will be
created and pushed into the merchant’s website. If the merchant
were to be breached by hackers, the “credit card data” that the
hackers would not be useable on any other merchant’s website.
Appeal 2019-003964
Application 15/404,140

9
We do not find Appellant’s arguments persuasive. The recited
limitations do not reflect an improvement in the functioning of a computer
or other technology or technical field. See Guidance at 55; cf. Trading
Techs. Int’l, Inc. v. IBG LLC, 921 F.3d 1084, 1090 (Fed. Cir. 2019) (“This
invention makes the trader faster and more efficient, not the computer. This
is not a technical solution to a technical problem.”). Further, the claims
utilize general purpose hardware (a user device, hardware processors, vendor
websites, and a token service provider server). See Specification ¶¶ 177–
198, Figs. 11 and 12; see also Enfish, LLC v. Microsoft Corp., 822 F.3d
1327, 1335–36 (Fed. Cir. 2016) (“[W]e find it relevant to ask whether the
claims are directed to an improvement to computer functionality versus
being directed to an abstract idea . . . the focus of the claims is on the
specific asserted improvement in computer capabilities (i.e., the self-
referential table for a computer database) or, instead, on a process that
qualifies as an ‘abstract idea’ for which computers are invoked merely as a
tool.”).
We are not persuaded by Appellant’s contention that the claims recite
steps beyond the abstract idea, such as “increased security.” See Reply Br.
5–6. Specifically, the claim does not: (1) improve the functioning of a
computer or other technology; (2) is not applied with any particular machine
(except for generic hardware); (3) does not effect a transformation of a
particular article to a different state; and (4) is not applied in any meaningful
way beyond generally linking the use of the judicial exception to a particular
technological environment, such that the claim as a whole is more than a
drafting effort designed to monopolize the exception. See MPEP
§§ 2106.05(a)–(c), (e)–(h).
Appeal 2019-003964
Application 15/404,140

10
Claim 1’s data-gathering steps (“receiving . . . a first set of inputs,”
“receiving . . . a second set of inputs”) reasonably can be characterized as
merely constituting insignificant extra-solution activity:
An example of pre-solution activity is a step of gathering data
for use in a claimed process, e.g., a step of obtaining
information about credit card transactions [that] is recited as
part of a claimed process of analyzing and manipulating the
gathered information by a series of steps in order to detect
whether the transactions were fraudulent.
MPEP § 2106.05(g). As our reviewing court has explained, such data
gathering simply provides data for other method steps. See, e.g.,
CyberSource Corp. v. Retail Decisions, Inc., 654 F.3d 1366, 1370 (Fed. Cir.
2011) (“We have held that mere ‘[data-gathering] step[s] cannot make an
otherwise nonstatutory claim statutory.”’ (alterations in original) (quoting In
re Grams, 888 F.2d 835, 840 (Fed. Cir. 1989))); see also 2019 Guidance at
55 (identifying “add[ing] insignificant extrasolution activity to the” abstract
idea as an example of when an abstract idea has not been integrated into a
practical application).
Claim 1’s other steps entail updating user payment information. But
the act of updating payment information constitutes the underlying abstract
idea—the fundamental economic practice and the commercial interaction
that, as we determine above, constitute certain methods of organizing human
activity. See BSG Tech LLC v. Buyseasons, Inc., 899 F.3d 1281, 1290 (Fed.
Cir. 2018) (“It has been clear since Alice that a claimed invention’s use of
the ineligible concept to which it is directed cannot supply the inventive
concept that renders the invention ‘significantly more’ than that ineligible
concept.”); Synopsys, Inc. v. Mentor Graphics Corp., 839 F.3d 1138, 1151
(Fed. Cir. 2016) (“[A] claim for a new abstract idea is still an abstract
Appeal 2019-003964
Application 15/404,140

11
idea.”); SAP America, Inc. v. InvestPic, LLC, 898 F.3d 1161, 1168 (Fed. Cir.
2018) (“What is needed is an inventive concept in the non-abstract
application realm.”).
Accordingly, we determine the claim does not integrate the recited
judicial exception into a practical application and is, therefore, directed to an
abstract idea. See Guidance, Section III(A)(2) (Prong Two: If the Claim
Recites a Judicial Exception, Evaluate Whether the Judicial Exception Is
Integrated Into a Practical Application).
Alice/Mayo—Step 2 (Inventive Concept)
Step 2B identified in the Revised Guidance
Step 2B
Next, we determine whether the claim includes additional elements
that provide significantly more than the recited judicial exception, thereby
providing an inventive concept. Alice, 573 U.S. at 217–18 (quoting Mayo
Collaborative Servs. v. Prometheus Labs., Inc., 566 U.S. 66, 72–73 (2012)).
We find the claim does not include a specific limitation or a combination of
elements that amounts to significantly more than the judicial exception itself.
See Guidance, Section III(B)(Step 2B: If the Claim Is Directed to a Judicial
Exception, Evaluate Whether the Claim Provides an Inventive Concept); see
also Aatrix Software, Inc. v. Green Shades Software, Inc., 890 F.3d 1354,
1359 (Fed. Cir. 2018) (“the ‘inventive concept’ cannot be the abstract idea
itself”). Other than the abstract idea itself, the remaining claim elements
only recite generic computer components that are well-understood, routine,
and conventional. See Final Action 4–5; Ans. 3–4; Specification ¶¶ 177–
198, Figs. 11 and 12 ; Alice, 573 U.S. at 226.
Accordingly, we conclude claims 1–20 are directed to fundamental
economic practices and commercial interactions, which are two of certain
Appeal 2019-003964
Application 15/404,140

12
methods of organizing human activity identified in the Guidance and thus an
abstract idea. Further, the claims do not recite limitations that amount to
significantly more than the abstract idea itself. We sustain the Examiner’s
35 U.S.C. § 101 rejection of claims 1–20.

35 U.S.C. § 103 Rejection
Independent claim 1 recites “receiving . . . on the user device . . . [a]
first set of inputs comprising instructions to push payment information . . .
[and] pushing, electronically by the one or more hardware processors on the
user device . . . tokenized payment information.” The Examiner finds that
Braski teaches these limitations. Final Action 6–9. Appellant contends
Braski teaches that a financial institution server, rather than the claimed user
device, pushes payment information to a wallet integration server. See
Appeal Br. 16; Reply Br. 7–8.
Braski teaches that a user accesses a wallet integration server, and
sends a selection of vendors to the wallet integration server. Braski,
Abstract, ¶¶ 37–38, 68–69, Fig. 4A. Braski teaches that the wallet
integration server retrieves the user’s payment information from a financial
institution server, encrypts the payment information, and transmits the
payment information to the selected vendors. Braski, Abstract, ¶¶ 39–40,
72, Fig. 4C. Thus, Braski teaches that the wallet integration server, rather
than the user device, pushes payment information to the vendors.
The Examiner does not provide persuasive evidence to show that
implementing Braski’s method for automatically updating payment
information on a user device, rather than on a server, would have been
within the level of ordinary skill. Given that Braski’s disclosure appears to
Appeal 2019-003964
Application 15/404,140

13
teach implementing the method only on a server, and not on a user’s device,
and given that the Examiner has not persuasively explained why
implementing Braski’s method on the user’s device would have been
obvious, we do not sustain the rejection of claim 1 and dependent claims 2–
18 under 35 U.S.C. § 103.
In contrast to claim 1, independent claims 19 and 20 do not limit the
claimed “pushing” to be performed on the user device. Therefore,
Appellant’s contention is not commensurate with the scope of the claims.
We agree with the Examiner that “receive . . . instructions to push payment
information” and “automatically concurrently push . . . payment
information” as recited in claims 19 and 20 is taught by Braski’s disclosure
of a user authorizing, or “instructing,” the wallet integration server to
automatically update payment information, and the server subsequently
automatically updating the payment information. Braski ¶ 14; see id. at
Abstract, ¶¶ 5, 12–13, 35–41, 63–79; Final Action 6–9; Answer 4–8.
Appellant contends that Braski teaches encrypting the payment
information, rather than tokenizing the payment information as claimed.
Appeal Br. 17; Reply Br. 9. Appellant does not provide persuasive evidence
or explanation to distinguish the claimed tokenized payment information
from the encrypted payment information of Braski. To the extent that
tokenized payment information is different than encrypted payment
information, Raj teaches that tokenizing payment information was within the
level of ordinary skill. Raj, Abstract, Figs. 3 and 4, ¶¶ 53–54, 58, 69–70, 97.
Substituting the known tokenized payment information of Raj for the known
encrypted payment information used by the wallet integration server of
Braski yields the predictable result of the wallet integration server
Appeal 2019-003964
Application 15/404,140

14
automatically concurrently pushing tokenized payment information. See
KSR Int’l Co. v. Teleflex, Inc., 550 U.S. 398, 416 (2007) (“The Court
recognized that when a patent claims a structure already known in the prior
art that is altered by the mere substitution of one element for another known
in the field, the combination must do more than yield a predictable result.”).
We sustain the rejection of claims 19 and 20 under 35 U.S.C. § 103.

DECISION
The rejection of claims 1–20 under 35 U.S.C. § 101 as directed to
patent-ineligible subject matter is affirmed.
The rejection of claims 1–18 under 35 U.S.C. § 103 as unpatentable
over Braski and Raj is reversed.
The rejection of claims 19 and 20 under 35 U.S.C. § 103 as
unpatentable over Braski and Raj is affirmed.

CONCLUSION
In Summary:
Claims
Rejected
35 U.S.C. § References/Basis Affirmed Reversed
1–20 101 Non-statutory
subject matter
1–20
1–20 103 Braski, Raj 19, 20 1–18
Overall
Outcome
1–20

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.
§ 41.50(f).
Appeal 2019-003964
Application 15/404,140

15

AFFIRMED