Apple Inc.

Patent Trials and Appeals Board

Feb 8, 2021

2020005817 (P.T.A.B. Feb. 8, 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.
14/474,787 09/02/2014 Yousuf H. Vaid 5607.2040001
(P21734US1)
7814
63975 7590 02/08/2021
STERNE, KESSLER, GOLDSTEIN & FOX P.L.L.C.
1100 NEW YORK AVENUE, N.W.
WASHINGTON, DC 20005
EXAMINER
SAX, TIMOTHY P
ART UNIT PAPER NUMBER
3685
NOTIFICATION DATE DELIVERY MODE
02/08/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):
Apple-eOA@sternekessler.com
e-office@sternekessler.com
PTOL-90A (Rev. 04/07)
UNITED STATES PATENT AND TRADEMARK OFFICE
____________

BEFORE THE PATENT TRIAL AND APPEAL BOARD
____________

Ex parte YOUSUF H. VAID, GEORGE R. DICKER, AHMER A. KHAN,
CHRISTOPHER B. SHARP, GLEN W. STEELE,
CHRISTOPHER D. ADAMS, and DAVID T. HAGGERTY
____________

Appeal 2020–005817
Application 14/474,787
Technology Center 3600
____________

Before ANTON W. FETTING, MICHAEL C. ASTORINO, and
JAMES P. CALVE, Administrative Patent Judges.

FETTING, Administrative Patent Judge.

DECISION ON APPEAL

STATEMENT OF THE CASE1
Yousuf H. Vaid, George R. Dicker, Ahmer A. Khan, Christopher B.
Sharp, Glen W. Steele, Christopher D. Adams, and David T. Haggerty

1 Our decision will make reference to the Appellant’s Appeal Brief (“Appeal
Br.,” filed March 10, 2020) and Reply Brief (“Reply Br.,” filed August 10,
Appeal 2020-005817
Application 14/474,787

2

(Appellant2) seeks review under 35 U.S.C. § 134 of a final rejection of
claims 1–10, 21, 23, 24 ,26, 28, and 30–37, the only claims pending in the
application on appeal. We have jurisdiction over the appeal pursuant to
35 U.S.C. § 6(b).
We REVERSE.
The Appellant invented a way of generating identifiers and receipts
related to financial transactions conducted by electronic devices via wireless
communication. Spec., para. 3.
An understanding of the invention can be derived from a reading of
exemplary claim 1, which is reproduced below (bracketed matter and some
paragraphing added).
1. An electronic device, comprising:
[1] an antenna;
[2] an interface circuit coupled to the antenna and configured to
communicate with an other [sic, another] electronic device;
and
[3] a secure element coupled to the interface circuit and
configured to:3
[4] generate a dynamic card verification value (DCVV) for a
financial transaction based at least in part on
an account number identifier that indirectly specifies a
financial account,

2020), and the Examiner’s Answer (“Ans.,” mailed June 10, 2020), and
Final Action (“Final Act.,” mailed October 11, 2019).
2 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 Apple, Inc.
(Appeal Br. 3).

3 Encompasses limitations 4–10.
Appeal 2020-005817
Application 14/474,787

3

a truncated counter value representing a number of
transactions conducted by the electronic device, and
a random number;
[5] generate financial-account information comprising
the account number identifier,
the truncated counter value, and
the DCVV;
[6] determine a first transaction identifier that uniquely identifies
the financial transaction based at least in part on the financial-
account information;
[7] conduct the financial transaction with the other electronic
device by transmitting, using the interface circuit, the financial-
account information to the other electronic device;
[8] receive, from a computer system operated for a third party, a
notification associated with the financial transaction,
wherein the computer system operated for the third party
is independent of a counterparty in the financial
transaction associated with the other electronic device;
[9] receive, from the computer system operated for the third
party, receipt information associated with the financial
transaction,
wherein the receipt information comprises a second
transaction identifier that uniquely identifies the financial
transaction,
wherein the second transaction identifier is computed
based at least in part on the financial-account information
transmitted to the other electronic device;
and
[10] associate the receipt information with the financial
transaction based at least in part on the first transaction
identifier and the second transaction identifier.
Appeal 2020-005817
Application 14/474,787

