Ex Parte Nelsen et al

Patent Trial and Appeal Board

Oct 18, 2012

11974987 (P.T.A.B. Oct. 18, 2012)

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.
11/974,987 10/17/2007 Mark Allen Nelsen P-14064US 6468
71116 7590 10/18/2012
Visa USA c/o Duane Morris LLP
Attn: James Sze, Esq.
101 West Broadway
Suite 900
San Diego, CA 92101
EXAMINER
DASS, HARISH T
ART UNIT PAPER NUMBER
3695
MAIL DATE DELIVERY MODE
10/18/2012 PAPER
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.
PTOL-90A (Rev. 04/07)
UNITED STATES PATENT AND TRADEMARK OFFICE 1
___________ 2
3
BEFORE THE PATENT TRIAL AND APPEAL BOARD 4
___________ 5
6
Ex parte MARK ALLEN NELSEN, 7
NANCY THERESE HILGERS, 8
KARL NEWLAND, 9
FREDERICK LIU, 10
ROGER PAUL MORRISON, 11
ANDREW BRENDAN CARPENTER, 12
SIVAKUMAR SESHAPPAN, 13
CRAIG M. KATO, 14
and ALAN SCOTT 15
___________ 16
17
Appeal 2011-002447 18
Application 11/974,987 19
Technology Center 3600 20
___________ 21
22
23
Before ANTON W. FETTING, BIBHU R. MOHANTY, and 24
MEREDITH C. PETRAVICK, Administrative Patent Judges. 25
FETTING, Administrative Patent Judge. 26
DECISION ON APPEAL 27
Appeal 2011-002447
Application 11/974,987

2
STATEMENT OF THE CASE1 1

1 Our decision will make reference to the Appellants’ Appeal Brief (“App.
Br.,” filed June 14, 2010) and Reply Brief (“Reply Br.,” filed October 19,
2010), and the Examiner’s Answer (“Ans.,” mailed August 30, 2010).
Mark Allen Nelsen, Nancy Therese Hilgers, Karl Newland, Frederick 2
Liu, Roger Paul Morrison, Andrew Brendan Carpenter, Sivakumar 3
Seshappan, Craig M. Kato, and Alan Scott (Appellants) seek review under 4
35 U.S.C. § 134 (2002) of a final rejection of claims 1-20, the only claims 5
pending in the application on appeal. We have jurisdiction over the appeal 6
pursuant to 35 U.S.C. § 6(b) (2002). 7
The Appellants invented a way to import fraud prevention rules from an 8
issuer and implement them in real-time at a payment processor 9
(Specification 1:Field of the Invention). 10
An understanding of the invention can be derived from a reading of 11
exemplary claim 1, which is reproduced below [bracketed matter and some 12
paragraphing added]. 13
1. A payment processor apparatus comprising: 14
[1] a network interface 15
configured 16
to receive 17
a fraud prevention rule 18
from an issuer, 19
and 20
to receive 21
a proposed financial transaction 22
Appeal 2011-002447
Application 11/974,987

3
from an acquirer; 1
[2] a transaction driver 2
configured 3
to receive 4
the fraud prevention rule; 5
[3] a real time decisioning processor 6
to compare 7
the proposed financial transaction 8
from the acquirer 9
and 10
the fraud prevention rule, 11
the comparison determining 12
whether the proposed financial transaction should 13
be declined; 14
and, 15
[4] the network interface 16
being further configured 17
to transmit a decline message 18
to the acquirer 19
when the proposed financial transaction 20
should be declined. 21
The Examiner relies upon the following prior art: 22
Kavanagh US 2004/0128243 A1 Jul. 1, 2004
Madhok US 2006/0059110 A1 Mar. 16, 2006
Kranzley US 2008/0021829 A1 Jan. 24, 2008
Appeal 2011-002447
Application 11/974,987

