111111
`
`1111111111111111111111111111111111111111111111111111111111111
`US008521623B2
`
`(12) United States Patent
`Vasten
`
`(10) Patent No.:
`(45) Date of Patent:
`
`US 8,521,623 B2
`Aug. 27, 2013
`
`(54) RETURN PAYMENT CARD PROCESS
`
`(75)
`
`Inventor: Brett Vasten. Highlands Ranch. CO
`(US)
`
`(73) Assignee: Visa International Service Association,
`San Francisco, CA (US)
`
`( *) Notice:
`
`Subject to any disclaimer. the term of this
`patent is extended or adjusted tmder 35
`U.S.C. 154(b) by 0 days.
`
`(21) Appl. No.: 12/690,254
`
`(22) Filed:
`
`Jan. 20, 2010
`
`(65)
`
`Prior Publication Data
`
`US 201 1/0055057 A I
`
`Mar. 3. 201 1
`
`2007/0045403 A l *
`2007/0138299 A1 *
`2008/0044057 A1
`2008/0172316 A1*
`2008/0300895 A l
`2008/03010 II A l *
`2009/0095809 A l *
`2009/0240512 A l *
`
`3/2007 Slonecker, Jr. ................ 235/380
`6/2007 Mitra ............................ 235/492
`212008 Keller et a!.
`7/2008 Adams ............................ 705/35
`1212008 Monk
`12/2008 Monk ............................. 705/28
`4/2009 Naccache ..................... 235/380
`9/2009 Prchal et al. ...................... 705/1
`
`OTHER PUBLICATIONS
`
`"Expired Credit Card;' Jdentity-Theft-Awamess.com (Feb. 18,
`2008).•
`Thomas, H., "Thousands Exposed to Danger of Identity Theft,"
`EXPRESS. (Sep. 13. 2006).*
`Unknown, "Programs to Ensure AccLLracy of Voting Lists Making
`Strides." PR Newswire (Mar. 23, 2006).*
`Gilgoff, Heruy, •·washington Mun•a1 Lauches MasterCard Gift
`Card," Newsday, 2005 ("WAMU").'"
`International Search Report for International Application No. PCT/
`US2010/046335 dated Apr. 28,2011.6 pages.
`
`Related U.S. Application Data
`
`* cited by examiner
`
`(60) Provisional application No. 61/237,179, filed on Aug.
`26, 2009.
`
`(2012.01)
`
`(51) Lnt. C l.
`G06Q 10100
`(52) U.S. C l.
`USPC .................................. 705/30: 705/28; 705/41
`(58) Field of C lassification Search
`USPC . ... ... ... ................... ... ... ... ... ... .......... 705/28, 30
`See application file for complete search h.istory.
`
`(56)
`
`R eferences C ited
`
`U.S. PATENT DOCUMENTS
`11/2004 Hungcrpiller et al.
`6,826,548 B2
`7,172,112 B2
`212007 Bonalle et al.
`12/2010 Roscmore et al ............. 235/380
`7,850,075 B1"'
`2002/0 143655 A.l"
`10/2002 Elston et al. .................... 705/26
`112005 Smith et al. ................... 235/375
`2005/0006453 Al'"
`2005/0149544 A I "
`7/2005 Bishop et al. ................. 707/ 101
`2005/0218213 Al"
`10/2005 Rasnake et al. ............... 2351380
`2005/0247777 Al"'
`11/2005 Pitroda ......................... 235/380
`2006/0184386 Al
`8/2006 Merritt
`
`Primary Examiner - Ryan Zeender
`Assistant Examiner - Kristie A Mahone
`(74) Attorney, Agent, or Firm - Kilpatrick Townsend &
`Stockton LLP
`
`ABSTRACT
`(57)
`A payment card returned as undeliverable is processed with a
`card administration system that responds to the return of the
`payment card by setting a "returned" indicator ina data record
`of a cardholder to whom the payment card was intended for
`delivery, and otherwise maintains the cardholder's accmmt
`without change. A card handling system initiates destruction
`of the returned payment card and provides a replacement
`payment card to the cardholder if updated profile information
`of the cardholder is received witillu a predetermined time
`period, and closes the cardholder account and ren1ms any
`funds in lhe cardholder account if no updated profile infor(cid:173)
`mation ofthecardl10lder is received within the predetermined
`time period.
`
`20 C laims, 6 Drawing Sheets
`
`Cardholder
`108
`
`Can:IPun:hao"'
`(e.g. Em~
`110
`
`Page 1
`
`RMI EXHIBIT 2038
`CBM2014-00116
`
`

`

