Murgesh Navar et al.

Patent Trials and Appeals Board

Jun 30, 2020

2020000801 (P.T.A.B. Jun. 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.
13/294,134 11/10/2011 Murgesh Navar TE2-015 6154
138557 7590 06/30/2020
Polsinelli LLP - TE2
3 Embarcadero Center
Suite 2400
San Francisco, CA 94111
EXAMINER
CHOO, JOHANN Y
ART UNIT PAPER NUMBER
3685
NOTIFICATION DATE DELIVERY MODE
06/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):
sfpatent@polsinelli.com
uspt@polsinelli.com
PTOL-90A (Rev. 04/07)

UNITED STATES PATENT AND TRADEMARK OFFICE
____________

BEFORE THE PATENT TRIAL AND APPEAL BOARD
____________

Ex parte MURGESH NAVAR and GEORGE MCMULLEN

Appeal 2020-000801
Application 13/294,134
Technology Center 3600
____________

Before RICHARD M. LEBOVITZ, RACHEL H. TOWNSEND, and
JAMIE T. WISZ, Administrative Patent Judges.

LEBOVITZ, Administrative Patent Judge.

DECISION ON APPEAL
The Examiner rejected the claims under 35 U.S.C. § 103 as obvious,
and under 35 U.S.C. § 101 as reciting patent ineligible subject matter.
Pursuant to 35 U.S.C. § 134(a), Appellant1 appeals from the Examiner’s
decision to reject the claims. We have jurisdiction under 35 U.S.C. § 6(b).
We REVERSE.

1 We use the word “Appellant” to refer to “applicant” as defined in 37
C.F.R. § 1.42. Appellant identifies the real party in interest as Blazer and
Flip Flops, Inc. DBA The Experience Engine. Appeal Br. 3.
Appeal 2020-000801
Application 13/294,134

2
STATEMENT OF THE CASE
The claims stand rejected2 by the Examiner as follows:
1. Claims 1, 2, 8, 9, 15, 16, 20, and 25–29 under pre-AIA 35 U.S.C.
§ 103(a) as obvious in view of Tieken (US 2011/0161233 A1, published Jun.
30, 2011) (“Tieken”), Fukaya (US 2006/0280297 A1, published Dec. 14,
2006) (“Fukaya”), and Youn et al. (US 2007/0230704 A1, published Oct. 4,
2007) (“Youn”). Non-final Act. 8.
2. Claims 3 and 10 under pre-AIA 35 U.S.C. § 103(a) as obvious in
view of Tieken, Fukaya, Youn, and Blackhurst et al. (US 2011/0191160 A1,
published Aug. 4, 2011) (“Blackhurst”). Non-final Act. 16.
3. Claims 4 and 11 under pre-AIA 35 U.S.C. § 103(a) as obvious in
view of Tieken, Fukaya, Youn, and Flitcroft et al. (US 2003/0028481 A1,
published Feb. 6, 2003) (“Flitcroft”). Non-final Act. 17.
4. Claims 5, 12 and 30 under pre-AIA 35 U.S.C. § 103(a) as obvious
in view of Tieken, Fukaya, Youn, Flitcroft, and Hoerenz (US 2004/0267611
A1, published Dec. 30, 2004) (“Hoerenz”). Non-final Act. 18.
5. Claims 6 and 13 under pre-AIA 35 U.S.C. § 103(a) as obvious in
view of Tieken, Fukaya, Youn, Flitcroft, Hoerenz, and Harris et al. (US
2006/0200480 A1, published Sep. 7, 2006 A1) (“Harris”). Non-final Act.
19.
6. Claims 17 and 18 under pre-AIA 35 U.S.C. § 103(a) as obvious in
view of Tieken, Fukaya, Youn, and Bickerstaff et al. (US 2009/0036095 A1,
published Feb. 5, 2009) (“Bickerstaff”). Non-final Act. 20.

2 Non-final Office Action (Oct. 2, 2018) (“Non-final Act.”).
Appeal 2020-000801
Application 13/294,134