4

The Examiner relies upon the following prior art:
Name Reference Date
Bowman US 6,460,163 B1 Oct. 1, 2002
Biere US 7,742,762 B1 June 22, 2010
Pastusiak US 2006/0129502 A1 June 15, 2006
Dua US 2006/0165060 A1 July 27, 2006
Hammad US 2008/0040276 A1 Feb. 14, 2008
Wentker US 2008/0167017 A1 July 10, 2008
Ronda US 2011/0265159 A1 Oct. 27, 2011
Claims 1, 3–10, 21, 23, 24, 26, 28, and 34–37 stand rejected under 35
U.S.C. § 103(a) as unpatentable over Wentker, Hammad, Dua, and
Bowman.4
Claim 2 stands rejected under 35 U.S.C. § 103(a) as unpatentable over
Wentker, Hammad, Dua, Bowman, and Biere.
Claim 30 stands rejected under 35 U.S.C. § 103(a) as unpatentable
over Wentker, Hammad, Dua, Bowman, and Ronda.
Claims 31–33 stand rejected under 35 U.S.C. § 103(a) as unpatentable
over Wentker, Hammad, Dua, Bowman, and Pastusiak.
ISSUES
The issues of obviousness turn primarily on whether all of the claim
limitations deserve patentable weight and whether all limitations deserving
such weight are described by the art.

4 Claim 23 is omitted from the lead paragraph (Final Action 4), but is
included in the analysis (Final Action 9).
Appeal 2020-005817
Application 14/474,787

5

FACTS PERTINENT TO THE ISSUES
The following enumerated Findings of Fact (FF) are believed to be
supported by a preponderance of the evidence.
Facts Related to Appellant’s Disclosure
01. The financial-account information may correspond to or be
equivalent to magnetic-stripe data on a credit card. Financial-
account information includes data, such as: a token associated
with a financial-account identifier, a card-holder-name field, an
expiration date of the financial account specified by the financial-
account identifier, a numerical value corresponding to a number of
financial transactions conducted by electronic device, a dynamic
card verification value (DCVV) for the financial transaction,
and/or additional data. Spec., para. 36.
02. If the financial account is a credit-card account, the token may be
a device primary account number (DPAN) instead of the financial
primary account number (FPAN) or credit-card number, where the
DPAN may be thought of as a 'virtual' credit card number that
corresponds/maps to a 'real' FPAN. In addition, the financial-
account information may include a truncated counter value (such
as the least-significant three bits, four bits or five bits of a two-
byte counter value) combined with the dynamic card verification
value. Note that the dynamic card verification value may be
dynamically generated by the secure element in electronic device
for each financial transaction using a cryptographic technique
using the DPAN, the counter value, one or more cryptographic
keys and a random number provided by electronic device during
Appeal 2020-005817
Application 14/474,787

6

the wireless communication. Consequently, a different dynamic
card verification value may be generated for each financial
transaction. Spec., para. 37.
03. The process encrypts and/or decrypts authentication information
communicated with authentication subsystem, and encrypts and/or
decrypts information (such as tokens) communicated with secure
subsystem. The process compares authentication information with
stored authentication. Spec., para. 51.
04. The Specification contains no other reference to the dynamic
card verification value, and in particular, describes no functional
use of the value or the data representing the value other than as a
conventional authentication value after it is generated, encrypted,
and decrypted. The Specification describes no functional effect of
the DPAN or the counter value upon the dynamic card verification
value’s use as a conventional authentication value or on any other
functional effect upon the process.
Facts Related to the Prior Art
Wentker
05. Wentker is directed to improved consumer mobile phone
payment systems and methods. Wentker, para. 8.
06. Wentker describes a mobile phone, which can include mobile
phone components such as an NFC communications element, a
secure element comprising a payment application, and resident
applications including one or more mobile applications and one or
more download managers. Wentker, para. 37.
Appeal 2020-005817
Application 14/474,787

