Fisher, Michelle

Patent Trials and Appeals Board

Oct 30, 2020

12592581 - (R) (P.T.A.B. Oct. 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.
12/592,581 11/25/2009 Michelle Fisher 379842-991160 2986
12120 7590 10/30/2020
Michelle Fisher
2930 Domingo Ave
Suite 123
Berkeley, CA 94705
EXAMINER
KELLEY, STEVEN SHAUN
ART UNIT PAPER NUMBER
2646
NOTIFICATION DATE DELIVERY MODE
10/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):
mfisher@blazemobile.com
PTOL-90A (Rev. 04/07)
UNITED STATES PATENT AND TRADEMARK OFFICE
BEFORE THE PATENT TRIAL AND APPEAL BOARD
Ex parte MICHELLE FISHER

Appeal 2019-003563
Application 12/592,581
Technology Center 2600
Before ERIC B. CHEN, CARL L. SILVERMAN, and
MICHAEL J. ENGLE, Administrative Patent Judges.

SILVERMAN, Administrative Patent Judge.
DECISION ON REQUEST FOR REHEARING

STATEMENT OF THE CASE
Appellant requests Rehearing of the July 23, 2020 Decision on Appeal
No. 2019-003563 (“Decision”) affirming the Examiner’s rejection of claims
86, 88, 89, 95, 96, 98, 99, and 105–123 under 35 U.S.C. § 103. We have
jurisdiction under 35 U.S.C. § 6(b). Requests for Rehearing are limited to
matters misapprehended or overlooked by the Board in rendering the
original decision. 37 C.F.R. § 41.52.
Appeal 2019-003563
Application 12/592,581

2
We have reconsidered the Decision in light of Appellant’s arguments
in the Request for Rehearing filed August 16, 2020 (“Request”). For the
reasons given below, we grant the request to modify our Decision.
BACKGROUND
The invention relates to conducting a Near Field Communication
(NFC) transaction using an NFC protocol and a mobile wireless device.
Abstract; Spec.1 ¶¶ 2, 3, 10, 13, 14; Figs. 1, 3A–3C.
Claim 86, reproduced below, is representative2 of the claimed subject
matter (emphases added):
86. A method for conducting a Near Field
Communication (NFC) transaction using an NFC protocol, the
method comprising:
maintaining an identification code associated with a user
and a secure element application configured to use the NFC
protocol in a secure element memory, the secure element
memory, a secure element processor and a secure element
transceiver supporting a first communication channel
comprising the NFC protocol included in a secure element
embedded within the body of a mobile device, the mobile
device comprising of a mobile device memory, a mobile device
processor, and a mobile device wireless transceiver;
executing the secure element application in response to a
near field communication inductive signal by an NFC terminal;

1 Specification, filed 11/25/2009 (“Spec.” or “Specification”). As discussed,
infra, there are several related specifications and there has been some
confusion regarding Appellant’s citations to related specifications. For
purposes of this Rehearing, we refer to the Specification, filed 11/25/2009
(“Spec.” or “Specification”).
2 Appellant’s arguments are directed toward independent claims 86 and 96.
See Appeal Br. 44–45 (the reference to claim 1 appears to be harmless
error). We select claim 86 as representative and the remaining other claims
stand or fall with claim 86. See 37 C.F.R. § 41.37(c)(1)(iv).
Appeal 2019-003563
Application 12/592,581

3
wirelessly transmitting, using the secure element
application, a transaction request including the identification
code associated with the user via the secure element transceiver
over a first communication channel to the NFC terminal in
response to the near field communication inductive signal by
the NFC terminal, wherein the transaction request including the
identification code associated with the user is transmitted over
a second communication channel that is different than the first
communication channel to a server for processing the NFC
transaction using a payment method stored at the server that
corresponds to the identification code associated with the user,
wherein the NFC terminal and the first communication channel
is configured to use the NFC protocol; and
after a payment has been processed by the server,
receiving a transaction response at the mobile application from
the server over the second communication channel.