3
7. Claim 19 under pre-AIA 35 U.S.C. § 103(a) as obvious in view of
Tieken, Fukaya, Youn, Bickerstaff, and Zandonadi (US 2008/0257952 A1,
published Oct. 23, 2008) (“Zandonadi”). Non-final Act. 22.
8. Claims 1–6, 8–13, 15–20, and 25–30 under 35 U.S.C. § 101
because the claimed invention is directed to non-statutory subject matter.
Non-final Act. 4.
Claim 1 is representative and reproduced below. The claim has been
annotated with bracketed numbers and letters for reference to the limitations
in the claim.
1. A method of encryption for recurring mobile transactions, the
method comprising:
[1] receiving a request for a mobile transaction
transmitted from a mobile device over a communication
network and received at a gateway server, wherein the request
includes a user key that is not maintained at the mobile device
and sensitive data;
[2] executing instructions stored in memory of the
gateway server, wherein execution of instructions by a
processor of the gateway server:
[2a] generates an encryption key based on a server
key stored at the gateway server and the received user key,
wherein the received user key is not maintained at the gateway
server,
[2b] encrypts the sensitive date in the request using
the generated encryption key, and
[2c] transmits the encrypted sensitive data over the
communication network from the gateway server to the mobile
device;
[3] receiving a subsequent request for a different mobile
transaction from the mobile device, the subsequent request
including the user key that continues not to be maintained at the
mobile device and the encrypted sensitive data; and
[4] executing further instructions stored in the memory of
the gateway server, wherein execution of the further
instructions by the processor of the gateway server:
Appeal 2020-000801
Application 13/294,134

4
[4a] generates a decryption key based on the user
key received in the subsequent request and the stored server
key, wherein the user key received in the subsequent request is
not maintained at the gateway server
[4b] decrypts the encrypted sensitive data using the
generated decryption key, and
[4c] transmits the decrypted sensitive data to a
payment processor for processing.

CLAIM 1
There are two principal computer platforms in claim 1, a “gateway
server” and a “mobile device.” A gateway server is a server or other type of
computing device which can communicate with a mobile device and a point-
of-sale terminal. Spec. ¶¶ 18, 21, 22. The mobile devices can be “mobile
phones, smartphones, personal digital assistants (PDAs), handheld
computing device, portable computing devices (e.g., laptop, netbook,
tablets), or any other type of computing device capable of communicating
over communication network.” Spec. ¶ 20.
In step [1] of claim 1, the gateway server receives a request from the
mobile device for a “mobile transaction” that includes a “user key” and
“sensitive data. The “user key” can be a “PIN code.” Spec. ¶ 9; Fig. 14
(showing a 4 digit PIN). The “sensitive data” is not defined in the
Specification, but we understand it in the context of the Specification to
include financial account information, such as a credit card number or bank
account identifier. Spec. ¶¶ 5, 10. The “mobile transaction” can be a credit
card purchase. Spec. ¶¶ 4, 10. The user key is not maintained at the mobile
device. Thus, in step [1], the user enters a PIN number (“user key”) and
credit card information (“sensitive data”) to make a purchase (“mobile
transaction”) and the information is sent to the gateway server.
Appeal 2020-000801
Application 13/294,134

5
In step [2a], an “encryption key” is generated at the gateway server
based on a “server key” stored at the gateway server and the “user key”
which is not maintained at the server. The “encryption key” is used to
encrypt the sensitive data (step [2b]) which is then sent back to the mobile
device (step [2c]). The mobile device therefore has the encrypted sensitive
data (such as an encrypted credit card number).
A subsequent request for a different financial mobile transaction (e.g.,
to make a second credit card purchase) is made to the gateway server in step
[3], where the request includes the user key (e.g., the PIN number) and the
encrypted sensitive data (e.g., encrypted credit card number) generated in
step [2]. Thus, the user does not have to send the unencrypted sensitive data
again, but rather has an encrypted form to send to server.
In the last step of the claim, the gateway server generates a
“decryption key” based on the “user key” and the “server key” (step [4a]).
The gateway server decrypts the encrypted sensitive data (e.g., the credit
card number) (step [4b]), and sends it to a payment processor for processing
(step [4c]).

REJECTIONS BASED ON TIEKEN, FUKAYA, AND YOUN
The Examiner found that Tieken describes a method of encrypting
“recurring” mobile transactions. The Examiner found that Tieken describes
the same steps of claim 1, but not generating an encryption key at the
gateway server using a “user key” and “server key” as in step [2a] of claim
1. Non-Final Act. 10. To meet this deficiency, the Examiner cited Fukaya
which the Examiner found discloses combining a user key and a server key
“to form a new keys used to encrypt information which is then sent back to
Appeal 2020-000801
Application 13/294,134