4
Claims 1-20 stand rejected under 35 U.S.C. § 103(a) as unpatentable 1
over Kranzley, Madhok and Kavanagh.2,3 2
ISSUES 3
The issues of obviousness turn primarily on whether (1) any of the 4
references describe fraud prevention rules; and (2) whether the claims shift 5
financial transaction approval from issuers to payment processors. 6
FACTS PERTINENT TO THE ISSUES 7
The following enumerated Findings of Fact (FF) are believed to be 8
supported by a preponderance of the evidence. 9
Facts Related to the Prior Art 10
Madhok 11
01. Madhok is directed to detection of fraud and control 12
management in banking transactions by notifying and authorizing 13
credit card transactions in accordance with personalized rules set 14
up by a credit card holder of a bank. Madhok ¶ 0002. 15
02. Various fraud detection systems have been discussed in the 16
prior art for personalized control and management to a customer 17
of the bank for transfer of money. Madhok ¶ 0013. 18

2 Although the statutory basis for the rejection of claims 1-7 and 15-20 omits
Kavanagh (Ans. 6), the analysis explicitly relies on the same rationale as the
rejection of the remaining claims, which includes Kavanagh. Thus, the
omission of Kavanagh is taken as a typographic error.

3 Rejections under 35 U.S.C. § 101 and 112 were withdrawn. Ans. 3.
Appeal 2011-002447
Application 11/974,987

5
03. Arcot TransFort is a real-time payment authentication solution 1
that will allow Visa member banks and Visa card processors to 2
authenticate the identity of Visa cardholders during an online 3
transaction. Madhok ¶ 0023. 4
04. Madhok does transactions using a card and getting confirmation 5
of the transactions through a messaging service. The card user 6
enters his card data at the point of sales terminal, which sends a 7
request to the acquiring bank system. The card fraud control 8
system (CFCS) receives a request for validation from the issuing 9
bank and passes the request through the user defined personalized 10
rules and assuming a successful match sees whether the user has 11
opted for authorization or notification. If the user has opted for 12
notification, then assuming a successful match for notification 13
rule, the CFC system sends a notification. The user is further 14
asked whether to authorize the transaction or not. The user has to 15
key in a Personal Identification Number (PIN) given to him during 16
the registration process. The CFC system validates the PIN and 17
based on the result of the authentication the transaction is declined 18
or accepted. In this way, by using the CFC system, the user can 19
make transactions using the card in a secure and safe environment 20
and is informed of every transaction. Madhok ¶ 0033-0034. 21
05. A rule engine picks up the rules of transaction set by the user at 22
the time of registration and matches them with the request. These 23
rules are defined by the user using a Rules Wizard that creates 24
conditions with credit card transaction parameters such as amount 25
of transaction, time of transaction, location of merchant, merchant 26
Appeal 2011-002447
Application 11/974,987

6
type and channel used for transaction. The rules are in the form of 1
operands and the logical operators. The user can create multiple 2
rules and have control over the values, operators and the operands 3
(parameters) used in creating a rule. If the request matches a rule 4
or a set of rules, it is passed on to a logic processor module. 5
Madhok ¶ 0051-0052. 6
Kranzley 7
06. Kranzley is directed to allowing cardholders to access multiple 8
financial accounts with a single payment card in a manner which 9
is convenient and flexible for the cardholders. This is operated 10
with payment cards that are structurally and functionally the same 11
as payment cards that are typically used in existing widely-12
deployed payment card systems. Kranzley ¶ 0003. 13
07. Kranzley permits cardholders to pre-define, and to store in the 14
system, account selection rules which are associated by the system 15
with the cardholder’s card number. For example, the rules may 16
determine which account should be selected for use in a particular 17
transaction based on one or more attributes of the transaction. 18
When the cardholder presents his/her card to pay for a transaction, 19
the system looks up the rule or rules, previously defined by the 20
cardholder, to determine which one of the cardholder's accounts 21
should be accessed to pay for the transaction. Kranzley ¶ 0009. 22
08. The payment card system may include numerous server 23
computers operated by “acquiring” financial institutions which 24
have contracted with the merchants to receive and process the 25
Appeal 2011-002447
Application 11/974,987