Appeal Br. 46 (Claim Appendix).
REFERENCES
Prior art relied upon by the Examiner:
Name Reference Date
Rosenberg US 2004/0235450 Al Nov. 25, 2004
Park US 2005/0143051 Al June 30, 2005
Hagale et al. US 2006/0253389 Al Nov. 9, 2006
Yeager US 2007/0075133 Al Apr. 5, 2007
Nystrom et al. US 2009/0075592 Al Mar. 19, 2009

REJECTIONS
Claims 86, 88, 89, 95, 96, 98, 99, 105–108, 112–114, and 118–123 are
rejected under 35 U.S.C. § 103(a) as being unpatentable over Rosenberg,
Nystrom, and Yeager. Final Act. 2–11.
Claims 109 and 115 are rejected under 35 U.S.C. § 103(a) as being
unpatentable over Rosenberg, Nystrom, Yeager, and Park. Final Act. 8.
Appeal 2019-003563
Application 12/592,581

4
Claims 110, 111, 116, and 117 are rejected under 35 U.S.C. § 103(a)
as being unpatentable over Rosenberg, Nystrom, Yeager, and Hagale. Final
Act. 9–10.
BACKGROUND
In the Request, Appellant argues, inter alia, the Examiner and the
Board err in applying an unreasonably broad claim interpretation to find the
combination of Rosenberg, Nystrom, and Yeager teaches the following
claim 86 limitations:
(1) “maintaining an identification code associated with a
user and a secure element application configured to use the
NFC protocol in a secure element memory” and
(2) “wherein the transaction request including the
identification code associated with the user is transmitted over
a second communication channel that is different than the first
communication channel to a server for processing the NFC
transaction using a payment method stored at the server that
corresponds to the identification code associated with the
user.”

Id. (also referred to as “disputed limitations (1) and (2)”; designations (1)
and (2) and emphasis added). See Request items 1–6.
In the Final Action, the Examiner finds Rosenberg and Nystrom each
teaches disputed limitation (1). Final Act. 2–3 (citing Rosenberg ¶¶ 42–56;
Figs. 1, 2, 4–6, 8; Nystrom ¶¶ 127–133, 136–139; Figs. 7, 9). The Examiner
finds Rosenberg and Nystrom each teaches using the secure element for POS
transactions. Id. (citing Rosenberg ¶¶ 5, 6, 43, 45, 57–60; Nystrom ¶¶ 6, 7,
42). Regarding the “identification code associated with a user,” although the
Examiner finds Rosenberg teaches “sending an account number, which is the
‘identification code’ of the account and the account number would be
Appeal 2019-003563
Application 12/592,581

5
associated with a user,” the Examiner additionally cites Yeager. Id. at 4
(citing Rosenberg ¶¶ 6, 57). The Examiner finds Yeager teaches
“transmitting the account number 626 (which is the ‘identification code of
the account associated with the user’[] and is programmed into the
attachable adapter 100) during the POS transaction using NFC.” Id. at 4–5
(citing Yeager ¶¶ 21–23, 29, 31–36; Fig. 2).
The Examiner finds Rosenberg teaches disputed limitation (2). Id. at
3 (citing Rosenberg ¶¶ 6, 40, 52, 53). In particular, Rosenberg teaches
transmitting the account number from the secure element for the NFC
transactions. Id.
Appellant argues a prior Board Decision3 (also referred to as “Prior
Decision” and “Prior Dec.”) decided by a different panel corroborates many
of its arguments in this case. See, e.g., Appeal Br. 10, 12, 23, 24. Appellant
argues Rosenberg teaches a bank account or credit card number is stored on
the smart link module and refers to the Prior Decision determination that
“[t]he Examiner finds, and we agree, Figure 5 of Rosenberg is directed to a
method of transmitting payment information from a smartlink module to a
POS terminal.” Id. at 10 (quoting Prior Dec. 11). Appellant additionally
argues:
Rosenberg also positively recites that the identification
code stored in the smartlink module (Examiner alleges is “secure
element”) is the identifying information of the mobile device
such as the ESN or manufacturer serial number in paragraph
54 and is used to “mate” or authenticate the mobile device to
the smart/ink module (Examiner alleges is “secure element”)
in paragraph 56. Stated another way, the identification code does
not correspond to a payment method much less used in the