`U.S. Patent
`
`Aug. 27, 2013
`
`Sheet 1 of 6
`
`US 8,521,623 B2
`
`/ 100
`
`Card Handling
`System
`106
`
`Card
`Administration
`System
`102
`
`Cardholder
`1 - - - - - - - - t Account Records
`104
`
`Network
`112
`
`Cardholder
`108
`
`Card Purchaser
`(e.g. Employer)
`110
`
`FIG. 1
`
`Page 2
`
`

`

`U.S. Patent
`
`Aug. 27, 2013
`
`Sheet 2 of 6
`
`US 8,521,623 B2
`
`Workstation
`202
`
`Destruction Module
`204
`
`Messaging Module
`206
`
`Card Replacement
`Module
`208
`
`Update Module
`210
`
`Communications Module
`212
`
`Web Interface Module
`214
`
`Card Administration System
`102
`
`FIG. 2
`
`Page 3
`
`

`

`U.S. Patent
`
`Aug. 27, 2013
`
`Sheet 3 of6
`
`US 8,521,623 B2
`
`START
`
`Update status of the prepaid card to "returned" as undeliverable
`to cardholder
`
`302
`
`Initiate destruction of the returned prepaid card.
`
`304
`
`Send notification to the cardholder that the prepaid card was
`returned.
`
`306
`
`Send notification to the card purchaser that the prepaid card
`was retu med.
`
`308
`
`~,.
`
`Updated cardholder profile
`data received within reply
`time period?
`
`310
`
`YES
`
`NO
`
`~
`
`Close cardholder
`account and return any
`funds associated with
`the account.
`
`312
`
`Send replacement card
`to the cardholder per
`the updated profile
`data.
`
`314
`
`FIG. 3
`
`Page 4
`
`