6
the user device.” Id. at 10. The Examiner reasoned it would have been
obvious to one of ordinary skill at the time of the invention to use Fukaya’s
“two-part key combination to encrypt information” in Tieken’s method “to
ensure that the encryption on each key is unique to the users requesting the
encryption of their information and sending the result to the requesting
party.” Id.
The Examiner also stated that Tieken does not teach that the user key
is not maintained at the mobile device or the gateway server as required by
steps [1] and [2a] of the claim. Non-Final Act. 10–11. However, the
Examiner found that Youn teaches a user key that is not maintained at either
location. Id. at 11. The Examiner found it obvious to apply Youn’s
teachings to Tieken and Fukyama “to increase the amount of security by
having the user input the user key at each transaction.” Id.
Appellant contends that the Examiner’s reliance on Tieken’s “tokens”
to teach the encryption steps of claim 1 is improper because the tokens are
not the same as encrypted information. Appeal Br. 14. Rather, Appellant
argues that tokens identify and replace a financial account number, but the
token is not encrypting the account information (“sensitive data”) as
required by the claim. Id. at 14–15. Appellant also argues that Fukaya
describes the exchange of encryption keys between devices, contrary to what
is claimed, and does not describe a “user key” which is not stored on either
the mobile device or the gateway server. Id. at 15.
We agree with Appellant that the Examiner did not establish prima
facie obviousness of claim 1. We begin with Tieken by discussing an
embodiment shown in Figure 3. Figure 3 of Tieken is reproduced below:

Appeal 2020-000801
Application 13/294,134

7

Figure 3 is a block diagram showing the steps of an embodiment
described in Tieken. Tieken ¶ 54. In step 315, the identifier of the financial
account is encrypted. Tieken ¶ 56. Thus, this step is similar to step [2] of
the claim, but Tieken does not use a “user key” (such as a PIN number) as
part of the encryption process to generate an encryption key and encrypt the
account information as in step [2a] and [2b] of claim 1. Rather, Tieken
Appeal 2020-000801
Application 13/294,134

8
receives the encryption key from another source, such as the payment
processor. Tieken ¶ 56.
In claim 1, the encrypted data is sent back to the mobile device (step
[2c]). This step, as indicated by Appellant, does not take place in Tieken.
As shown in Figure 3 and explained by Tieken, after the financial account
information is decrypted in step 330 and sent to the payment processor in
step 335, a token is created in step 345. The token is stored in step 350, and
transmitted back to a device in step 355. Tieken ¶¶ 8, 59. The token is sent
back to the device, but the token does not contain encrypted data. While the
token is used to protect the financial account information (Tieken ¶ 60), it is
not used in subsequent mobile transactions as it is in step [3] of clam 1. To
the contrary, Tieken states that tokens cannot be used to initiate a financial
transaction. Tieken ¶¶ 10, 20. Tieken explains what the tokens are used for:
The merchant or service provider may receive the transaction
authorization. It may then delete the identifier of the financial
account and all other sensitive data associated with the financial
account, even if it is encrypted, and retain the token in its place.
The merchant or service provider may store the token for
numerous purposes, including, but not limited to, settlement,
reconciliation, and chargebacks. The tokens along with other
related transaction data may be used also for analytics and anti-
fraud measures. If the tokens are intercepted or stolen, they may
have no value to the thief, since they may not be used to initiate
a financial transaction.
Tieken ¶ 10.
The token may not be used to initiate a new transaction, such as
a new purchase. However, the token may be utilized for other
purposes, such as transaction refunds, transaction settlements,
and transaction adjustments, merely by way of example.
Furthermore, a merchant may utilize the token associate[d] with
a customer’s purchases [to] provide analytics regarding customer
Appeal 2020-000801
Application 13/294,134