3 Appeal 2015-004293, Application 12/592,581.
Appeal 2019-003563
Application 12/592,581

6
NFC payment transaction to process a payment using a
payment method that corresponds to the identification code of
a user. This distinction is important since if the mobile device is
sold or given to someone else, the user changes, but the ESN or
serial number (Examiner alleges is “identification code
associated with the user”) which is associated with the mobile
device stays the same. In contrast, Applicant teaches that the
payment method is stored at the server and an identification
code associated with the user is transmitted from the secure
element to the server as reflected by amended independent
claims recite in part, “a payment method stored at the server[.]”

Id. at 11.
Appellant argues Nystrom, like Rosenberg, stores credit information
in the secure smart module, not at the server. Id. at 12–13 (citing Nystrom
¶ 5). Appellant argues this is corroborated by the Prior Decision: “The
Examiner finds, and we agree, Nystrom teaches ‘an identification of a
credit card provider is transmitted to the POS.’ (Ans. 4–5 (citing Nystrom ¶
142)).” Id. at 12. Appellant also argues the Prior Decision notes that
Nystrom transfers payment credentials and Rosenberg teaches the
transmission of payment credentials. Id.
Appellant argues the Yeager public account/key does not correspond
to a payment method, and the key is not used in processing a payment using
a payment method that corresponds to the public account/key 626. Id. at 16.
Appellant argues “the identification code is not interchangeable with a
payment method (i.e., credit card number).” Id. at 38; see also, e.g., id. at
27–30.
In the Answer, the Examiner finds Rosenberg teaches transmitting an
account number (“identification code . . . ”) to the server, and this would
indicate that the payment method associated with the account number is
Appeal 2019-003563
Application 12/592,581

7
stored at the server. Ans. 3 (citing Rosenberg ¶¶ 6, 52). The Examiner
additionally cites Yeager for teaching storing different payment methods at
servers where the type of payment is determined by the transmitted user
account number. Id. (citing Yeager, Figs. 4–7).
The Examiner finds that a credit card type of payment may be
interpreted as the recited “method of payment.” Id. at 4. In particular:
The Examiner sets forth that Yeager’s teachings of storing
the account number in the secure element (see section [0031]),
which is then transmitted to the backend financial servers during
the POS transaction, would require and/or may be interpreted to
mean that the backend servers store the payment method. By
storing an account number or credit card number at a server (see
Fig. 5 of Yeager), the server would then implicitly store the
method of payment as “credit card payment method”. In essence,
using a credit card account is a “credit card payment method”.

Id.
In the Reply Brief, Appellant reiterates arguments and argues that the
Application describes two distinct methods (“scenarios”) of processing and
NFC transaction:
The first embodiment teaches storing payment credentials
or payment methods in the secure element and transmitting them
to the POS terminal which transmits them to a server for
processing. Support can be found, for example, in Figure 3A and
3B4. A second embodiment reflected in the Instant Application
teaches storing an identification code associated with the user in
the secure element and transmitting it to the POS terminal which
transmits it to a server that processes the transaction using a

4 Regarding “support” for the first embodiment, we note Spec., ¶ 41 states
“Figs. 3A-3D illustrate a flowchart of the present invention, and the various
steps that are included in a particular transaction, with reference to which of
various devices are implementing this step. As the flowchart is self-
explanatory, a further discussion is not provided herein.”
Appeal 2019-003563
Application 12/592,581