7
merchants’ payment card transactions. The acquirer server 1
computers, in turn, pass the transaction requests on to server 2
computers, which are operated by financial institutions which 3
issued the payment cards. The issuer server computers are also 4
part of the payment card system. The issuer server computers 5
process the transaction requests received from the acquirer server 6
computers and determine whether the requested transactions are to 7
be authorized. Kranzley ¶ 0012. 8
09. The functions may be divided among the system components in 9
various ways. For example, the payment card association server 10
computer could be eliminated, with each issuer server computer 11
taking on functions of the payment card association server 12
computer such as receiving input from cardholders to define 13
account selection rules, storing the resulting account selection 14
rules, and applying the account selection rules to transaction 15
requests. Kranzley ¶ 0053. 16
10. In another modification of the system, the payment card 17
association server computer operates to receive cardholder input 18
to define account selection rules, and then downloads the rules to 19
the issuer server computers for the cardholders. The issuer server 20
computers then store the account selection rules and apply the 21
rules to transaction requests. Kranzley ¶ 0055. 22
11. One server computer may operate to receive customer input to 23
define account selection rules, and another computer may receive 24
the rules from the first computer, store the rules, and apply the 25
Appeal 2011-002447
Application 11/974,987

8
rules in response to inquiries from issuer server computers. 1
Kranzley ¶ 0058. 2
12. Kranzley may also operate to provide cardholders with alerts 3
and/or reminders relating to their use of financial accounts. 4
Dispatching of alerts/reminders may be triggered by rules similar 5
to account selection rules. Alert/reminder rules may be defined in 6
a similar manner to account selection rules, and by a process 7
similar to that described above. Kranzley ¶ 0059. 8
13. The rules may assist the cardholder in early detection of 9
fraudulent transactions. Kranzley ¶ 0061. 10
ANALYSIS 11
We are not persuaded by the Appellants’ arguments that (1) all of the 12
references lack the fraud prevention rules of the present invention; and (2) 13
even if the fraud prevention rules could be found, none of the references 14
shift financial transaction approval from issuers to payment processors. 15
The Examiner relies primarily on Madhok for fraud prevention rules, 16
and indeed Madhok is directed to detection of fraud and control management 17
in banking transactions by notifying and authorizing credit card transactions 18
in accordance with personalized rules set up by a credit card holder of a 19
bank. FF 01. Whether Madhok relies on some notification mechanism in 20
implementing the results of such rules being found true as Appellants argue 21
does not negate the fraud prevention nature explicitly recited by Madhok. 22
We also find that Kranzley describes its rules being used for alerts as well as 23
for account selection and at least one use of its rules as being for fraud 24
prevention. FF 12-13. 25
Appeal 2011-002447
Application 11/974,987

9
The phrase “payment processor” is functional, referring to a processor 1
apparatus for payment. Clearly all of Kranzley’s operations occur on 2
machines that are part of the function of processing payment, thus the 3
overall payment processing apparatus comprising all the machines 4
performing that function, and Kranzley also shows it was predictable to shift 5
various parts of the operation among individual discrete components of the 6
overall payment processing apparatus. Appellants appear to be arguing the 7
“payment processor” refers to a party, but the claim does not recite that to be 8
the case. 9
We are also not persuaded by the Appellants’ argument that the user 10
defines the rules in the art rather than the issuer. The claims recite the rules 11
are received from the issuer, not defined by the issuer. Thus the issue is 12
where the rules reside or pass through. Kranzley clearly shows that the rules 13
may reside or pass through an issuer computer among its various alternative 14
designs. FF 09-10. 15
CONCLUSIONS OF LAW 16
The rejection of claims 1-20 under 35 U.S.C. § 103(a) as unpatentable 17
over Kranzley, Madhok and Kavanagh is proper. 18
DECISION 19
The rejection of claims 1-20 is affirmed. 20
No time period for taking any subsequent action in connection with this 21
appeal may be extended under 37 C.F.R. § 1.136(a). See 37 C.F.R. 22
§ 1.136(a)(1)(iv) (2007). 23
24
Appeal 2011-002447
Application 11/974,987

10
AFFIRMED 1
2
3
4
5
6
7
8
9
mls 10