9
purchases. It may also be used for anti-fraud purposes, merely
by way of example.
Tieken ¶ 20.
Therefore, while Tieken describes encrypting the financial data in step
[2a], the encrypted data is not sent back to the mobile device as required by
step [2c] and it is not used to provide payment information for a second and
subsequent financial mobile transaction as in step [3] of the claim. See
Appeal Br. 15. Figure 4 of Tieken shows another embodiment, but it also
uses tokens in the same way as in Figure 3 and is deficient for the same
reason.
The Examiner responded to Appellant’s argument regarding the
difference between how tokens are used in Tieken and the encrypted data in
the claim by directing attention to paragraphs 7, 27, and 35 of Tieken. Ans.
6. However, these paragraphs describe the general use of encryption keys,
but do not disclose sending the encrypted data back to the mobile device as
in step [2c] of claim 1. The Examiner also referred to paragraphs 8, 28, 40,
and 67 of Tieken. Non-Final Act. 9. These paragraphs refer to a token,
which as explained above, is not the same as the encrypted data of step [2c]
and [3]. The Examiner also stated that Appellant erroneously “mapped” the
tokens to the encryption key (Ans. 5–6), but the Examiner referenced the
tokens and the tokens are sent back to the device in Tieken.
The Examiner cited Fukaya for teaching combining a user key and
server key as in step [2a] of the claim. Non-Final Act. 10. The Examiner
also found Fukaya describes steps [2c] of the claim in sending the encrypted
data back to the mobile device, citing paragraphs 93 and 100 of Fukaya. Id.
Paragraphs 93 and 100 of Fukaya describe preparing an encryption
key Kab based on a key of the user sent to the server and a key of the server.
Appeal 2020-000801
Application 13/294,134

10
Fukaya further describes sending the encrypted data and server key back to
the device. Fukaya ¶ 100. The data is then sent back to the server with the
user key. Id. This step is done for authentication purposes. Id. Thus, as
discussed by Appellant (Appeal Br. 16), this two-way exchange of
encryption keys is very different from the claim, where no encryption keys
are exchanged. The Examiner did not explain why it would have been
obvious to send the encrypted data back to the mobile device, instead of
using tokens as described by Tieken, and how this would have reasonably
suggested re-using the encrypted data to initiate a subsequent mobile
transaction as in step [3] of claim 1, when Tieken expressly teaches that
tokens are not to be used for this purpose (Tieken ¶¶ 10, 20).
Youn describes a “user-secret” which corresponds to the “user key” of
claim 1. Youn ¶¶ 8, 18. In Youn’s process, the server encrypts the user
secret and server key. Youn ¶ 28. When the user wants the server to
decrypt data stored on its behalf, it requests encrypted information, decrypts
it, and sends the server key back to the server. Id. Thus, while this step uses
a user key in combination with a server key as in step [2a] of the claim, it
does not use these two keys to generate an encryption key as also required
by the step. In view of the deficiencies in Tieken and Fukaya as described
above, even if there were a reason to use a user-secret instead of an
encryption key as in Fukaya, one of skill in the art would still not have
arrived at the claimed invention. Nonetheless, the Examiner’s reasoning to
modify Fukaya by using a “user-secret” is inconsistent with Fukaya which
uses two encryption keys in a two way exchange. The Examiner did not
explain why it would have been obvious to have not used two encryption
keys, when Fukaya’s method is based on that teaching.
Appeal 2020-000801
Application 13/294,134

11
For the foregoing reasons, the rejection of claim 1, and dependent
claims 2, 8, 9, and 20–25, is reversed.
Independent claims 15, 16, and 20 have substantially the same
limitations as claim 1 and is reversed for the same reason as claim 1.
Obviousness rejections 2–7 of dependent claims 3–6, 10–13, 17–19,
and 30 are reversed, as well, because the Examiner did not establish that the
additional publications cited in the rejections make up for the deficiencies in
Tieken, Fukaya, and Young described above.

REJECTION BASED ON 101
Principles of Law
Under 35 U.S.C. § 101, an invention is patent-eligible if it claims a
“new and useful process, machine, manufacture, or composition of matter.”
However, not every discovery is eligible for patent protection. Diamond v.
Diehr, 450 U.S. 175, 185 (1981). “Excluded from such patent protection are
laws of nature, natural phenomena, and abstract ideas.” Id. The Supreme
Court articulated a two-step analysis to determine whether a claim falls
within an excluded category of invention. Alice Corp. Pty. Ltd. v. CLS Bank
Int’l, 134 S.Ct. 2347 (2014); Mayo Collaborative Servs. v. Prometheus Labs,
Inc., 566 U.S. 66, 75–77 (2012).
In the first step, it is determined whether the claims at issue recited
one of those patent-ineligible concepts. Alice, 134 S.Ct. at 2355. If it is
determined that the claims recite an ineligible concept, then the second step
of the two-part analysis is applied in which it is asked “[w]hat else is there in
the claims before us?” Id. The Court explained that this step involves
a search for an ‘inventive concept’ — i.e., an element or
combination of elements that is ‘sufficient to ensure that the
Appeal 2020-000801
Application 13/294,134