8
payment method that corresponds to the identification code
associated with the user. Support can be found, for example, in
the Specification in paragraph 37, “If the point of sale terminal
reader 152 includes the provision for NFC communications, then
simply bringing the secure element 130 with the NFC transceiver
will cause initiation of a transaction and the transmission of the
identification code associated with the secure element 130 and
thus the user[]” and paragraph 40, “As such, the management
server 180 can store user personal and credit and transactional
information and history, including a code associated with the
user, for a variety of different mobile devices, thereby allowing
a system which can scale.”

Reply Br. 14–15.
In our Decision, we affirmed the Examiner’s interpretations of the
claims as broad but reasonable given the record before us. See Dec. 10–12.
ANALYSIS
In the Request for Rehearing, Appellant argues, inter alia ,“the
Board’s interpretation of ‘identification code’ rendered the term
indistinguishable from ‘payment method’ which is used in the specification
to denote a credit card, debit card, or cash card that is stored at the server for
processing a payment corresponding to the identification code.” Req. 3
(emphasis omitted). According to Appellant:
[P]er the Applicant's Specification, the plain meaning of
Applicant’s use of “identification code associated with the
user” corresponds to a payment method stored at the server and
differs significantly from the credit card number/bank account
number stored in the secure element used in Rosenberg,
Nystrom, and Yeager. Thus, it is respectively submitted that the
Board's interpretation is not compatible with the present
specification and, therefore, is a misapplication of MPEP
§ 2111.

Appeal 2019-003563
Application 12/592,581

9
Req. 4.5
Appellant then refers to portions of the Specification:
As stated in the Specification support for identification
code can be found, for example, in paragraph 336, “Fig. 2B1
illustrates a preferred embodiment of the secure element 130
associated with the mobile device 110, the secure element 130
being commonly known as a smart card. As illustrated, the
secure element 130 has a secure processor 132, a secure memory
133 and a POS transceiver 134 adapted to send transaction
request signals and receive transaction response signals over a
first communication channel. . . . The transaction request signals
and the transaction response signals associated with the
transaction preferably include identification code associated
with the user, as well as information relative to the transaction,
such as item, quantity, vendor, as is known.”
As stated in the Specification support for identification
code can be found, for example, in paragraph 397 , “The point of
sale terminal 150 illustrated in Fig. 3C is conventional, in that it
has capability of electronically reading information from a
device equipped to transmit information in a format that it reads.
Thus, the reader 152 within the point of sale terminal 150 can be
of one or many types. If the point of sale terminal reader 152
includes the provision for NFC communications, then simply
bringing the secure element 130 with the NFC transceiver will
cause initiation of a transaction and the transmission of the
identification code associated with the secure element 130 and
thus the user.”

5 The pages in the Request are not numbered. Appellant indicates on the
first page of the Request that the Remarks begin on page 2 and we have
numbered the Request pages 2–14.
6 As discussed infra, there is confusion regarding Appellant’s citation to a
Specification. This appears to be ¶ 31 of the Specification (filed
11/25/2009).
7 As discussed infra, there is confusion regarding Appellant’s citation to a
Specification. This appears to be ¶ 37 of the Specification (filed
11/25/2009).
Appeal 2019-003563
Application 12/592,581

10
As stated in the Specification support for identification
code and payment method can be found, for example, in Figure
3D and paragraph 428 , “As such, the management server 180 can
store user personal and credit and transactional information and
history, including a code associated with the user, for a variety
of different mobile devices, thereby allowing a system which
can scale.”
As stated in the Specification support for identification
code and payment method can be found, for example, in
paragraph 469. “The two transaction workflows that have been
specifically discussed above are the credit card and ticketing
workflows. Other transaction flows are also intended within the
scope of the invention. Debit card and cash card transactions are
similar to credit card transactions, with variations being
implemented to account for the differences that exist in those
types of transactions, which types of transactions are well
understood. Coupons can be implemented with the invention, in
much the same manner as tickets, though coupons can be
transmitted without there being payment. “