7

Hammad
07. Hammad is directed to improved consumer and portable
consumer device authentication and authenticating a portable
consumer device such as a payment card and a consumer using the
portable consumer device, performing back end processing, and
providing consumer notification of purchase transactions.
Hammad, para. 5.
08. Hammad describes Dynamic CVV ("dCVV") as the generation
of a verification value using information including a PAN
(primary account number), an expiration date, a service code, and
an automatic transaction counter. This verification value is
transmitted from a merchant to a service provider (e.g., a payment
processing organization or an issuer) where it is decoded and
evaluated for possible approval. The automatic transaction
counter keeps track of the number of times that a portable
consumer device is used, and if there is a mismatch between a
counter value that is received at the issuer and the counter at the
issuer, then this may indicate possible data skimming or
fraudulent use. Hammad, para. 68.
09. Hammad describes improving upon prior dCVV processes by
generating different dynamic verification values using different
data or different types of variable information. For example, more
transaction and/or user specific data could be dynamically
changed to verify that the portable consumer device is the correct
one. This would be more secure than using just a simple counter.
For example, specific information could include the following:
Appeal 2020-005817
Application 14/474,787

8

terminal ID, time of day, telephone number, SIM card number,
transaction amount, account number, service code (two digits),
expiration date, current date, random numbers from the terminal,
etc. The specific information preferably includes at least one
dynamic data element such as a counter, time of day, purchase
amount, etc. In other embodiments, the specific information used
to create the dynamic verification value includes dynamic,
consumer specific or transaction specific information such as the
time of day when the transaction is taking place, the purchase
amount, prior transaction data, etc. Any, some, or all of these may
be used to create a verification value or other specific pieces of
information could be dynamically altered to create a new dCVV.
In one specific example, data regarding a prior transaction (e.g., a
prior purchase amount, the time of a prior purchase, etc.) may be a
dynamic data element, which may be used to authenticate a
portable consumer device for future transactions. Hammad, para.
72.
10. Hammad describes data that is transmitted from a merchant to an
issuer in a purchase transaction. The data fields include PAN,
expiration date, service code, PIN CVV, and discretionary data
fields. Hammad, para. 95.
Dua
11. Dua is directed to conducting electronic commerce and more
particularly to systems and methodologies for issuing, managing,
storing and using credentials authorizing the legitimate holder of
such a credential to accomplish a desired result. Dua, para. 2.
Appeal 2020-005817
Application 14/474,787

9

12. Dua describes a wallet application that will log all transactions
made in proximity, personal, or remote mode. The log will
display information such as date/time, name of retailer/
organization, location ID, list of credentials used in the
transaction, and purchase price (if transaction had a financial
component). The purpose of this log is to allow a user to see what
credential and personal information was shared with a third-party.
User's need to be able to verify sometimes what personal
information may have been shared during a specific transaction.
This viewer allows the user to go back and view up to 6 months of
transactions. In the case of financial transactions, the log entries
will also have links to digital receipts (which are stored separately
in the wallet application). Digital Receipts will be linked to log
entries based on date/time stamp and credential matches (other
criteria could also be used--for example, under one embodiment,
the device generates a unique transaction ID which is transmitted
with the credential to the merchant during each transaction. This
ID could be contained in the digital receipt, and used by the wallet
application to link the digital receipt with the log entries). Dua,
para. 489.
Bowman
13.Bowman is directed to selling of digital content over a computer
network, and more particularly to a system which ensures more
reliable delivery of digital content via a computer network.
Bowman 1:25–27.
Appeal 2020-005817
Application 14/474,787

10