`

`U.S. Patent
`
`Aug. 27, 2013
`
`Sheet 4 of 6
`
`US 8,521,623 B2
`
`,-----(cid:173)
`' .
`-
`(1'-· -
`-
`--_-...:;
`•,
`iii~~~:J
`!Jo -~ ·fu~ ..
`"0Meol81rtil
`ll'lt1-~ ·fff1) :
`.--....:------
`r~--~------- -. -,
`e .... ~~ u .... .-~
`r:_---==---=-..::-..:-::-__-_-- --· -,
`c.~I'W'Ittft•l
`Addrc u :
`11f!i5MftV@MIM§fl.f.ifi I
`,.,...,,.o. ( .. ,.. &t•tu•:
`
`. Plt,on.l (cid:173)
`
`t
`
`••tu~c.:
`
`$-t$:
`
`, •••• ;.,~r;
`
`.. ~ n"t•4e.; ~,._'i3~:!~()!- _
`·- jHo.~~::a
`
`406
`
`FIG. 4
`
`Page 5
`
`

`

`VISA
`
`Undeliverable Cards
`
`Undeliverable cards will be held in returned status
`until the Destroy date. Once an undeliverable card
`is destroyed, the cardholder account will be closed
`
`Report Data
`rerteo~.---~~~r~~~~tHX.l<-8'.-iiD:Oi':J:';inan"'"
`~]yro __ _ __
`.
`;:ernplo_yt:frf.!:o~tion':f23 ~.,2..,
`,!JD ;t;Jat~;~ -~ ~'"'.)~/i4/20Q,21..7;9.1,.,<f." ..• ;
`ii'ag&!J.,.. r,y_;,;.;,_., .m:. of 1 ·--;.G· i'i.:ts"'¥'.Jt 5. ;ij
`
`~
`~
`
`~
`rJ1 .
`"""" n> = """"
`> :=
`
`~
`N
`_;...}
`N
`0
`1-'
`!.H
`
`FIG. 5
`
`('D
`('D
`
`rJ)
`::r
`.....
`t.ll
`Q ....,
`
`0\
`
`d
`(J)
`QO u.
`
`N
`~
`~
`N
`(H
`o:;
`N
`
`Page 6
`
`

`

`U.S. Patent
`
`Aug. 27, 2013
`
`Sheet 6 of 6
`
`US 8,521,623 B2
`
`1/0
`Controller
`614
`
`System
`Memory
`622
`
`Central
`Processor Unit
`620
`
`Printer
`604
`
`A
`
`'\j
`
`/ 602
`
`=>
`
`Display
`Adapter
`612
`
`External
`Port
`616
`
`Keyboard
`606
`
`Data Media
`Drive
`608
`
`Communication
`Interface
`618
`
`Monitor
`610
`
`\600
`
`FIG.6
`
`Page 7
`
`

`

`US 8,521 ,623 B2
`
`1
`RETURN PAYMENT CARl) PROCESS
`
`CROSS-REFERENCE TO RELATED
`APPLICATIONS
`
`111is application claims the benefit of U.S. Provisional
`Application Ser. No. 61/237,179 entitled "Return Payment
`Card Process" by Brett Vas ten filed Aug. 26, 2009. Priority of
`the filing date is hereby claimed, and the disclosure of the
`Provisional Application is hereby incorporated by reference. 10
`
`5
`
`2
`or card administration system as to when a payment card has
`been retmned and what the updated mailing address data
`should be, fi.lrther complicating the re-maiJing process and
`delaying when the destmction of returned payment cards may
`take place.
`What is needed is an improved technique for handling
`returned payment cards to reduce inconvenience to cardhold(cid:173)
`ers, reduce overhead to card sources. and ensure continued
`service with current cardholder infor;nation.
`
`SUMMARY
`
`BACKGROUND
`
`A payment card retumed to a card source as undeliverable
`is processed by a card administration system that responds to
`the return of the payment card by setting a returned flag in a
`15 data record associated with an account of a cardholder to
`whom the payment card was intendt:d for delivery, and oth(cid:173)
`erwise maintaining the cardholder's accoum status as active.
`Thus. the status of the payment card currently in the posses(cid:173)
`sion of the cardl1older is unchanged. A card handling system
`20 can initiate destmction of the returned payment card without
`delay. The card handling system provides a replacement card
`to the cardholder if updated profile infonnation of the card(cid:173)
`holder is received within a predetern1ined time period, and
`closes the cardholder account and retums any funds in the
`25 cardholder account if no updated profile information of the
`cardholder is received within the predetermined time period.
`T hus, the cardholder is not inconvenienced by inactivation
`without warning and the card source is not forced to store
`returned cards.
`The processing described herein will allow an issuer or
`30 other source of the payment card to cor1figure their progr<tm
`such t!Jat when an upgraded or replacement card is marked as
`returned. it will not affect the current payment card in the
`possession of the cardl1older.Al1 other returned payment card
`processing may remain unchanged from current practice.
`Additionally, in a company program, effort is made to alert
`both the cardholder and the employer that the cardl1older
`profile needs to be updated with a valid mailing address. This
`is accomplished via a new report and new e-mail messaging.
`Finally, a new configuration parameter allows new card num-
`40 bers to be generated for re-mailed replacement cards. This
`will allow the Issuer to eliminate the storage controls for
`returned payment cards.
`Other objects and advantages of the present invention will
`be apparent to one of ordinary skill in the art upon review of
`45 the detailed description of the present invention and the
`i.ncluded figures.
`
`BRIEF DESCRIPTION OF THE ORA WINGS
`
`FIG. 1 is a block diagram of an exemplary system that
`performs the processing described herein for the handling
`renrrned payment cards.
`FJG. 2 is a block diagram that shows components of the
`card administration system of FIG. 1.
`FIG. 3 is a flow diagram that illustrates the processing
`55 performed by the card administration system of FIG. I .
`FIG. 4 is a screenshot from a computer display of the FIG.
`1 system, showing a data record for a cardl1older.
`FJG. 5 is a screenshot from a computer display of the FIG.
`1 system, showing a user interface for data records of returned
`60 payment cards.
`FIG. 6 is a block diagram of a computer apparatus in the
`card administration system of FIG. 1.
`
`A variety of portable consumer devices, typically called
`payment cards, can be purchased by a first entity (the "card
`purchaser" or "card source") for the benefit of a second entity
`(the "cardholder") and loaded with a desired amount of
`money thereon. The card is associated with a cardholder
`account against which the cardholder can accumulate charges
`from purchase transactions and make payments. The card
`purchaser can then have the payment card mailed to the
`cardholder. Such payment cards are often referred to as pre(cid:173)
`paid cards or debit cards. l n a company-sponsored prognllu,
`the card purchaser may be the employer of the cardholder.
`Credit cards are another well-known fonn of payment card,
`comprising portable consumer devices that can be used for
`payment. Credit cards are associated with a cardholder
`account against which the cardholder can accumulate charges
`from purchase transactions and make payments.
`Conventionally. these payment cards are mailed to the
`respective cardholder via regular mail, such as through the
`U.S. Postal Service so the cards are physically received by the
`cardholder. lf the cardholder changes his or her mailing
`address before receipt, the mailed payment card may not
`reach the cardholder and instead may be returned by the 35
`Postal Service due to the old or invalid mailing address. The
`sender (i.e., card source) to whom the payment card is
`returned may comprise the issuing bank, the payment card
`company, the cardholder's employer, or some other card
`administration system associated with the payment card.
`When a payment card is returned, the card number associ(cid:173)
`ated with the payment card is entered into data records of a
`card processing system. The system determines if the pay(cid:173)
`ment card that has been returned is an upgraded card (i.e., a
`card that is pending activation). If so. the system will force the
`activation of the upgraded card and then it will change the
`payment card status to "Retumed". The retumed payment
`card is kept for a time to await re-sending or, eventually, to be
`destroyed. The activation of the upgraded card forces the
`status of the payment card currently in possession of the 50
`cardholder to be "inactive". Because the cardholder's current
`payment card is not active anymore, that payment card can no
`longer be used. 1l1at is, at approximately the moment the
`cardholder's current payment card is set to "inactive", that
`card cannot be used. Such a situation can be a great inconve(cid:173)
`nience to the cardholder and may occur with no wamiug. A
`s imilar situation exists for cards associated with new
`accounts, though the results are not as severe, because the
`inactive status occurs before the cardholder obtains posses(cid:173)
`sion of a payment card.
`In addition, retumed payment cards cause a large overhead
`because of the need to securely store the returned payment
`cards pending resolution of their stams before they are
`destroyed. The payment cards must be retrieved from the
`secure storage to be re-mailed to an updated mailing address 65
`or to be destroyed. Moreover, it can be di fficultto have prompt
`communication between the cardholder and the card source
`
`DETAILED DESCRIPTION
`
`As used herein, the tenn "card" or "payment card"
`includes, but is not limited to, for example, credit or debit
`
`Page 8
`
`

`

`US 8,521 ,623 B2
`
`3
`cards, bank cards, prepaid, preloaded, or prefunded cards,
`such as general purpose reloadable cards, travel cards, payroll
`cards, teen or sn1dent cards, commercial cards, gift cards, or
`any other type of preloaded, prefunded, or prepaid conven(cid:173)
`tioual payment card that a customer can use i11lieu of a cash 5
`payment, and these tem1s are used interchangeably herein.
`Such cards are examples of portable consumer devices which
`may also include phones, key fobs, personal digital assistants,
`pagers, smart media, transponders, and other sujtable
`devices.111e tenn "transaction" includes, but is not limited to, 10
`bill pay, point-of-service purchase, ATM withdrawal, balance
`inquiry, or any other purchase-type activity through payment
`card usage. 1l1e term "cardholder" includes, but is not linllted
`to, for example, a cardholder of any type of payment card (as
`thattenu is used herein), a customer, or an accom1t bolder, and 15
`these terms are used interchangeably herein. The term
`"acquirer" includes, but is not linlited to, the merchant's
`payment processor or the merchant's bank or financia l insti(cid:173)
`tution who acquires transactions from merchants and routes
`messages, authorizations, or clearing drafts betwt.-en mer- 20
`chants and a payment card processing network, and these
`terms are used interchangeably herein. The term "issuer"
`includes but is uot limited to a bank or other fina ncial insti(cid:173)
`tution that issues the payment cards. The tenn "processing
`network" or "network" includes but is not limited to an elec- 25
`troruc payment system, or any conventional network or sys(cid:173)
`tem for authorizing or processing electroruc payments.
`FIG. 1 is a block diagram that shows a prepaid returned
`card processing system 100 having a card administration
`system 102 that includes computer equipment for authorized 30
`system users to carry out the processing described herein. The
`system users can access data records 104 of cardholder
`accounts to determine cardholder address information, card
`status, and the like. The card administration system users can
`commtmicate with a card handling system 106 that performs 35
`tasks associated with mailingpaymentcards to cardholders as
`well as destroying mailed payment cards that have been
`returned as Lmdelivemble, aud con·esponding data updates.
`Once a payment card is returned as undeliverable, a notifica(cid:173)
`tion of the return can be sent from the card administration 40
`system 102 to the cardholder associated with the returo.ed
`payment card to request updated mailing address infonna(cid:173)
`tion. If desired, the notification can also be sent to the card
`purchaser 110, such as the cardholder's employer, to alert
`them of the returned card and of the need for updated card- 45
`holder information. The commurucations between the card
`administmtion system 102 and the cardholder 108 and card
`purchaser 110 can take place over a computer network, such
`as via e-mail systems over the Internet. The card admirustra(cid:173)
`tion system can be provided and maintained by the issuer or 50
`other card source, who is responsible for maintaining a cur(cid:173)
`rent balance on the payment card and interfacing with mer(cid:173)
`chants and others who accept the payment card as payment
`for goods and services.
`The card admiillstration system 102 may be used by an 55
`authorized customer service representative of the issuer or
`card source in viewing information related to a cardholder's
`account and maintainiug associated data.ln one example, the
`card admirustration system 102 can comprise one or more
`computers with software applications configured to provide 60
`various graphical user interfaces, display screens, and cou(cid:173)
`trols for a person such as a customer service representative to
`access cardholder account information. The card admirustra(cid:173)
`tion system software may be configured to communicate, via
`a network if desired, with one or more cardholder account 65
`databases I 04, which maintain and store account infonnation
`fora plurality of cardholders. For example, when a cardholder
`
`4
`coutacts an authorized customer service representative of the
`issuer (e.g., via telephone), the customer service representa(cid:173)
`tive accesses the cardholder's account information via the
`card administration system 102 and can view one or more
`cardholder pro file display scrt.-ens as des ired . One exam pie of
`a cardholder profile screen is illustrated in FJG. 4, described
`further below.
`The card administration system 102 may be configured to
`provide the authorized customer service representative with
`the ability to input data or associate infom1ation with the
`cardholder's account. The card adminjstration system may
`also include one or more controls, which may be utilized by
`the authorized customer service representative order to dis(cid:173)
`play profile screens, input data, or perform other functions
`that may be desired depending upon the particular implemen(cid:173)
`tation. In one example, information entered by the authorized
`customer service representative relating to a cardholder's
`account is transmitted by the card admirustration system 102
`to the account databases 104, where such infom1ation can be
`stored.
`The card administration system 102 may also be acces(cid:173)
`sible, for example in a limited na111re, by individuals such as
`persons (e.g., mail room personnel of the card source or
`issuer) that handle rettmled mail such as retumed payment
`cards received from the postal service. lu one example, the
`card admirustration system 102 can include one or more
`computer graphical user interfaces for use by individuals such
`as mail room persoru1el, when handling returned payment
`cards. For instance, one or more controls may be provided
`that permit mail room personnel, upon receipt of a returned
`payment card that has been marked "ret11rn to sender", to set
`the value of a data flag or indicator associated with a card(cid:173)
`holder account indicating that the payment card was returned
`due to an invalid mailing address. 1l1e card adm inistration
`system 102 may provide a user interface with an address entry
`field for entry of any forwarding address indicated on the
`renrrned payment card mail package. Other status flags or
`indicators can be used, such as a returned flag of a data record
`indicating that the cardholder address associated with the
`account is an old/incorrect/bad/invalid address.
`The card administration system 102 may commurucate
`with the card handling system 106, which may be imple(cid:173)
`mented as a list, database, or other data structure. The card
`handling system can be configm·ed to assist iu managing the
`handling of returned payment cards for destn1ction, and may
`perform one or more additional operations described herein,
`depending upon tbe implementation. In particular, returned
`paymeut cards are uot kept in secure storage, rather, they are
`processed fordestmction immediately upon receipt. When an
`authorized user enters a payment card number as returned, the
`system 102 sets a re111rned flag in a data record associated
`with an account of a cardholder to whom the payment card
`was intended for delivery. ·n1e system otherwise maiutains
`the cardholder's account status as active. Thus, the status of
`the payment card currently in the possession of the cardholder
`is unchanged, and tbe system will not affect use of the pay(cid:173)
`ment card curreutly in the possession of the cardl1older. 'J11at
`is, unlike conventional returned card processing systems, the
`returned card will not be inlmediately activated and the card
`in the possession of the cardholder will not be immediately
`deactivated by the system described herein. Most all other
`returned payment card processing of conventional systems
`will remain intact, except as noted herein.
`Exemplary Components
`FIG. 2 is a block diagram that shows components of the
`card administration system 102 of FIG. 1. The card adm inis(cid:173)
`tration system may include data processing subsystems, net-
`
`Page 9
`
`

`

`US 8,521 ,623 B2
`
`5
`works, and operations used to support and deliver payment
`card services, card destmction services, messaging services,
`data update services, and payment card replacement services.
`FIG. 2 shows the card administration system 102 as including
`a workstation computer 202. The workstation computer is
`typically a desktop computer, a laptop computer, a large
`mainframe computer. or a cluster of computers that function
`as a unit. In one example, the workstation computer 202 may
`be a database server coupled to a Web server. The workstation
`computer 202 also may comprise a desktop computer used by 10
`an authorized person to colllJntmicate with a server computer,
`wherein the desk1op computer and server computer have a
`similar constmction as illustrated in FIG. 2 and arc both part
`of the card administration system 102.
`The workstation computer 202 may include programming
`code for causing a processor of the computer to implement a
`method comprising (a) receiving a card number at a computer
`of a card administration system for a retumed payment card
`comprising a payment card that was iutcudt:d for use in con(cid:173)
`nection with a cardholder account having a current payment
`card, (b) determining that the card number of the remrned
`payment card is associated with an upgrade card or a replace(cid:173)
`ment card in a card database of the card administration sys(cid:173)
`tem, (c) setting a "retumed" indicator of a data r€-'COrd for the
`returned payment card in the card database of the card admin(cid:173)
`istration system and indicating that the re11101ed payment card
`is to be destroyed, and maintaining a status of the cunent
`payment card in the card database without change, and (d)
`generating data for producing a return-replacement paymellt
`card associated with the cardholder account if' updated profile
`information of the cardholder account is received at the com(cid:173)
`puter of the card administration system within a predeter(cid:173)
`mined time period, and closing the cardholder account and
`returning any fimds in the cardholder account if no updated
`profile information of the cardholder account is received
`within the predetermined time period.
`111e returned indicator may comprise a flag that is set or not
`set, to indicate that a card has been returned as undeliverable,
`or has not been returned. The "ret11med" flag may comprise,
`for example, an additional column in a list or table of a data
`record for a cardholder account or payment card. A
`"retumed" nag value of zero can be the default value, which
`is set to "1 "or a non-zero value to indicate the corresponding
`payment card has been ret11rned.
`Implementing
`the
`"ret11rned" flag as an additional column of a data table pro(cid:173)
`vides the additional functionality described herein with mini(cid:173)
`mal change to data stn1cnrres of the system l 02 and facilitates
`leaving the payment card status unchanged even when the
`card is ret11rned.
`The workstation computer 202 of FIG. 2 may also include
`programming code to implement a method further compris(cid:173)
`ing determining that the cardl1older account indicates that the
`cardholder account is associated with both an upgrade card
`having a set "remmed" flag and a replacement card having a 55
`set " returned" flag, w herein generating data for producing a
`return-replacement payment card comprises generating data
`for producing a retum-replacement payment card only for the
`upgrade card and not for the replacement card.
`The workstation computer 202 of FIG. 2 may also include 60
`prognmuning code that comprises a variety of .flU1clional
`modules. TI1e functiona l modules may comprise a destruction
`module 204, a messaging module 206, a card replacement
`modllle 208, an update module 210, a communications mod(cid:173)
`ule 212. and a Web interface module 214. Each of these 65
`modules may comprise any suitable combination ofhardware
`and/or soHware to perform tbe ftmctions described herein.
`
`6
`TI1eworkstation computer202 ofFlG. 2 includes program(cid:173)
`ming code that implements a destmction module 204 that
`initiates processing for destn1ction of a returned payment
`card. The destmction processing may include, for example,
`5 sending a notification message to personnel to request or
`authorize physical destruction of a returned payment card.
`The destmction processing also may include sending a mes(cid:173)
`sage to confirm that destruction has taken place. and/or initi-
`ating a database update for records to reflect the destruction.
`11Jeworkstationcomputer 202 ofFIG. 2 includes program-
`ming code that implements a messaging module 206 that
`generates and processes messages for the cardholder and/or
`purchaser relating to the renrrned payment card. For example,
`the messaging module facilitates sending a notification mes-
`15 sage to a cardholder at the cardJJolder address for the card(cid:173)
`holder account as to the renrrned stams of the remmed pay(cid:173)
`ment card. The notification message may include a request to
`the cardholder for updated cardholder information. such as
`residence address, email address, and/or correspondence
`20 address. ll1e messaging module 206 can also facilitate send(cid:173)
`ing a notification message to a purchaser at a purchaser
`address for the retllrned payment card or other designated
`notification address to provide information as to the renLrDed
`stat11s o f the returned payment card. ll1e messaging module
`25 206 may be configured to send notification messages in the
`form of SMS messages, text messages, e-mail messages,
`automated voice messages, and the like to the cardholder
`and/or card purchaser.
`ll1eworkstation computer 202 ofFIG. 2 includes program-
`30 ming code that implements a card replacement module 208
`that facilitates generating data for producing a rei1Jrn-replace(cid:173)
`ment payment card associated with the cardholder account in
`response to receiving updated profile iuJormation of the card(cid:173)
`holder account within a predetenuined time period. TI1e card
`35 replacement module operates to ensure that the generated
`data includes a card number for the remm-replacement card
`that is different from the card number of the ren1med payment
`card. Ensuring that retmned payment cards are destroy€.'<1 and
`ensuring that replacement cards have different numbers from
`40 the destroyed cards helps reduce incidents of fraud and
`improves record keeping for the system 102.
`The workstation computer 202 of FIG. 2 includes program(cid:173)
`ming code that implements an update module 210 that facili(cid:173)
`tates updating an account database of the card administration
`45 system to reflect the card number for the return-replacement
`card as having been sent and to reflect the destroyed status of
`the retumed payment card. TI1e update module 210 may be
`configmed to process update inJom1ation received and/or
`input from the system user and/or from the cardholder and/or
`50 from the payment card purchaser. such as updated cardholder
`information, cardholder status information, payment card
`purchaserinfom1ation, account information, and the like. TI1e
`update information may be received and may be stored i11 the
`database of the cardholder account records 104 and the card
`handling system 106.
`Theworkstationcomputer 202 ofFIG. 2 includes program(cid:173)
`ming code that implements a communications module 212
`that facilitates communication between the workstation com(cid:173)
`puter and other components of the system lOO. For example,
`the communications module can provide necessary interfaces
`for network couummications with the database of the card-
`holder account records 104 and the card handling system106,
`if those components are implemented separately from the
`workstation computer 202. The card administration database
`of the cardholder account records 104 and the card handling
`system 106 may alternatively be implemented as modules
`comprising programming code of the card administration
`
`Page 10
`
`

`

`US 8,521 ,623 B2
`
`7
`system l 02 that provides the operations of the database of the
`cardholder account records 104 and the card handling system
`106 as described herein.
`The database of the cardholder account records 104 and the
`card handling system 106 may store any suitable type of 5
`information to faci litate performance of the operations
`described herein. Suitable information that may be stored in
`the database system 104. 106 may include cardholder name
`and address infom1ation, payment card purchaser (e.g.
`employer) name and address iufonuatiou, payment c<trd sta- 10
`nts information, and cardholder account information. Other
`information that may be included in the database 104, 106
`may include other operational and maintenance information
`for the system 100.
`11H:workstation computer202offlG. 2 includes program- 15
`ming code that implements a Web interface module 214 that
`facilitates operation with a Web site, through wruch opera(cid:173)
`tions such as data update, messaging, card replacement
`authorization, and destmction processing may be initiated,
`authorize-d. and controlled. The drawings described further 20
`below include an exemplary Web site display window screen
`shot as provided through the Web interface module 214. The
`Web interface module may comprise, for example, a Web
`browser and Web site maintenance applications. In addition,
`the Web interface module may be use-d by a system user to 25
`provide updated information to the system, and may be used
`by a system user to initiate or acknowledge messaging, as
`well as initiate and authorize payment card processing opera(cid:173)
`tions.
`Thus. the workstation and programming code of the work- 30
`station computer 202 enable operation of the card adminis(cid:173)
`tration system 102 such that, when an authorized user of the
`system enters the rctu.rn<.'C! payment card number into an
`appl ication interface for programming code executi ng on the
`workstation. a server computer 202 of the card administration 35
`system 102 detects whether the card being returned is au
`upgraded card or a replacement card (i.e., a card that is pend(cid:173)
`ing activation). If the returned payment card is an upgraded
`card or a replacement card, then the server computer will set
`the value of a data flag or indicator associated with a card- 40
`holder account to indicate that the payment card was returned.
`Other processing may apply to a payment card that is not an
`upgraded card or replacement card. Thus, for an upgraded
`card or replacement card that has been returned as undeliver(cid:173)
`able. the system 102 will not change the status of the payment 45
`card in the possession of the cardholder, and therefore the
`cardholder is not inconvenienced by deactivation without
`warning.
`The workstation and programming code of the workstation
`computer 202 also will enable operation of the card admin(cid:173)
`istration system 102 to facilitate issuer configuration of the
`payment cards produced under their payment card program
`such that when an upgraded paymen