(12) United States Patent
`Coulter et al.
`
`(10) Patent No.:
`(45) Date of Patent:
`
`US 9,292,852 B2
`Mar. 22, 2016
`
`US009292852B2
`
`(54) SYSTEMAND METHOD FOR APPLYING
`STORED VALUE TO A FINANCIAL
`TRANSACTION
`
`(75) Inventors: Todd R. Coulter, Rancho Murieta, CA
`(US); Mordechai E. Kaplinsky,
`Brooklyn, NY (US); Christopher E.
`Lewis, Tempe, AZ (US); Jeffery A.
`Warmington, Wellington, FL (US)
`
`(73) Assignee: FonWallet Transactions Solutions,
`Inc., Rancho Murieta, CA (US)
`
`(*) Notice:
`
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 340 days.
`
`JP
`JP
`
`USPC ............................................................ 705/67
`See application file for complete search history.
`
`(56)
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`6,999,943 B1
`7.357.310 B2
`
`2/2006 Johnson et al.
`4/2008 Calabrese et al.
`(Continued)
`
`FOREIGN PATENT DOCUMENTS
`2007O18043 A * 1, 2007
`2011-118898 A
`6, 2011
`OTHER PUBLICATIONS
`
`(21) Appl. No.: 12/859,213
`
`(22) Filed:
`
`Aug. 18, 2010
`
`(65)
`
`Prior Publication Data
`US 2010/0312636A1
`Dec. 9, 2010
`
`Related U.S. Application Data
`(63) Continuation-in-part of application No. 12/557,457.
`filed on Sep. 10, 2009, now Pat. No. 8,099,368.
`(60) Provisional application No. 61/112,749, filed on Nov.
`8, 2008.
`
`(51) Int. Cl.
`G06O20/00
`G06O20/42
`
`(2012.01)
`(2012.01)
`(Continued)
`
`(52) U.S. Cl
`G06O20/42 (2013.01); G06O20/10
`CPC
`(2013.01). G06O20/20 (2013,015. G06O20/32
`(201301). G06O20/322 (2013,015. G06O
`s
`20/40 (2013,015.
`(Continued)
`(58) Field of Classification Search
`CPC ...................................................... G06Q 20/00
`
`International Search Report and Written Opinion for PCT/US09/
`63641; Applicant: FonWallet Transaction Solutions, Inc.; Mailing
`Date: Dec. 15, 2009, 8 pages.
`(Continued)
`
`Primary Examiner —James A Reagan
`
`ABSTRACT
`(57)
`A transaction processing service operates as an intermediary
`between acquirers of financial transaction requests and issu
`ing institutions that process the financial transaction requests.
`The intermediary receives an authorization request generated
`based on a transaction initiated by a customer at a point of
`purchase. The intermediary service then determines one or
`more stored value items that can be applied to the transaction.
`Stored value items may be determined based on the custom
`er's identity or based on transaction characteristics, such as
`the point of purchase or the transaction items. The service
`sends a transaction notification to a mobile device associated
`with the customer to notify the customer of the available
`stored value items. The service then applies the stored value
`items to pay a portion of the transaction amount and initiates
`a payment process to pay the remainder of the transaction
`amount.
`
`40 Claims, 18 Drawing Sheets
`
`12
`
`Payment
`Association
`
`issuing
`institution
`
`08
`
`204
`
`208
`
`(3)
`
`Acquirer
`
`Entermediary
`Service
`
`
`
`Secure
`Storage
`Provider
`
`102
`-6-4---- -
`Mobile Device :
`Customer
`
`IPR2021-01260
`Unified EX1001 Page 1
`
`

`

`US 9,292.852 B2
`Page 2
`
`(51) Int. Cl.
`G06O20/10
`(2012.01)
`G06O20/20
`(2012.01)
`G06O20/32
`(2012.01)
`G06O20/40
`(2012.01)
`G06O 30/02
`(2012.01)
`G06O40/02
`(2012.01)
`(52) U.S. Cl.
`CPC ............ Gogo 3002 (2013.01); Gogo 30.023.8
`2013.O1): GO(6O4/02 (2013.O1
`(
`.01);
`O
`(
`.01)
`
`(56)
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`2002/0138445 A1
`9/2002 Laage et al.
`2002.0143634 A1 10/2002 Kumar et al.
`2003/0216996 A1 1 1/2003 Cummings et al.
`2004/0230525 A1* 11/2004 Barsade et al. ................. TOS/40
`2005/0222949 A1 10/2005 Inotay et al.
`2005/025 1440 A1* 11/2005 Bednarek ........................ 70.5/10
`2008/0010191 A1
`1/2008 Rackley, III et al.
`2008/0010215 A1
`1/2008 Rackley, III et al.
`2008/0172317 A1
`7, 2008 Deibert et al.
`2008/0288351 A1* 1 1/2008 Leung et al. .................... TO5/14
`2009,01929.04 A1
`7/2009 Patterson et al.
`2009/0325542 A1 12, 2009 Wentker et al.
`2010, 0121726 A1
`5, 2010 Coulter et al.
`2010, 0121767 A1
`5, 2010 Coulter et al.
`2010.0312657 A1 12/2010 Coulter et al.
`2010.0312700 A1 12/2010 Coulter et al.
`
`OTHER PUBLICATIONS
`
`Non-Final Office Action, U.S. Appl. No. 12/859,205, Mail Date Nov.
`7, 2011, 21 pages.
`Final Office Action, U.S. Appl. No. 12/557,453, Mail Date Mar. 30,
`2011, 19 pages.
`Final Office Action, U.S. Appl. No. 12/557,457, Mail Date Apr. 27.
`2011, 17 pages.
`g. Match
`MPTSB's OPond
`Policy Issues—Background Paper No. 2 Electronic Payment Sys
`tems Observatory (ePSO) (Aug. 2011), retrieved online Sep. 29, 2011
`at http://ftp/irc.es/EURdoc/eur 19934en.pdf, 33 pages.
`Non-Final Office Action, U.S. Appl. No. 12/557,457, Mail Date Sep.
`28, 2010, 24 pages.
`Non-Final Office Action, U.S. Appl. No. 12/557,453, Mail Date Oct.
`5, 2010, 16 pages.
`Notice of Allowance, U.S. Appl. No. 12/557,457, Mail Date Oct. 12,
`2011, 17 pages.
`Final Office Action, U.S. Appl. No. 12/859,205, Mail Date Jun. 13,
`2012, 9 pages.
`Non-Final Office Action, U.S. Appl. No. 12/859,203, Mail Date Feb.
`8, 2012, 5 pages.
`Notice of Allowance, U.S. Appl. No. 12/557,453, Mail-Date Apr. 3,
`2012, 19 pages
`Nittance U.S. Appl. No. 12/859,203, Mail-Date Apr. 27.
`Notice of Allowance, U.S. Appl. No. 12/859,205, Mail-Date Oct. 9,
`2012, 18 pages.
`
`* cited by examiner
`
`IPR2021-01260
`Unified EX1001 Page 2
`
`

`

`U.S. Patent
`
`Mar. 22, 2016
`
`Sheet 1 of 18
`
`US 9,292.852 B2
`
`
`
`112
`
`110
`
`Payment
`Association
`
`issuing
`Institution
`
`1OO
`
`.
`
`FIG. I.
`Prior Art
`
`IPR2021-01260
`Unified EX1001 Page 3
`
`

`

`U.S. Patent
`
`Mar. 22, 2016
`
`Sheet 2 of 18
`
`US 9,292.852 B2
`
`200
`
`112
`
`110
`
`Payment
`ASSOCiation
`
`issuing
`Institution
`
`108
`
`204
`
`208
`
`
`
`
`
`ACOuirer
`C
`
`Intermediary
`Service
`
`Secure
`Storage
`Provider
`
`Merchant?
`POP
`
`
`
`- - - - -
`
`102
`
`206
`O2
`---d------,
`
`Mobile Device
`
`Customer
`
`IPR2021-01260
`Unified EX1001 Page 4
`
`

`

`U.S. Patent
`
`Mar. 22, 2016
`
`Sheet 3 of 18
`
`US 9,292.852 B2
`
`
`
`112
`
`110
`
`Payment
`ASSOciation
`
`Issuing
`Institution
`
`200
`
`Intermediary
`Service
`
`Secure
`Storage
`Provider
`
`IPR2021-01260
`Unified EX1001 Page 5
`
`

`

`U.S. Patent
`
`Mar. 22, 2016
`
`Sheet 4 of 18
`
`US 9,292.852 B2
`
`112
`
`110
`
`
`
`Payment
`ASSOciation
`
`Issuing
`Institution
`
`200
`
`
`
`
`
`Intermediary
`Service
`
`
`
`Secure
`Storage
`Provider
`
`
`
`
`
`IPR2021-01260
`Unified EX1001 Page 6
`
`

`

`U.S. Patent
`
`Mar. 22, 2016
`
`Sheet 5 of 18
`
`US 9,292.852 B2
`
`
`
`{{9 (9 IAI
`
`
`
`ÞV9, 'OIH
`
`9ZZ
`
`'Moleq
`
`ZZZ
`
`OZZ
`
`ZZZ
`
`IPR2021-01260
`Unified EX1001 Page 7
`
`

`

`U.S. Patent
`
`US 9,292.852 B2
`
`
`
`(19 (91 H.
`
`
`
`
`
`07Z
`
`sezº**** | spoo
`
`O9 (AOIAI
`
`ZZZ
`
`992
`
`IPR2021-01260
`Unified EX1001 Page 8
`
`

`

`U.S. Patent
`
`Mar. 22, 2016
`
`Sheet 7 of 18
`
`US 9,292.852 B2
`
`
`
`
`
`009
`
`909
`
`JOSS3OOJA
`
`IPR2021-01260
`Unified EX1001 Page 9
`
`

`

`U.S. Patent
`
`Mar. 22, 2016
`
`Sheet 8 of 18
`
`US 9,292,852 B2
`
`Hmwsuwm
`
`co_um:_m>m
`
`
`
`Nov
`
`cosmU=m>
`
`mmv
`
`
`
`w:_m>8.9m
`
`
`
`mo_>mo2522
`
`cozmoEsEEoo
`
`cofiozcmfii
`
`~623sz
`
`m:_:mw_wmv
`
`@5533
`
`m;
`
`9:33.
`
`20:3sz
`
`co=mo_::EEoo
`
`mow
`
`0;
`
`53605
`
`Scu<
`
`LmEBmzo
`
`cosmoEzEEoo
`
`LwEoumso
`
`EmEmmmcms.
`
`LwEoumzo
`
`8382522
`
`
`
`E20@2502522
`
`m.DNK
`
`|PR2021-01260
`
`Unified EX1001 Page 10
`
`IPR2021-01260
`Unified EX1001 Page 10
`
`
`
`
`
`
`
`
`
`
`
`

`

`U.S. Patent
`
`Mar. 22, 2016
`
`Sheet 9 of 18
`
`US 9,292.852 B2
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Receive request
`
`Validate ?equest
`
`504
`
`506
`
`Authenticate requester
`
`Retrieve Customer info
`
`PrOCeSS Stored value
`
`500
`
`Process rules
`
`Process advertising
`
`Generate transaction
`notification
`
`Send message to mobile
`
`Receive reply from mobile
`
`FIG. 6A
`
`IPR2021-01260
`Unified EX1001 Page 11
`
`

`

`U.S. Patent
`
`Mar. 22, 2016
`
`Sheet 10 of 18
`
`US 9,292.852 B2
`
`
`
`Transaction verified?
`
`
`
`No
`
`Reject request
`
`520
`
`Yes
`
`521
`
`522
`
`Generate information request
`
`524
`Send information request to
`issuing institution
`
`526
`
`500
`
`Receive account information
`
`528
`
`Send account information to
`acquirer
`
`Return
`
`FIG. 6B
`
`IPR2021-01260
`Unified EX1001 Page 12
`
`

`

`U.S. Patent
`
`Mar. 22, 2016
`
`Sheet 11 of 18
`
`US 9,292.852 B2
`
`532
`
`Receive target account
`
`
`
`Receive condition(s)
`
`534
`
`536
`
`
`
`538
`
`
`
`
`
`
`
`
`
`Store rule parameters
`
`530
`
`FIG. 6C
`
`IPR2021-01260
`Unified EX1001 Page 13
`
`

`

`U.S. Patent
`
`Mar. 22, 2016
`
`Sheet 12 of 18
`
`US 9,292.852 B2
`
`550
`
`
`
`
`
`
`
`
`
`
`
`552
`
`Determine requesting account
`
`554
`
`Determine rules only
`asSociated with requesting
`aCCOUnt
`
`Determine group rules
`applicable to requesting
`aCCOunt
`
`
`
`Select next rule
`
`Determine Conditions
`
`558
`
`560
`
`562
`
`Determine relevant information
`
`Test Conditions
`
`564
`
`566
`
`Queue associated action
`
`Additional rules?
`
`
`
`FIG. 6D
`
`IPR2021-01260
`Unified EX1001 Page 14
`
`

`

`U.S. Patent
`
`Mar. 22, 2016
`
`Sheet 13 of 18
`
`US 9,292.852 B2
`
`PrOCeSS Stored
`Value
`
`572
`
`Determine Customer
`information
`
`574
`Determine point of purchase
`information
`
`576
`
`Determine product information
`
`57 8
`Look up stored value items
`based on customer, point of
`purchase, or product
`information
`
`580
`
`Select next stored value item
`
`Apply automatically?
`
`
`
`
`
`570
`
`584
`Apply stored value item to
`transaction
`
`586
`Add stored value item to
`notification list
`
`
`
`Stored value item
`remaining?
`
`NO
`
`FIG. 6E
`
`IPR2021-01260
`Unified EX1001 Page 15
`
`

`

`U.S. Patent
`
`Mar. 22, 2016
`
`Sheet 14 of 18
`
`US 9,292.852 B2
`
`Start
`
`702
`
`700
`
`Receive initial authorization
`request
`
`
`
`
`
`
`
`704
`Initial
`authorization reques
`associated with
`intermediary
`Service?
`
`
`
`NO
`
`706
`Send initial authorization
`request to payment association
`
`Return
`
`Send information request to
`intermediary service
`
`710
`Receive aCCount information
`from intermediary service
`
`Generate modified
`authorization request
`
`712
`
`714.
`
`Send modified authorization
`request to payment association
`
`716
`
`Receive authorization
`
`718
`Send authorization to point of
`purchase
`
`Return
`
`FIG. 7
`
`IPR2021-01260
`Unified EX1001 Page 16
`
`

`

`U.S. Patent
`U.S. Patent
`
`022a2r.m
`
`51a
`
`855960H“mwsamm
`co=m_oomw<538MEmE>ma3935.25
`
`0coszto£3<
`".0E_on_ $205.“.
` cozmuEsEEoo
`
`SEmE>ma
`mcozmfiomw<
`
`
`
`”6“Eon
`
`
`
`
`
`Z08
`wow
`
`
`
`cosmoEsEEoocozmoEzEEoo
`
`mwmceza
`
`co_um:_m>m_
`
`US 9,292.852 B2
`2B258,
`
`9SU
`
`%moEmm
`2.,bmfiwEEE
`
`|PR2021-01260
`
`Unified EX1001 Page 17
`
`IPR2021-01260
`Unified EX1001 Page 17
`
`
`
`

`

`U.S. Patent
`
`Mar. 22, 2016
`
`Sheet 16 of 18
`
`US 9,292.852 B2
`
`
`
`
`
`6 ’9ICH
`
`
`
`A eolaeq e??qoW
`
`IPR2021-01260
`Unified EX1001 Page 18
`
`

`

`U.S. Patent
`
`Mar. 22, 2016
`
`Sheet 17 of 18
`
`US 9,292.852 B2
`
`Receive request
`
`
`
`
`
`1002
`
`1004
`
`Look up account information
`
`1000
`
`
`
`
`
`
`
`
`
`Perform Verification
`procedure?
`
`Yes
`
`1008
`
`Perform verification procedure
`
`
`
`
`
`1010
`issuing institution
`managed?
`
`
`
`Utilize rules module to
`reject all requests within a
`Selected time frame
`
`1014
`SSuing institution
`stored?
`
`
`
`1016
`Transmit message to issuing
`institution
`
`1018
`
`Update account status
`
`FIG. I.04
`
`IPR2021-01260
`Unified EX1001 Page 19
`
`

`

`U.S. Patent
`
`Mar. 22, 2016
`
`Sheet 18 of 18
`
`US 9,292.852 B2
`
`1042
`
`Receive authorization request
`
`
`
`1044
`
`Look up account information
`
`
`
`1046
`Issuing institution
`Stored?
`
`
`
`1048
`
`1040
`
`1050
`
`Look up account Status
`
`Request account status
`
`
`
`
`
`Activated?
`
`Execute authorization
`
`1056
`
`
`
`
`
`FIG. IOB
`
`IPR2021-01260
`Unified EX1001 Page 20
`
`

`

`US 9,292,852 B2
`
`1.
`SYSTEMAND METHOD FORAPPLYING
`STORED VALUE TO A FINANCIAL
`TRANSACTION
`
`2
`payment instruments can therefore be complicated and cum
`bersome. Thus, it would be useful to consumers to be able to
`manage multiple payment instruments in a simple fashion.
`
`CROSS-REFERENCE TO RELATED
`APPLICATIONS
`
`This application is a continuation-in-part of U.S. patent
`application Ser. No. 12/557,457 filed Sep. 10, 2009 now U.S.
`Pat. No. 8,099.368, entitled “Intermediary Service and
`Method for Processing Financial Transaction Data with
`Mobile Device Confirmation, which claims the benefit of
`U.S. Provisional Application No. 61/112,749, entitled
`“Mobile Card Access & Authorization filed on Nov. 8, 2008.
`
`BACKGROUND
`
`10
`
`15
`
`25
`
`30
`
`35
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`FIG. 1 is a block diagram of a representative environment
`for processing financial transaction data according to prior art
`methods.
`FIG. 2A is a block diagram that illustrates communication
`steps for sending an authorization request to an intermediary
`service.
`FIG.2B is a block diagram that illustrates a two-step autho
`rization process performed by the intermediary service.
`FIG. 2C is a block diagram that illustrates a process for
`authorizing a transaction using a modified authorization
`request.
`FIGS. 3A-3D are representative user interfaces presented
`to a customer of a mobile device during a financial transac
`tion.
`FIG. 4 is a block diagram of a representative server archi
`tecture.
`FIG. 5 is a logical block diagram of the intermediary ser
`W1C.
`FIGS. 6A and 6B are a flow chart of a process for process
`ing financial transaction data executed by an intermediary
`service.
`FIG. 6C is a flow chart of a process for defining rules to be
`executed by the intermediary service.
`FIG. 6D is a flow chart of a process for processing rules by
`the intermediary service.
`FIG. 6E is a flow chart of a process for processing stored
`value by the intermediary service.
`FIG. 7 is a flowchart of a process for processing financial
`transaction data executed by an acquirer.
`FIG. 8 is a logical block diagram of the acquirer.
`FIG. 9 is a block diagram of encrypted message routing
`through the intermediary service.
`FIG. 10A is a flowchart of a process for selectively acti
`Vating or deactivating an account through the intermediary
`service.
`FIG. 10B is a flowchart of a process for handling an autho
`rization request by an issuing institution.
`
`DETAILED DESCRIPTION
`
`Companies that participate in electronic transaction sys
`tems (e.g., transaction systems that process credit cards, debit
`cards, etc.) must balance a number of competing concerns in
`their interactions with the systems. As businesses, companies
`must track their costs in dealing with transaction systems. For
`example, merchants who accept credit cards are subject to
`various fees when processing transactions. Merchants may
`therefore decide to accept certain credit cards and reject oth
`ers, or require a minimum charge amount when accepting a
`card for payment, in order to reduce fees. In addition, mer
`chants must track and make policy decisions about how they
`use and protect personal information associated with trans
`actions. Government regulations and private contracts (e.g.,
`with the credit card associations) set privacy and security
`requirements that banks and merchants must satisfy. The
`privacy and security requirements place limits on data secu
`rity and encryption and also limit the types of data that can be
`transmitted using different formats. These concerns are inter
`related because participants in the system pay lower fees
`when more customer information is provided with the trans
`action information. Fees are lower because the additional
`customer information can generally be retrieved only from
`the physical card itself, indicating that the card was present at
`the time of the transaction. Thus, a purchase at a brick-and
`mortar business is charged a lower processing fee than a
`purchase on the Internet, because the brick-and-mortar busi
`ness is able to transmit more customer information to the
`credit card company.
`Consumers also balance competing concerns. Avoiding
`losses from fraudulent or erroneous transactions is a particu
`lar concern. Currently, Some issuing institutions use auto
`mated systems that attempt to detect and reject Suspicious
`transactions based on transaction characteristics (e.g., loca
`tion, amount, etc.). However, these automated systems are
`often unsuccessful in differentiating legitimate transactions
`and fraudulent transactions. Otherwise, consumers can gen
`erally detect fraudulent or erroneous transactions only by
`reviewing their bill or statement to verify that every transac
`tion is correct. Reviewing bills is inconvenient because it
`requires continual vigilance from the consumer. In addition,
`several days or weeks may pass before an erroneous or
`fraudulent transaction is detected. Thus, it would be useful to
`have payment systems that enable consumers to more effi
`ciently detect these incorrect transactions.
`Convenience is also a major concern for consumers. The
`average consumer may pay for purchases using multiple pay
`ment instruments, such as credit cards, debit cards, and gift
`cards. Each payment instrument has a separate card or token
`and a separate set of identifying information, Such as credit/
`debit card numbers, that must be tracked. Managing multiple
`
`40
`
`45
`
`A transaction processing service that operates as an inter
`mediary between acquirers of financial transaction requests
`and issuing institutions that process the financial transaction
`requests is disclosed (hereinafter referred to as “the interme
`diary service' or “the service'). The intermediary communi
`cates with an acquirer to provide account information that can
`be used by the acquirer to process the financial transaction
`requests. The intermediary service utilizes a customer's
`mobile device as an out-of-band communication channel to
`notify a customer of a received financial transaction request.
`In certain circumstances, before continuing to process the
`received financial transaction request the service must first
`receive the customer's confirmation of the transaction. By
`seeking out-of-band confirmation from a customer to a trans
`action, the disclosed intermediary service thereby signifi
`cantly reduces the occurrence of fraud without changing or
`otherwise burdening standard merchant payment processes.
`To initiate a transaction, a customer presents a card or token
`containing unique identifying information to a merchant in
`order to pay for a purchase. The token may be, for example, an
`RFID tag or other contactless device for providing the unique
`
`50
`
`55
`
`60
`
`65
`
`IPR2021-01260
`Unified EX1001 Page 21
`
`

`

`3
`identifying information and may be contained in or attached
`to the customer's mobile device. The merchant transmits the
`unique identifying information to an acquirer (i.e., a financial
`institution that provides a clearinghouse service for consoli
`dating financial transactions) in an initial authorization
`request. The acquirer recognizes that the initial authorization
`request is associated with the intermediary service based on
`the unique identifying information, and transmits at least part
`of the initial authorization request to the intermediary service.
`The intermediary service authenticates the request and
`retrieves stored customer information from a database based
`on the identifying information. The stored customer informa
`tion includes an address of the customer's mobile device, a
`reference to one or more payment instruments associated
`with the customer, and averification code associated with the
`customers intermediary service account.
`Using the retrieved address of the device, the intermediary
`service transmits a transaction notification message to the
`customer's mobile device. The transaction notification mes
`sage may include the name or location of the point of pur
`chase, the transaction amount, a listing of payment instru
`ments that may be used to pay for the transaction, and/or other
`pertinent characteristics of the transaction. The transaction
`notification message may also specify a required response
`from the customer. The required response may vary depend
`ing on the requesting merchant, the type of transaction, the
`amount of the transaction, or other factor associated with the
`transaction (e.g., the type of goods or services being sold, an
`assessment of the likelihood of fraud, etc.). For example, a
`low-price transaction may require no response, a higher value
`transaction may require that the customer confirm the trans
`action, and a still higher value transaction may require that the
`customer confirm the transaction and provide a verification
`code in response to the transaction notification message. The
`transaction notification message is presented to the customer
`on the mobile device. The intermediary service may also
`Support fallback methods for transmitting the transaction
`notification message to the customer in the event that the
`primary method of sending the message to the customer is not
`available.
`If a response is required from the customer, the customer's
`response is received by the mobile device and transmitted to
`the intermediary service. The intermediary service continues
`processing of the initial authorization request based on the
`customer's response. If the customer fails to respond to the
`transaction notification message, rejects the transaction, or
`provides an incorrect verification code, the intermediary Ser
`Vice sends a denial message to the acquirer and the transaction
`fails.
`If the customer authorizes the transaction by confirming
`the transaction, or confirming the transaction and providing a
`correct verification code, the intermediary service transmits
`an information request to the issuing institution of a payment
`instrument that is to be used to complete the transaction. In
`response to the request, the issuing institution provides
`account information for the selected payment instrument. The
`intermediary service forwards the account information to the
`acquirer, which generates a modified authorization request
`based on the received account information. The acquirer then
`sends the modified request to the associated payment asso
`ciation in accordance with its standard practices. By provid
`ing the account information to generate the modified autho
`rization request, the intermediary service allows a customer
`to easily select among multiple payment instruments while
`using a single token or identifier at the time of payment. In
`addition, the provided account information may include addi
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`US 9,292,852 B2
`
`10
`
`15
`
`4
`tional verification that enables the payment association to
`process the transaction with a lower fee.
`In some embodiments, the intermediary service may main
`tain a record of a set of payment instruments that are available
`to each customer for purposes of a transaction. One or more
`payment instruments may be automatically selected for each
`transaction based on rules that are defined by the intermediary
`service, by the customer, or by the merchant. Alternatively, a
`customer may be allowed to select a payment instrument from
`a list of payment instruments that are provided in a transaction
`notification message that is transmitted by the service to the
`customer. The selected payment instrument or payment
`instruments determine the issuing institution or institutions to
`which the intermediary service sends the information request.
`The intermediary service may also provide a rules module
`that stores a set of rules for processing transactions. Each rule
`specifies one or more conditions to be tested and one or more
`actions to be executed based on the tests. For each authoriza
`tion request, the service determines the applicable rules to
`apply and tests conditions for each rule. Based on the test
`results, the service either executes or does not execute an
`associated action. Conditions may be specified based on
`transaction information, customer information, or other
`information. For example, a rule might specify a condition to
`test whether the transaction value is above a threshold value
`that requires special handling. Actions define the service's
`response to a particular result in testing a condition. To con
`tinue the previous example, the rule may include an action to
`specify a verification procedure to carry out when the trans
`action value exceeds the threshold value.
`Some rules apply to all transactions, regardless of the cus
`tomer initiating the transaction, while other rules apply to
`transactions from specified groups of accounts. Rules may be
`specified by any participant in the transaction chain, includ
`ing the customer, the merchant, the issuing institution, and the
`intermediary service, or by a combination of rules from one or
`more of these parties.
`The intermediary service may also provide functionality to
`store value for the benefit of customers. As used herein,
`“stored value' refers to any type of value stored by the inter
`mediary service that can be used to pay a portion of a trans
`action. A “stored value item is a particular unit of stored
`value that may be applied to a transaction. Each stored value
`item has an associated value, which may be stored as a cur
`rency amount measured in a US or foreign monetary unit
`(e.g., S1.95, €4) or as a percentage of a transaction amount
`(e.g., a 10% off coupon)). The value may also be denominated
`in non-currency units (e.g., "points') that can be converted to
`a currency value using a conversion rate at the time of a
`transaction. In some embodiments, the associated value for a
`stored value item varies depending on characteristics of the
`transaction, such as the time of the transaction or the mer
`chant. For example, the associated value for a stored value
`item that is a coupon may be 10% off if the item is used
`between 2 PM and 4 PM (e.g., during typical periods of low
`traffic) and 5% off at other times. Similarly, the system may
`convert non-currency units to a currency amount using a rate
`that varies depending on transaction characteristics. One
`skilled in the art will appreciate that other types of stored
`value could also be used. Each stored value item may also
`have an associated customer identifier, one or more condi
`tions for applying the stored value, and an expiration date.
`Some stored value items are unconditional. These items (re
`ferred to as “vouchers') are generally associated with a par
`ticular customer and can be used for any transaction. Custom
`ers may receive vouchers as payments or gifts from other
`customers (e.g., as a gift card), as rebates from merchants or
`
`IPR2021-01260
`Unified EX1001 Page 22
`
`

`

`US 9,292,852 B2
`
`5
`
`10
`
`15
`
`5
`manufacturers, or as refunds from merchants. Vouchers may
`have an expiration date or may retain value until redeemed by
`a CuStOmer.
`Other stored value items have conditions that restrict the
`transactions that they may be used for. These items are
`referred to as “coupons” and function similarly to traditional
`paper coupons. For example, the service may store coupons
`that can only be used for particular items or at particular
`merchants. The service may be configured to automatically
`provide coupons to the customer based on characteristics of a
`particular transaction or the customer's transaction history.
`For example, the intermediary service may provide a coupon
`when the customer purchases a particular item or when the
`customer purchases items from a particular merchant. Simi
`larly, the service may provide a coupon based on a series of
`purchases from a merchant or based on repeated purchases of
`a particular product. The service may allow a customer to use
`a coupon immediately or save the coupon for later use. Each
`saved coupon may have a range of effective dates or times, a
`specified number ofuses, or both an effective date/time range
`and a number ofuses. For example, a coupon may be effective
`for the month of June, for a time period from 2 PM to 4 PM
`each day, or from the date the coupon was issued to an
`expiration date (e.g., until July 4th). If the current date does
`not fall within the effective dates of the coupon, the service
`does not allow the coupon to be utilized by the customer. If a
`coupon has expired (i.e., the current date falls after the latest
`effective date for the coupon), or if or the number of uses for
`the coupon has been exhausted, the service may remove the
`coupon from the customer's account.
`During operation, the intermediary service generally pro
`cesses stored value after or in conjunction with the processing
`of rules by the rules module. The service determines relevant
`information from the authorization request, Such as customer
`information and merchant information, and uses the informa
`tion to determine whether there are any applicable stored
`value items. The service then determines whether to apply the
`stored value items to the transaction. In some cases, the ser
`Vice sends a transaction notification indicating the available
`stored value items and requesting that the customer select
`40
`which items to apply. Alternatively, the service may be con
`figured to automatically apply some or all available items. For
`example, the service may allow a customer to pre-authorize
`Some items to be automatically applied without requiring
`additional verification. Items that are not pre-authorized may
`45
`be excluded from use or applied based on the customer's
`response to a transaction notification. The service may also
`allow a coupon issuer to specify that its coupons should be
`automatically applied without requiring customer authoriza
`tion. After determining which items to apply, the service uses
`the stored value items to reduce the transaction amount. The
`service then proceeds with the payment process to request
`payment for the remainder of the transaction amount.
`The intermediary service may also provide functionality to
`enable a customer to selectively change the status of an
`account by activating or deactivating the account. In some
`embodiments, the intermediary service manages account sta
`tus using the rules module capabilities discussed above. In
`these embodiments, the intermediary service allows the cus
`tomer to define a rule to specify time intervals when an
`account may be used. When an authorization request is
`received, the intermediary service rejects the request if the
`time is not within an authorized time interval.
`In other embodiments, the intermediary service provides
`an interface for customers and manages account status, while
`the issuing institution manages activation or deactivation
`using the account status information. In these embodiments,
`
`50
`
`6
`a customer communicates with the intermediary service to
`direct the service to change the account status. The interme
`diary service determines the accounts issuing institution and
`provides an indication to the issuing institution of the current
`status of the account (or of the change in status). In some
`embodiments, the intermediary service provides the indica
`tion by transmitting a message to the issuing institution to
`notify it of the new status. Alternatively, the intermediary
`service may store the account status information in its own
`database. The issuing institution may then request account
`status from the intermediary service whenever it needs the
`information, such as when it receives an authorization
`request. An advantage of the issuing institution-managed
`implementation is that it allows the intermediary service to
`control account status for all uses of the account, even for
`authorization requests that do not pass through the interme
`diary service. At the same time, this implementation takes
`advantage of the fact that the customer is already registered
`with intermediary service, so that the intermediary service
`can provide verification procedures to confirm changes in
`acCOunt Status.
`In some embodiments, a customer may provide the unique
`identifying information to an online merchant via a computer
`interface. Such as via a checkout process implemented on a
`web site. The online merchant transmits the unique identify
`ing information to an acquirer (i.e., a financial institution that
`provides a clearinghouse service for consolidating financial
`transactions) in an initial authorization request. The transac
`tion is then processed by the intermediary service in a similar
`manner to transactions received from a brick-and-mortar
`merchant. Alternatively, the online merchant may bypass the
`acquirer by transmitting the information directly to the inter
`mediary service. The transaction may then be processed by
`the intermediary service as discussed above, with the online
`merchant acting in the acquirer's role.
`When sensitive account information is transmitted through
`the intermediary service from a financial institution to an
`acquirer, the account information may remain in