Id. at 7–8.
Appellant refers to the dependent claims as corroborating that an
identification code is not the same as the payment method. Id. at 8 (citing
dependent claims 106, 112, 108, 114, 109, 115, 118, 120). Appellant argues
the prosecution makes clear that the identification code of the user
corresponds to a payment method which is a credit card, debit card, or
prepaid card. Id. at 8–9.

8 As discussed infra, there is confusion regarding Appellant’s citation to a
Specification. This appears to be ¶ 40 of the Specification (filed
11/25/2009).
9 As discussed infra, there is confusion regarding Appellant’s citation to a
Specification. This appears to be ¶ 44 of the Specification (filed
11/25/2009).
Appeal 2019-003563
Application 12/592,581

11
We have reviewed Appellant’s arguments in the Appeal Brief, Reply
Brief, at the Hearing, and in the Request for Rehearing, the Examiner’s
rejections, and the Examiner’s responses to Appellant’s arguments. For at
least the reasons discussed below, although we agree with and adopt the
Examiner’s factual findings regarding the teachings of the cited references,
in light of Appellant’s new evidence in the Specification, we more narrowly
interpret the disputed limitations in view of the Specification. In our
analysis below, we highlight and address specific findings and arguments for
emphasis.
During prosecution, claims must be given their broadest reasonable
interpretation when reading claim language in light of the Specification as it
would have been interpreted by one of ordinary skill in the art. In re Am.
Acad. of Sci. Tech. Ctr., 367 F.3d 1359, 1364 (Fed. Cir. 2004). While we
interpret claims broadly, but reasonably in light of the Specification, we
nonetheless must not import limitations from the Specification into the
claims. See In re Van Geuns, 988 F.2d 1181, 1184 (Fed. Cir. 1993). Our
reviewing court states “the words of a claim ‘are generally given their
ordinary and customary meaning.’” Phillips v. AWH Corp., 415 F.3d 1303,
1312 (Fed. Cir. 2005) (en banc) (citations omitted). However, the broadest
reasonable interpretation differs from the broadest possible interpretation.
In re Smith Int’l, Inc., 871 F.3d 1375, 1383 (Fed. Cir. 2017). The correct
inquiry in giving a claim term its broadest reasonable interpretation in light
of the specification is “an interpretation that corresponds with what and how
the inventor describes his invention in the specification, i.e., an
interpretation that is ‘consistent with the specification.’” Id. at 1382–83
(quoting In re Morris, 127 F.3d 1048, 1054 (Fed. Cir. 1997)).
Appeal 2019-003563
Application 12/592,581

12
Claim 86 presents a method for conducting an NFC transaction using
an NFC protocol. The method includes maintaining an identification code
associated with a user in a secure element, transmitting the identification
code to an NFC terminal, and transmitting the identification code to a
server10 for processing the NFC transaction using a payment method stored
at the server that corresponds to the identification code associated with the
user. Simply stated, claim 86 recites two disputed elements: the
identification code in a secure element memory and the payment method
stored at the server that corresponds to the identification code.
As stated in the Decision, a plain reading of the disputed limitations
supports a broad interpretation of the disputed limitations as utilized in the
Examiner’s findings:
We now refer to the disputed claim 86 limitations. For
example, claim 86 disputed limitation (1) does not recite the
“identification code . . . ” must be a serial number and cannot be
a credit card number. Nor does disputed limitation (2) “server
for processing the NFC transaction using a payment method
stored at the server that corresponds to the identification code
associated with the user” recite that the payment method cannot
be a method to debit a particular credit card. Similarly, disputed
limitation (2) does not recite that the payment method is only
stored at the server, and cannot be stored at both the secure
element and at the server. Nor does the claim recite that the
identification code is only stored in the secure element and
cannot be stored at both the secure element and at the server.
See, e.g., Tr. 13:7–10 (“these new claims recite a different

10 Figure 1 of the Specification includes two servers: management server 180
and Transaction Server 170. It appears that Appellant intends the recited
“server” to correspond to the Transaction Server 170 and this
characterization of claim 86 is also articulated by Appellant at the Oral
Hearing. See Transcript (“Tr.”) 9:17–10:6 (discussing Fig. 1 of the Spec.).
Appeal 2019-003563
Application 12/592,581

13
scenario in which only the identification code is stored in the
secure element, and the payment method is stored at the server”).