12
patent in practice amounts to significantly more than a patent
upon the [ineligible concept] itself.’
Alice, 134 S.Ct. at 2355 (citing from Mayo, 566 U.S. at 75–77).
Alice, relying on the analysis in Mayo of a claim directed to a law of
nature, stated that in the second part of the analysis, “the elements of each
claim both individually and ‘as an ordered combination’” must be
considered “to determine whether the additional elements ‘transform the
nature of the claim’ into a patent-eligible application.” Alice, 134 S.Ct. at
2355.
The PTO published guidance on the application of 35 U.S.C. § 101.
USPTO’s January 7, 2019 Memorandum, 2019 Revised Patent Subject
Matter Eligibility Guidance, 84 Fed. Reg. 50, 51–57 (2019) (“Eligibility
Guidance”). This guidance provides additional direction on how to
implement the two-part analysis of Mayo and Alice.
Step 2A, Prong One, of the 2019 Guidance, looks at the specific
limitations in the claim to determine whether the claim recites a judicial
exception to patent eligibility. In Step 2A, Prong Two, the claims are
examined to identify whether there are additional elements in the claims that
integrate the exception into a practical application, namely, is there a
“meaningful limit on the judicial exception, such that the claim is more than
a drafting effort designed to monopolize the judicial exception.” 84 Fed.
Reg. 54 (2. Prong Two).
If the claim recites a judicial exception that is not integrated into a
practical application, then as in the Mayo/Alice framework, Step 2B of the
Eligibility Guidance instructs us to determine whether there is a claimed
“inventive concept” to ensure that the claims define an invention that is
significantly more than the ineligible concept, itself. 84 Fed. Reg. 56.
Appeal 2020-000801
Application 13/294,134

13
With these guiding principles in mind, we proceed to determine
whether the claimed subject matter in this appeal is eligible for patent
protection under 35 U.S.C. § 101.

Discussion
Claim 1 is directed to a “method.” Following the first step of the
Mayo/Alice analysis, we find that the “method” claim is also a “process,”
and therefore falls into one of the broad statutory categories of patent-
eligible subject matter under 35 U.S.C. § 101. We thus proceed to Step 2A,
Prong One, of the Eligibility Guidance.

Step 2A, Prong One
In Step 2A, Prong One, of the Eligibility Guidance, the specific
limitations in the claim are examined to determine whether the claim recites
a judicial exception to patent eligibility, namely whether the claim recites an
abstract idea, law of nature, or natural phenomenon.
The Non-final Action was mailed Oct. 2, 2018, before the publication
of the Eligibility Guidance. The Examiner stated that “the claims are
directed to the abstract idea of protecting and processing financial data for a
transaction with the use of processing information through a clearinghouse
and a mathematical procedure for converting a data representation to
another.” Non-final Act. 5. In the Answer, mailed after the publication of
the Eligibility Guidance, the Examiner stated that the “claims are directed to
facilitating future transactions, i.e. managing human activity, and seems to
merely utilize encryption as a general environment applied to the managing
of human activity.” Ans. 3. The Examiner also characterized the “user key”
Appeal 2020-000801
Application 13/294,134

14
and “server key” as “merely forms of data that are not used in any other way
that would qualify them as any particular type of data, but instead act as
mere generic data.” Ans. 4. The Examiner also states that “the generation
of keys does not seem to be the intended purpose of the claims.” Id.
We do not agree with the Examiner’s dismissal of the encryption steps
as “mere generic data” and not the “intended purpose of the claims.” Ans. 4.
The encryption is used to encrypt the specific sensitive data and therefore is
not “mere generic data” as found by the Examiner. The encryption and
decryption steps are specific steps in the claim, and thus the Examiner’s
statement about them not being the intended purpose of the claim is not a
basis to ignore them.
We agree with the Examiner’s finding, however, that the claim is
directed to “managing human activity,” a category of abstract idea listed in
the Eligibility Guidance. Specifically, the claim receives a request in step
[1] for a mobile transaction, which can be a purchase using a credit card.
After carrying out several steps of encryption and decryption, the decrypted
sensitive data, which can be a credit card number, is transmitted in step [4c]
to a payment process for processing. The claim therefore recites steps of
“sales activities” (a “mobile transaction,” “payment processor for
processing” which is listed in the Eligibility Guidance the abstract idea of
“[c]ertain methods of organizing human activity”). Eligibility Guidance, 84
Fed. Reg. 52. See also note 13 listing “the concept of ‘local processing of
payments for remotely purchase goods’” as falling within the category of
“certain methods of managing human activity. Id.
Appeal 2020-000801
Application 13/294,134