14. Bowman describes transporting a digital content item between an
order fulfillment server and a client computer by accepting a
digital receipt from a user, presenting a choice of digital content
for which the digital receipt is valid, accepting a request for a
digital content item from the user, computing a first checksum of
the digital content item at the order fulfillment server, transmitting
the digital content item from the order fulfillment server to the
client computer using a protocol capable or recovering from
communication errors without the need to retransmit the entire
digital content item, computing a second checksum of the digital
content item at the client computer, and comparing the first
checksum to the second checksum. Bowman 2:63–3:8.
15. Bowman describes the user selecting a specific digital content
item, the digital content item is downloaded, a checksum of at
least a portion of the digital content item used as a designated test
portion and preferably of the entire digital content item is
calculated at the client. A checksum of the file generated on the
order fulfillment server is compared to the checksum computed in
block 419 on the client computer. This important step verifies that
digital content item which has been paid for by the use, has been
received intact. Either the checksum generated on the client can
be sent to the server which will perform the comparison or vice
versa. A message digest algorithm such as MD5 offers almost
complete assurance that the file received is perfectly correct.
Bowman 8:29–58.
Appeal 2020-005817
Application 14/474,787

11

ANALYSIS
Claims 1, 3–10, 21, 23, 24, 26, 28, and 34–37 rejected under 35 U.S.C. §
103(a) as unpatentable over Wentker, Hammad, Dua, and Bowman
We agree with Examiner that the recited combination of an account
number identifier that indirectly specifies a financial account, a truncated
counter value representing a number of transactions conducted by the
electronic device, and a random number
is non-functional descriptive material that is simply describing
the data that is being used to generate the dynamic card
verification value. As long as three different data values are used
to generate the DCVV then that will read on this claim limitation
because the claim does not provide any specifics on how the
DCVV is generated based on the data. What those three different
data values are named does not affect the generation of the
DCVV.
Ans. 5.
While data per se applied to some computer process causes a
functional effect on the computer and process, that data per se is an arbitrary
pattern of bits based on unrecited encoding protocols and unrecited
generating steps and structure. Informing one how to mentally interpret or
label that bit pattern (what the Examiner refers to as what those three
different data values are named) is itself of no functional consequence. The
data label is not a limitation that can distinguish the claim from the art. The
patentability issue devolves to whether the prior art describes the recited
structure or function irrespective of how one labels the data.
Our reviewing court has held that nonfunctional descriptive material
cannot lend patentability to an invention that would have otherwise been
anticipated by the prior art. In re Ngai, 367 F.3d 1336, 1339 (Fed. Cir.
Appeal 2020-005817
Application 14/474,787

12

2004). Cf. In re Gulack, 703 F.2d 1381, 1385 (Fed. Cir. 1983) (noting that
when descriptive material is not functionally related to the substrate, the
descriptive material will not distinguish the invention from the prior art in
terms of patentability). King Pharm., Inc. v. Eon Labs, Inc., 616 F.3d 1267,
1279 (Fed. Cir. 2010) (“[T]he relevant question is whether ‘there exists any
new and unobvious functional relationship between the printed matter and
the substrate.’”) (citations omitted).
The rationale behind this lack of patentable weight is preventing the
repeated patenting of essentially a known product by the mere inclusion of
novel non-functional descriptive material. King Pharm., Inc, 616 F.3d at
1279) (“The rationale behind this line of cases is preventing the indefinite
patenting of known products by the simple inclusion of novel, yet
functionally unrelated limitations.”) Cf. In re Ngai, 367 F.3d 1336, 1339
(Fed. Cir. 2004) (“If we were to adopt Ngai’s position, anyone could
continue patenting a product indefinitely provided that they add a new
instruction sheet to the product.”).
Here the process in no way depends on the actual mental
interpretation of the account number identifier, truncated counter value, and
random number, and the mental interpretation of such data is not dependent
on the process. Were the recited data labels within data criteria to be given
weight, an Applicant could obtain patents on the existing Hammad prior art
described dynamic card verification value by simply applying differently
labelled non-functional data.
We are, however, persuaded by Appellant’s argument that “Bowman
does not teach or suggest a second transaction identifier [that uniquely
identifies the financial transaction] computed based on financial-account
Appeal 2020-005817
Application 14/474,787