Request 3.
Regarding claim interpretation, there has been some confusion in the
record before us as to Appellant’s citations to specific portions of a
specification11 and Appellant’s citation to specific Figures. There are
several identified specifications in the record, and the original Specification
identifies two other applications that are incorporated by reference. See
Spec. ¶ 1 (identifying U.S. Provisional Patent Application No. 60/766,171
filed December 31, 2005, entitled “Mobile Credit Card Account Installer”
and U.S. Provisional Patent Application No. 60/766,172 filed December 31,
2005 entitled “Mobile Ticket”). Based on statements made at the Hearing,
Appellant often appears to be referring to a specification as published (as
US 2010/0161403 A1 on June 24, 2010) rather than the Specification as
filed (on Nov. 25, 2009). Tr. 10:5–16:23. Unfortunately, the result is
Appellant’s identification of the portions of the “Specification” in the record
does not always follow the Specification. There is also confusion in
Appellant’s citations to arguments that Appellant has previously made in the
record that Appellant argues supports its position regarding claim
interpretation. Appellant’s citation to prior arguments in this case appear to
not always track with the actual intended citation. For example, regarding

11 See note 1, supra. Specification, filed 11/25/2009 (“Spec.” or
“Specification”). There are several related specifications and there is
confusion regarding Appellant’ citations to related specifications. For
purposes of this Rehearing, we refer to the Specification, filed 11/25/2009
(“Spec.” or “Specification”).

Appeal 2019-003563
Application 12/592,581

14
Appellant’s citation to its previous arguments, see Request, page 8, citing
argument made in Reply Brief 32. It appears Appellant intended to refer to
Reply Brief 33.
In our Decision, we determined Appellant did not clearly identify
portions of the Specification which would provide definitions or sufficient
guidance to a person of ordinary skill in the art that the claims would be
interpreted as asserted by Appellant. Dec. 11 (“Nor has Appellant identified
portions of the Specification which would provide definitions or sufficient
guidance to a person of ordinary skill in the art that the claims would be
interpreted as asserted by Appellant.”). At the Hearing, Appellant was urged
to provide specific guidance regarding the Specification. Tr. 10:22–11:8. In
its Request, Appellant has pointed more clearly to description in the
Specification that is consistent with its interpretation and inconsistent with
the Examiner’s interpretation. Although arguments not previously raised
and evidence not previously relied upon are usually not permitted in
rehearing, see 37 C.F.R. § 41.52(a), and we encourage Appellant to more
clearly include all arguments and evidence in the appeal brief in the future,
we have nevertheless reconsidered our interpretations in view of the
arguments that Appellant did make in the Appeal Brief, Appellant’s new
citations to the Specification and further explanations in the Request, and
Appellant’s pro se status.
Specification, paragraph 31, describes “identification code associated
with the user, as well as information relative to the transaction, such as item,
quantity, vendor, as is known” (emphases added). Absent is any description
or suggestion that a credit card would be selected as “identification code.”
Paragraph 37 describes “transmission of the identification code associated
Appeal 2019-003563
Application 12/592,581