15
Appellant states that “[h]uman activity cannot be encrypted.” Reply
Br. 2. Appellant further argues that the claims are not directed to organizing
human activity, but only arise in digital transactions. Id. at 3.
The claim, as acknowledged by Appellant, recites steps in which
purchase transactions are conducted. Reply Br. 3 (“Human-conducted
purchase transactions conducted in person . . . are not, however, capable of
encryption or capable of being encrypted by an encryption key”). The
Eligibility Guidance lists sales and payment processing as managing human
activity, which are reasonably understood to include the type of mobile
purchase transaction recited in claim 1. Eligibility Guidance, 84 Fed. Reg.
52. Thus, we do not find Appellant’s argument persuasive.
In sum, for the foregoing reasons, we find that claim 1 recites an
abstract idea. Accordingly, we proceed to Step 2A, Prong Two, of the
Eligibility Guidance.
Step 2A, Prong Two
Prong Two of Step 2A under the 2019 Eligibility Guidance asks
whether there are additional elements that integrate the exception into a
practical application. As in the Mayo/Alice framework, we must look at the
claim elements individually and “as an ordered combination” to determine
whether the additional elements integrate the recited abstract idea into a
practical application. The Eligibility Guidance explains that “[a] claim that
integrates a judicial exception into a practical application will apply, rely on,
or use the judicial exception in a manner that places a meaningful limit on
the judicial exception, such that the claim is more than a drafting effort
designed to monopolize the judicial exception.” Eligibility Guidance, 84
Fed. Reg. 54. Integration into a practical application is evaluated by
Appeal 2020-000801
Application 13/294,134

16
identifying whether there are additional elements individually, and in
combination, which go beyond the judicial exception. Eligibility Guidance,
84 Fed. Reg. 54–55.
The PEG Update explains that “first the specification should be
evaluated to determine if the disclosure provides sufficient details such that
one of ordinary skill in the art would recognize the claimed invention as
providing an improvement.” Update to Subject Matter Eligibility 12.3
We begin with the Specification. The Specification explains that in
prior art systems, “records were compromised from servers and applications
when hackers attack centralized database.” Spec. ¶ 7. The Specification
further explains that although “[m]any merchants have implemented data
encryption systems to protect stored credit card data,” these encryption
systems are still vulnerable, because “storage of the credit card data exposes
the merchant and incentivizes hackers with the prospect of access to tens of
thousands of stored credit card records.” Id. To address this problem, the
Specification describes using both a server key stored at the server and a
“user-selected key,” such as a PIN number, to generate an encryption key at
a gateway sever to encrypt the credit card number. Spec. ¶ 9. “The server
subsequently discards the user key, which is also not stored on the mobile
device.” Id. The server sends the encrypted credit card back to the mobile
device. Spec. ¶ 10. “The encrypted credit card cannot be decrypted [at the
gateway server] without the user entering the user key again to verify their
identity and order” in addition to the gateway server employing the server

3 Available at
https://www.uspto.gov/sites/default/files/documents/peg_oct_2019_update.p
df (last accessed Jun. 9, 2020) (“PEG Update”).

Appeal 2020-000801
Application 13/294,134