13

information transmitted to another electronic device.” Appeal Br. 12; Reply
Br. 10. The Examiner responds that
[t]he limitation as a whole recites “receive, from the computer
system operated for the third party, receipt information
associated with the financial transaction, wherein the receipt
information comprises a second transaction identifier that
uniquely identifies the financial transaction, wherein the second
transaction identifier is computed based at least in part on the
financial- account information transmitted to the other electronic
device”. The claims are directed to the electronic device that
receives receipt information from the third party computer
system. The second transaction identifier is not computed by this
electronic device and instead is generated by a separate device
that is outside the scope of the claims. How the second
transaction identifier is computed does not affect the limitations
directed to the electronic device of the claims. Even assuming
that this limitation should be given patentable weight, Bowman
in Column 8, Ln 29 - Column 9, Ln 4 discloses that a checksum
is generated by a server based on a digital content item and a
checksum is generated by a client device based on the same
digital content item. Therefore these checksums are generated by
two separate entities using the same data and are then compared
to make sure they match. Even though the data that is being
generated in Bowman is a checksum generated using a digital
content item and the data being generated in the pending
application is a transaction identifier using transaction data, the
checksums of Bowman are generated the same way as the
transaction identifiers in this pending application.
Ans. 6–7. The problem for the Examiner is that a checksum is far from
unique. Instead, its relationship to the content from which it is derived is
such that it is improbable that a different content would produce the same
value, although this is possible. Rather than uniquely identifying content, it
shows a high probability that the content is unaltered. The Examiner does
Appeal 2020-005817
Application 14/474,787

14

not determine why one of ordinary skill would have substituted a unique
identifier for Bowman’s checksum.
The remaining claims depend from claim 1 or similar claim 21.
Claim 2 rejected under 35 U.S.C. § 103(a) as unpatentable over Wentker,
Hammad, Dua, Bowman, and Biere
This claim depends from claim 1.
Claim 30 rejected under 35 U.S.C. § 103(a) as unpatentable over Wentker,
Hammad, Dua, Bowman, and Ronda
This claim depends from claim 1.
Claims 31–33 rejected under 35 U.S.C. § 103(a) as unpatentable over
Wentker, Hammad, Dua, Bowman, and Pastusiak
These claims depend from claims 1 and 21.

CONCLUSIONS OF LAW
The rejection of claims 1, 3–10, 21, 23, 24, 26, 28, and 34–37 under
35 U.S.C. § 103(a) as unpatentable over Wentker, Hammad, Dua, and
Bowman is improper.
The rejection of claim 2 under 35 U.S.C. § 103(a) as unpatentable
over Wentker, Hammad, Dua, Bowman, and Biere is improper.
The rejection of claim 30 under 35 U.S.C. § 103(a) as unpatentable
over Wentker, Hammad, Dua, Bowman, and Ronda is improper.
The rejection of claims 31–33 under 35 U.S.C. § 103(a) as
unpatentable over Wentker, Hammad, Dua, Bowman, and Pastusiak is
improper.
Appeal 2020-005817
Application 14/474,787

15

CONCLUSION
The rejection of claims 1–10, 21, 23, 24, 26, 28, and 30–37 is
reversed.
In summary:
Claims
Rejected
35 U.S.C.
§
Reference(s)/Basis Affirmed Reversed
1, 3–10, 21,
23, 24, 26,
28, 34–37
103 Wentker.
Hammad, Dua,
Bowman
1, 3–10, 21,
23, 24, 26,
28, 34–37
2 103 Wentker.
Hammad, Dua,
Bowman, Biere
2
30 103 Wentker.
Hammad, Dua,
Bowman, Ronda
30
31–33 103 Wentker.
Hammad, Dua,
Bowman,
Pastusiak
31–33
Overall Outcome 1–10, 21, 23,
24, 26, 28,
30–37

REVERSED