15
with the secure element 130” and we note that risk of loss of the
identification code is likely less significant than loss of a credit card
(number). Paragraph 40 describes that “the management server 180 can
store user personal and credit and transactional information and history,
including a code associated with the user, for a variety of different mobile
devices, thereby allowing a system which can scale.” This allows scaling
because the mobile device includes the identification code and this code can
be used in multiple devices and loss of a device and its identification code is
likely less significant that loss of credit card information.
The Specification, paragraphs 31, 37, and 40, is consistent with
Appellant’s interpretation and inconsistent with the Examiner’s
interpretation.
Dependent claims 106 and 112 recite that “payment method is a credit
card, debit card, or cash card.” Dependent claims 108 and 114 recite
“wherein based on information related to the identification code, the NFC
terminal transmits the identification code to a specific server for processing
the NFC transaction using the payment method stored at the server that
correspond to the identification code.” Dependent claims 109 & 115 recite
in part, “further wherein, the transaction response is based on the server
correlating the identification code associated with the user, information
related to the payment method, information related to a user, information
related to the NFC transaction, and information related to transaction
history.” Dependent claims 118 & 120 recite in part, “further wherein the
server is configured to store a single identification code associated with the
user for a variety of the user’s mobile devices.”
Appeal 2019-003563
Application 12/592,581

16
The dependent claims are consistent with the interpretation that the
identification code is a code stored in the mobile device that corresponds to a
payment method (credit card) stored at the server.
Applying a broad and reasonable interpretation of disputed limitation
(1), the “identification code . . . ” can be a serial number as asserted by
Appellant, but would not be a credit card number as asserted by the
Examiner because this interpretation is not consistent with the Specification.
With a broad and reasonable claim interpretation, we now refer to the
Examiner’s findings regarding the teachings of Rosenberg, Nystrom, and
Yeager.
Rosenberg teaches transmitting an account number, not an
identification code, to the server. Ans. 3; Rosenberg ¶¶ 6, 52. Nystrom
teaches using a secure element for the POS transactions. Final Act. 3;
Nystrom ¶¶ 6, 12, 127–133, 136–139, 142, 143; Figs. 7, 9. Yeager teaches
transmitting an account number, not an “identification code . . . ” during the
POS transaction. Final Act. 4–5; Yeager ¶¶ 31–36; Fig. 2. Yeager stores the
account number in the secure element during the POS transaction and
transmits it to the backend servers during the POS transaction, and this
results in storing the payment method in the backend servers. Ans. 4–5;
Yeager ¶ 31; Fig. 5.
We turn now to the Prior Decision which affirmed the obviousness
rejection of then-pending claim 54 over Rosenberg and Nystrom. Prior Dec.
1–14. Claim 54 has since been cancelled. Although then-pending claim 54
included similarities to present claim 86, there are significant differences.
Claim 54 did not recite “using a payment method stored on the server.”
Claim 54 recited the terms “payment protocol” and “payment credentials”
Appeal 2019-003563
Application 12/592,581

17
that are stored within the secure element in the memory of the mobile
device, but does not recite “identification code.”
Much of the Prior Decision is focused on the teachings of the
references (Rosenberg, Nystrom). The Prior Decision findings regarding the
teachings of Rosenberg and Nystrom are relevant regarding currently-
pending claim 86 but the Prior Decision does not directly address
“identification code . . . .” See Prior Dec. 3–14. In particular, the findings
discussed, supra, that Rosenberg and Nystrom teach transferring payment
information (credit information) stored in the memory of the secure element
is consistent with the findings of the Prior Decision. Id. at 11.
In view of the above, on the record before us, the references do not
teach transferring an identification code using a payment method stored at
the server that corresponds to the identification code associated with the user
as required by claim 86. Instead, the references teach transferring credit
information (credit card) and this is outside the scope of a broad and
reasonable interpretation of claim 86. Additionally, the Examiner’s use of
the credit card as both the identification code and the payment method is
inconsistent with the Specification as the identification code and credit card
information are described as separate elements.
Because our decision is dispositive of the rejections made, we do not
address additional arguments raised by Appellant in the Request for
Rehearing.

DECISION
Appeal 2019-003563
Application 12/592,581

18
For the reasons discussed above, we grant Appellant’s request and
reverse the Examiner’s rejection of representative claim 86, and claims 88,
89, 95, 96, 98, 99, and 105–123 under 35 U.S.C. § 103.

REQUEST FOR REHEARING GRANTED
EXAMINER REVERSED