17
key. Spec. ¶¶ 9–10. Therefore, subsequent orders from the mobile device
can be accomplished using the encrypted credit card and the user key
without having to transmit the actual card number and with the security that
the credit card information can only be decrypted in conjunction with a user
key that is not stored on the device and which must be entered by the user to
verify the order. Spec. ¶ 10. “Once the credit card information is securely
stored on the mobile device, it enables the customer to order repeatedly from
the same merchant or place one-off orders from different merchants without
having to re-enter the credit card information.” Spec. ¶ 36. The
Specification explains how using credit card information encrypted with a
user key in recurring purchases protects the credit card information from
attackers. Spec. ¶ 41.
Claim 1, consistent with the Specification, generates an encryption
key based on both the server key stored at the gateway server and the
received user key at the gateway server (step [2a]) but does not store this
user key on the mobile device or the gateway server. The sensitive data
(e.g., credit card information) is encrypted at the server using the encryption
key (step [2b]) and the encrypted data is sent back to the mobile device (step
[2c]). In subsequent transactions, the user employs the encrypted data and
user key (steps [2c],[3], which can only be decrypted by the gateway server
using the stored server key and the user key which user key is not
maintained at either location for attackers to gain access.
As explained by Appellant, the claims avoid the “failings” in the prior
art by providing “for individualized encryption/decryption keys that are
generated by combining a server key stored only at the gateway server with
Appeal 2020-000801
Application 13/294,134

18
a user key (e.g., a PIN) that is never maintained . . . by any device.” Appeal
Br. 10. Appellant further states:
Rather than relying on prior art requirements of repeated user
registration and (insecure) credit card storage at the server, the
claimed individualized encryption/decryption system
incorporates a user-specific element . . . sent from but never
maintained at the mobile device that is combined with a server
key that is stored at the server only, thereby providing users with
the opportunity to purchase products securely without actually
having to register with the specific merchant's system or risk the
merchant system storing their sensitive data.
Id.
The Examiner replies to Appellant’s argument:
None of these supposed improvements align with applicant’s
supposed “improvement upon conventional encryption”,
furthermore none of the supposed improvements are reliant upon
any form of encryption. Therefore it is apparent that the
encryption of the claims merely act as a generic encryption
environment added to the claims without meaningfully adding to
the abstract idea of managing human activity by facilitating
future transactions. It is further noted that allowing purchases
without registration with each individual merchant, is what
occurs in everyday purchase transactions with both normal
account identifiers and encrypted identifier/tokens. Therefore,
even if appellant’s assertion that “user key” and “server key” data
is to be taken as specific data were to be accepted, such a
designation would do little to materially contribute the alleged
improvements.
Ans. 4.
As explained above, the claimed improvements are in using a user key
in combination with a server key to encrypt sensitive data, where the user
key is not maintained on the mobile device or the gateway server, and then
sending the encrypted data back to the mobile device where it may be used
to carry out additional purchases. The Examiner did not establish that these
Appeal 2020-000801
Application 13/294,134

19
steps recited in the claim are a “generic encryption environment” that do not
serve as a material improvement to the method of accomplishing “recurring
mobile transactions.” The steps asserted to embody the improvement to the
payment system are not abstract ideas, themselves, but constitute additional
elements which provide a technological improvement to electronic payment
transactions by making them more secure and providing merchant
verification. Accordingly, we conclude that the judicial exception recited in
claim 1 is integrated into a practical application and therefore the claim is
patent eligible under 35 U.S.C. § 101. The rejection of claim 2–6, 8–13, 15–
20, and 25–30 is reversed for the same reasons.

CONCLUSION
In summary:
Claims
Rejected
35 U.S.C.
§
Reference(s)/Basis Affirmed Reversed
1, 2, 8, 9,
15, 16, 20,
25–29
103 Tieken, Fukaya,
Youn
1, 2, 8, 9,
15, 16, 20,
25–29
3, 10 103 Tieken, Fukaya,
Youn, Blackhurst
3, 10
4, 11 103 Tieken, Fukaya,
Youn, Flitcroft
4, 11
5, 12, 30 103 Tieken, Fukaya,
Youn, Flitcroft,
Hoerenz
5, 12, 30
6, 13 103 Tieken, Fukaya,
Youn, Flitcroft,
Hoerenz, Harris
6, 13
17, 18 103 Tieken, Fukaya,
Youn, Bickerstaff
17, 18
19 103 Tieken, Fukaya,
Youn, Bickerstaff,
and Zandonadi
19
Appeal 2020-000801
Application 13/294,134

20
1–6, 8-13,
15–20, 25–
30
101 1–6, 8–13,
15–20, 25–
30
Overall
Outcome
1–6, 8–13,
15–20, and
25–30

REVERSED