Ex Parte Nelsen et al

Patent Trial and Appeal BoardOct 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