111111
`
`(19) United States
`(12) Patent Application Publication
`Putta et al.
`
`11111111111111111111111111111111111111111111111111111111111111
`US 20010032192Al
`
`(10) Pub. No.: US 2001/0032192 A1
`Oct. 18, 2001
`(43) Pub. Date:
`
`(54) METHOD AND APPARATUS FOR
`IMPROVED FINANCIAL INSTRUMENT
`PROCESSING
`
`(76)
`
`Inventors: Laxmiprassad Putta, Cambridge, MA
`(US); Sudhakar Durairaj, Watertown,
`MA (US); Sridhar Ramachandran,
`Watertown, MA (US); James Lowell
`Frankel, Lexington, MA (US)
`
`Correspondence Address:
`Ronald J. Kransdorf
`Wolf, Greenfield & Sacks, P.C.
`600 Atlantic Avenue
`Boston, MA 02210 (US)
`
`(21)
`
`Appl. No.:
`
`09/735,064
`
`(22)
`
`Filed:
`
`Dec. 11, 2000
`
`Related U.S. Application Data
`
`(63) Non-provisional of provisional application No.
`60/170,031, filed on Dec. 10, 1999.
`
`Publication Classification
`
`(51)
`
`Int. Cl? ............................ G06F 17/60; H04K 1!00;
`H04L 9/00
`
`(52) U.S. Cl. ................. 705/76; 705/39; 705!65; 705/67;
`705/78
`
`(57)
`
`ABSTRACT
`
`A method and apparatus are provided for issuing secondary
`programmable account numbers (SPANs) to a customer or
`customer-designated party, each of which SPANs is associ(cid:173)
`ated with a customer primary account or other financial
`instrument, and each of which SPANs has selected usage
`parameters assigned thereto. SPANs may be issued as a
`book, with usage parameters assigned to the book in addition
`to or instead of individual SPANs. When a SPAN is pre(cid:173)
`sented to a merchant for payment, the SPAN, including
`compliance with usage parameters, is verified and appropri(cid:173)
`ate action taken based on either verification or failure of
`verification.
`
`Account Registration ----~
`Start
`
`352
`
`Get the custome~s online
`login and password
`
`Get the custome~s online
`login, password and
`registration Information
`
`No
`
`Yes.
`
`Yes
`
`Retrive custome~s
`registration information
`from the primary account
`database
`
`Stop
`
`TWILIO INC. Ex. 1015 Page 1
`
`

`
`FIG. 1
`
`we.,.,-;.
`
`.._>,
`::J
`
`.!!1
`s::
`<1.1
`C1J E
`ra ua.
`en m
`E
`.e c
`
`<1.1
`
`....
`
`Programmable L. __ _
`Mod.u le
`, ·------ -· ---------·-!..- ...
`•
`
`•
`
`Payments:_ .. ______ _
`
`-----------------------------------------------------------------------------~---
`
`...
`
`I
`I
`I
`I
`I
`
`' ' I
`-ication lllte"'rtate..s
`
`Interface
`
`J
`
`Platform
`
`Switches
`
`:1ent Networks
`
`I")
`
`~ .....
`
`""C
`~ .....
`~ = .....
`~ 't:l -....
`.... 0 =
`~ -a -....
`~ ..... .... 0 =
`
`I")
`
`E-Wallets
`
`Shopping
`Aggregators
`
`0
`I")
`!"""
`'"""'
`~CIO
`N c c
`'"""'
`'JJ. =(cid:173)~
`~ .....
`'"""' 0 ......,
`'"""' ~
`
`d
`'JJ.
`N c c
`'"""' -c
`8 N
`'"""'
`'0
`N
`>
`'"""'
`
`TWILIO INC. Ex. 1015 Page 2
`
`

`
`Patent Application Publication Oct. 18, 2001 Sheet 2 of 13
`
`US 2001!0032192 A1
`
`i !
`.......................................................... _, ................. .
`
`j .
`
`C\1 .
`(.9
`LL
`
`TWILIO INC. Ex. 1015 Page 3
`
`

`
`Patent Application Publication Oct. 18, 2001 Sheet 3 of 13
`
`US 2001/0032192 A1
`
`352
`
`Get the custome~s online
`login and password
`
`No
`
`Get the custome~s online
`login, password and
`registration information
`
`No
`
`Yes.
`
`Yes
`
`Retrive custome~s
`registration information
`from the primary account
`database
`
`Enable SPANs
`
`FIG. 3
`
`TWILIO INC. Ex. 1015 Page 4
`
`

`
`Patent Application Publication Oct. 18, 2001 Sheet 4 of 13
`
`US 2001/0032192 A1
`
`Primary account
`
`101
`
`1:N
`
`SPAN
`
`1000
`
`Usage parameters
`
`Authorization conditions
`
`512
`
`511
`
`FIG. 4
`
`TWILIO INC. Ex. 1015 Page 5
`
`

`
`Patent Application Publication Oct. 18, 2001 Sheet 5 of 13
`
`US 2001/0032192 A1
`
`flot horl J~ll)) , con~ itions
`511
`
`•
`
`Vatld ct!tiit card number
`V.aUd merchant
`,
`Card not expired
`Primaf!J account has funds
`
`I
`
`M.)lJirial'\t,.. conditions c.
`512
`tls~,e P:zr3.'Pieters
`
`:-.~.-~"-~·· .. =.::'
`
`• ~
`fa co! value
`Our.alion·base:d limit
`Cr'!dit limit
`Mlltdtlntswho can accept the ca1d
`Valid dltoa of sale
`Vo!locitf. thJmbt:r of uses
`.
`E
`xpuf dJt~ set bdor~ primaf'IJ expJry dat~
`A•Jth~ntieJtion information (name. zip, r:to)
`Coll~clive restrictions
`-·- '
`
`: ..
`
`••
`
`FIG. 5
`
`TWILIO INC. Ex. 1015 Page 6
`
`

`
`Patent Application Publication Oct. 18, 2001 Sheet 6 of 13
`
`US 2001/0032192 A1
`
`DJ!Ibuu~
`
`r--
`
`-......
`;:;.
`~- [? SP/'IN
`.ot
`D-at~
`'
`3~1
`-....
`L
`-.....;.,..::::
`I+ Prlm1ry 1cc~unt
`......._ 3~2
`....,
`.........
`~ f.,.. f+ Aulhotlullon
`
`loot-
`
`.J'
`
`diii~Jit
`
`~
`
`p111mtltr
`......_4,\Jbm 3~3 .J
`
`FIG. 6
`
`101
`
`Fiunchl nt~l.c
`320
`
`ll~tlnc,lio~
`lnluhct
`~
`
`Yes
`
`Ho14f~n4sln 1111
`ptlm1ry ~~count
`forlhls
`lunuclion
`
`Up411t
`pmmtlttt on
`U1191 Of lht W4
`
`Stnd "cllnltd'
`lhrou~h lht
`lonJnciJI ntiwM
`'' IQII•Jirlng
`J)I'OOISW
`
`ObiJln
`lqlhorlullon
`eod,t(~20) 1nd
`rtcord lrmJclion
`
`Autholuiton
`eodt
`gtnmtor
`3eo
`
`Sen~ lvlhorlnllon
`codtlhrovg~
`fin1nd1l nt~'c
`lo 1cqvlrlng
`proouw
`
`llolllylht curtomu
`(1001101) lhrovgh
`no~ficJlion lnhr!Jct
`(400)
`
`;.-
`
`~ MuchJnl
`d11Jhu
`
`J
`
`-....
`
`Cvrtomu
`prtftrtncu
`
`f4- "
`' 3~4
`-/
`f+ 1-?
`..... ~JIJbut3~' - ........
`
`-..;::::::
`::;..'
`Us1gt pmmtltr
`dJtJbm
`3~e
`
`'-.
`
`'...;;:;
`T11nuaion
`dlllbJSt
`3~7
`
`........
`
`".--'
`
`__..
`
`~ I+
`.....----......·
`f.+ f+
`-- -.
`
`I"
`~ f?
`01l1bm of
`IOtnciu In lht tiC
`'- ntlt.4l<J~e
`
`-...
`
`/
`
`L.c- f-.,
`
`OlhtriMormJtion
`3~,
`
`...._ _ __,
`
`TWILIO INC. Ex. 1015 Page 7
`
`

`
`Patent Application Publication Oct. 18, 2001 Sheet 7 of 13
`
`US 2001!0032192 A1
`
`""0
`0
`
`.. :;
`.. (')
`~~
`E
`0
`~
`:;,
`u
`
`-
`
`:;)
`"1:7
`0
`
`..
`-
`e;
`aM
`c
`~
`""
`~
`
`~~
`~f<;:)
`~ccn
`C:Sti
`
`t
`
`~~
`
`•v
`
`c:
`
`0 - .. ~~N
`
`~;:"''I::f
`_oM
`-oe
`0
`:i
`
`• :;)
`
`"1:7
`0
`E~
`~M
`
`a .. (I)
`
`.
`(9 -u...
`
`f
`
`- v,
`0 -.. 0
`..
`0 ..
`
`0
`
`E ..-
`l:;
`::J u
`
`I "i\
`
`\
`
`[J
`
`,
`
`:.sl
`Eo oo
`,; ...
`:;) u
`
`\.
`'
`
`TWILIO INC. Ex. 1015 Page 8
`
`

`
`Patent Application Publication Oct. 18, 2001 Sheet 8 of 13
`
`US 2001/0032192 A1
`
`Prlm•ry Iecount
`~
`
`11Cnt~ilt
`lnltrf.Jct
`eoo
`
`Mor:llncatlon ·
`
`Yes
`
`Obbln prthllncts from
`Cllslomtr prcftrencu
`~abblst lnd 11\ose stt•l by
`lht CUriOII)IIIOOI
`
`tlo
`
`Obbln lilt modifloaUons
`rcqvtshd In authori:ulion
`Plllmtltr
`
`Nolity
`Cllrtomu
`about
`lnv1lld
`lo~ln
`
`llotlty customtr
`o~boutlht
`lnconslshncy
`
`Yu
`
`Mo4itt
`1ut~.oriz1!1on
`plrltntltr
`
`llo
`
`FIG.' 8
`
`TWILIO INC. Ex. 1015 Page 9
`
`

`
`Patent Application Publication Oct. 18, 2001 Sheet 9 of 13
`
`US 2001/0032192 A1
`
`Oahbuu3~0
`~---.....
`
`;;::;:;;-
`
`~
`
`--
`I -oil .,.. SPfU)
`I"'
`~t~""
`' 351
`.......
`! .... _.,. ~
`PrlmJry Jceount
`dahbm
`3~2
`
`Issuing rrod~
`~341
`
`(\
`
`Is lht tudomtrlogi~
`Jnd PJ~Id nlld7
`
`Yu
`
`1/o
`
`t prlmJ~ Jeeounl n
`lndwrtht PftN.j .. t
`
`·
`
`·: h ISUtd to thll
`custorntn
`
`llo
`
`Notify
`4- customu
`I bout lht
`11101
`
`,.......___
`
`Yu
`t
`
`Gtnmlt
`
`"""" SPR)J.5
`1
`
`iniUall:t
`pmmtltrs on
`UU~t,
`tranucUons. tlo
`
`T
`
`Rtdlrtctevdomtr to
`molliflcJIIon modult plulng
`lht d tl1•11t ~urtomtr
`puftrtncu 1nd tlltnt to~l
`pnlmncu
`
`f
`luut "9fA N.SJ'' •· :to
`lht cuslomu 011 sptclfltd
`oltltt through lht luulng
`lnltrfm
`
`""
`Slop
`
`)
`
`PrimJtt mount
`~00
`
`~
`
`I bht111e
`lrlltrfaee f-4+
`50
`
`)pFttJ
`genwtorwllh
`dJbbm of
`prtprocuud
`luuing lnltrfJct
`70IJ ~ nvmbtrs
`370
`
`FIG. 9
`
`.....
`
`.........
`
`~"""'_
`
`;"
`
`-.....
`[ ..... ~ AulhorluHon
`pmmtltr
`I""'""'
`~Ill bill 3~3 ......
`......
`;:.;-
`
`.
`
`......
`
`......
`... ~ Mmh,.•l
`dJIJbJU
`'- ~
`,.,.
`--....
`1-c. ~
`
`Cud4mtt
`Pllftrtncu
`~JtJbHt 3~~_...
`-...
`;::;
`l-4 ~
`Uuot pmmtltr
`dJIJbUt
`
`-
`' 3~ -"'
`, .... f•
`
`-...
`
`~
`OJ!Jbm of
`l~tlleiu In lht NC
`ntlwo~3~S
`
`I""" f._
`
`,..
`
`........
`
`--.......
`
`Olhtr Inform Ilion
`m
`_,...
`
`..._
`
`TWILIO INC. Ex. 1015 Page 10
`
`

`
`Patent Application Publication Oct. 18, 2001 Sheet 10 of 13
`
`US 2001/0032192 A1
`
`370
`
`Programmable Account Number Generator
`
`Get the account range start
`and end for programmable
`account numbers
`
`Get a random number R
`
`Set X to
`start+ R mod (end- start)
`
`351
`
`Activate the
`account in the
`SPAN Database
`
`Enqueue X to the queue of
`available programmable
`accounts
`
`Return the account
`number X
`
`Stop
`
`FIG. 10
`
`TWILIO INC. Ex. 1015 Page 11
`
`

`
`I")
`
`""C
`~ .....
`~ = .....
`~ 't:l -....
`~ .... 0 =
`~
`0' -....
`.... 0 =
`
`I")
`
`~ .....
`
`-~
`Conve~aUonaJ
`,.....____ Interaction ----l~
`
`Sevlce module
`343
`
`Customer
`100,
`
`Account query
`~--through Internet or---~~
`telephone
`
`--
`.... ~--Periodic statements---~
`
`l~uJnglmodltylng 4 SPF1/V,.j ·~­
`Account maintenance
`Customer education
`Periodlostahment preparation
`fraud and Exception handling
`Lost credit cards
`
`I .
`Negotiatmg
`exceptions
`_j_
`
`Financial netwolk .1nd
`merchant banks
`
`FIG. 11
`
`TWILIO INC. Ex. 1015 Page 12
`
`

`
`Patent Application Publication Oct. 18, 2001 Sheet 12 of 13
`
`US 2001!0032192 A1
`
`c:
`0
`
`'
`.,
`,; .. "
`·- ""
`c -....
`...
`
`IIW.OI()
`"""'M
`
`)
`
`-'"0
`
`_)
`
`I~
`
`\
`
`-4-
`
`0
`M
`
`M ..
`
`~ -o
`0
`E
`
`0
`
`<(
`
`c: I
`;::; ...
`• a or-
`.~ -0 .c. -;,
`·- M -m
`
`'OM
`
`c:
`ON
`,;U>
`·- 0
`c:
`...
`,...x
`
`.. "">(cid:173)
`.. -
`
`.
`(!J
`LL
`
`-o c ....
`... 0 0
`.,;:: · - Q)
`"'"U-,;
`" :% ..
`.. .. c:r
`c: ... c: ~
`--· --
`' -.. Q
`
`c
`·~ coo
`:=jo
`c~o:>
`! c
`41 ;: ·-0
`
`.. ~
`
`:;,
`0
`<>
`()0
`"'o
`
`,~ -.:
`~~ .. E ·--c.
`
`TWILIO INC. Ex. 1015 Page 13
`
`

`
`Patent Application Publication Oct. 18, 2001 Sheet 13 of 13
`
`US 2001/0032192 A1
`
`Single purchase authorization
`
`Customer
`database
`
`351
`
`Yes
`
`Authorize
`
`FIG. 13
`
`TWILIO INC. Ex. 1015 Page 14
`
`

`
`US 2001/0032192 A1
`
`Oct. 18, 2001
`
`1
`
`METHOD AND APPARATUS FOR IMPROVED
`FINANCIAL INSTRUMENT PROCESSING
`
`RELATED APPLICATION
`
`[0001] This application claims priority from Provisional
`Application Ser. No. 60/170,031, filed Dec. 10, 1999
`
`FIELD OF THE INVENTION
`
`[0002] This invention relates to transaction processing of
`financial instruments such as credit cards, and more specifi(cid:173)
`cally to methods and apparatus for improving the security,
`flexibility and privacy of such transactions.
`
`BACKGROUND OF THE INVENTION
`
`[0003] Since the inception of credit cards, limits have been
`set on their usage. Credit card issuing institutions place
`limits on credit cards typically to reduce overuse thereof.
`
`[0004] For example, credit cards generally have a credit
`limit set on them. Purchases made over the credit limit will
`not be accepted by the credit card issuing institution. Simi(cid:173)
`larly an expiry date can be set on a credit card to limit its
`validity. With the widespread deployment of networks to
`perform credit card processing, the use of terminal point(cid:173)
`of-sale devices to perform credit card authorizations has
`become common. Today, credit card payments are first
`authorized and later charged after the goods are shipped.
`
`[0005] Credit card issuing institutions offer flexibility to
`customers in establishing their credit card parameters, such
`as the account to be charged and monthly spending limits.
`For example, corporate credit cards offer the flexibility of
`charging payments made on a secondary credit card to its
`primary (master) credit card account. Multiple secondary
`credit cards can be issued on a primary credit card. More(cid:173)
`over, the owner of the primary credit card can impose
`constraints on the usage of the secondary credit cards, such
`as setting the monthly credit limit. The use of such cards is
`widespread in businesses and families.
`
`[0006] Customers can make credit card payments even if
`the credit card is not physically presented to the merchant.
`Orders can be placed by telephone or mail, and payments
`can be made using the credit card number, along with
`authentication information such as expiration date, card(cid:173)
`holder name as it appears on the card, billing address and in
`some cases CVV2 number. With the recent boom in online
`retailing, more customers use credit cards in such "card-not(cid:173)
`present" transactions.
`
`[0007] However, credit card payments over the Internet
`are susceptible to risk of fraud. For transactions where the
`customer physically presents the card at the point-of-sale,
`the merchant can authenticate that the card belongs to the
`customer presenting the card (for example, by comparing a
`signature to the signature on the card, by comparing the
`person presenting the credit card to a photograph on the
`card, or by asking for additional identification). But, for
`"card-not-present" transactions, the only way of authenti(cid:173)
`cating is by checking that the authentication information
`provided by the customer is correct. Though this authenti(cid:173)
`cation mechanism is often acceptable, it's by no means
`adequate. If a malicious agent manages to acquire the card
`number and the authentication information, then he can
`commit fraud very easily. The card number and authentica-
`
`tion information can very easily be obtained by breaking
`into the merchant databases. There are known instances of
`such break-ins. The cardholder will not be able to detect this
`fraud until he receives his monthly statement. Then the
`cardholder has to go through the hassle of disputing the
`transaction.
`
`In another malicious scenario, the merchant can
`[0008]
`overcharge the card. In a "cardnot-present" transaction, the
`customer has no control over the amount the merchant is
`charging. A fraudulent merchant can very easily overcharge
`the card or even charge the account twice (double charge).
`
`In another scenario, if the customer gives his card
`[0009]
`for recurring payments such as to pay an ISP, to pay for
`phone service, or to pay for newspaper or magazine sub(cid:173)
`scriptions, the service provider can charge the card on a
`periodic basis. If the customer cancels the service there is a
`risk that the service provider's billing systems are not
`updated on time and the customer's card is charged. In this
`instance the cardholder has to recognize that it's an unau(cid:173)
`thorized charge and dispute the transaction with either the
`service provider or the issuing bank.
`
`[0010] Many customers are uncomfortable making pur(cid:173)
`chases online because of the above and other reasons. Online
`shops may not succeed because of the reluctance of new
`customers to buy online.
`
`[0011] Credit card institutions have been promoting the
`use of credit cards by protecting the customers from fraud.
`In the USA, for example, the liability in case of fraud is
`limited to $50 if the customer reports the case of fraud
`properly. Although such protection improves credit card
`usage, the institutions need to bear the fraudulent charges
`made or pass them on to the merchant. Customers, on the
`other hand, need to be aware of the risk of fraudulent
`charging and must look at their monthly statements with
`care.
`
`[0012] There have been many attempts to overcome the
`problem of credit card fraud for "card-not-present" transac(cid:173)
`tions.
`
`[0013] One of the notable developments is the Secure
`Electronic Transaction (SET) protocol created by well(cid:173)
`known technology and credit card institutions. This protocol
`was developed to address the security issues of "card-not(cid:173)
`present" transactions conducted over the Internet. It involves
`the card issuing bank, the customer and the merchant and
`provides a detailed protocol for encryption of data and
`identification and certification of various parties. It's well
`published by the credit card institutions, but due to the
`investment required by the merchants, adoption has been
`limited.
`
`[0014] Another method being popularized by a number of
`credit card institutions are smart cards. Smart cards are
`credit cards with an embedded chip which can hold infor(cid:173)
`mation about the cardholder. They implement different types
`of request-response and encryption schemes to ensure secu(cid:173)
`rity. U.S. Pat. No. 5,317,636 (Vizcaino) explains how a
`typical smart card system works. Smart cards require a
`special reading device so that the information stored on the
`chip can be interpreted. This would mean changes to the
`existing point-of-sale (POS) terminals, which could be very
`costly, and can be of limited value for Internet or other
`card-not-present transactions.
`
`TWILIO INC. Ex. 1015 Page 15
`
`

`
`US 2001/0032192 A1
`
`Oct. 18, 2001
`
`2
`
`[0015] Another method is to use a system such as Digi(cid:173)
`Cash, U.S. Pat. No. 5,712,913 (David Chaum), where the
`information is split between various parties, so that no one
`database can be hacked to gain access to all the information
`required to commit fraud.
`
`[0016] Various approaches have been developed to control
`the use of the card, thereby making the card more secure.
`Japanese Patent No. Hei 6-282556 describes a system in
`which a credit card number can be used only once and in
`which personal information and use limits are recorded on
`the card. A special card-reading device reads the information
`from the card and checks if the usage conditions permit the
`card to be used. The card information will be transferred to
`the issuing institution only if the use conditions are valid.
`This system would again require changes to the existing
`POS terminals.
`
`[0017] Other approaches were developed to use proxy
`numbers instead of the actual credit card to do online
`transactions for example, U.S. Pat. No. 6,000,832, U.S. Pat.
`No. 5,833,816 (Franklin et al.). This system assumes cre(cid:173)
`ation of an electronic commerce card that is maintained for
`the customer at the bank. This online commerce card is
`assigned a real customer account number at the bank. When
`the customer wants to conduct an online transaction, the
`customer requests a transaction number from the bank. This
`transaction number is given to the merchant. When the
`merchant presents the number to the bank, the bank identi(cid:173)
`fies that the number is a proxy for an online commerce card
`and charges the transaction to the real account number. This
`number is valid for only one transaction. This is a good
`system to control fraud, but a good number of Internet
`purchases are shipped separately. In this case, the present
`system will deny the second authorization because it relates
`to a separate transaction.
`
`[0018] While security is a major concern in the use of
`credit cards, particularly on the Internet, there are also other
`concerns with the current systems. One major concern is
`privacy, credit card transactions by an individual being
`utilized by merchants and others to build up a profile on the
`individual which is used for marketing and other purposes.
`Privacy concerns are a factor limiting more extensive use of
`credit cards in connection with E-commerce and thus in
`limiting the expansion of E-commerce.
`
`[0019] Further, while existing credit cards offer some
`flexibility, as indicated above, in use of credit cards, the
`flexibility and control afforded to a user in the use of credit
`card accounts while maintaining security and privacy, is still
`fairly limited. Greater flexibility is for example desirable in
`being able to control duration and credit/spending limits on
`a card, merchants with whom the card can or cannot be used,
`number of uses, use velocity and many other factors. Fur(cid:173)
`ther, while credit card numbers are required for many types
`of transactions, including most E-commerce transactions,
`credit cards are not readily available in some parts of the
`world or to some individuals. A capability of being able to
`conduct credit card-like transactions, which may be trans(cid:173)
`parent to the merchant, from a bank checking account,
`savings account, or other financial instrument is therefore
`also highly desirable.
`
`[0020] Finally, there is a huge investment in existing POS
`terminals and in existing systems for processing credit card
`transactions. Therefore, any improvements required to
`
`address the above security, privacy, flexibility and other
`concerns should require minimum changes in existing ter(cid:173)
`minals/systems both to minimize implementations, costs and
`to facilitate rapid implementations.
`
`[0021] Therefore, a need exists for more secure, private
`and flexible methods of processing transactions and pay(cid:173)
`ments based on existing credit card processing infrastructure
`while requiring minimal changes thereto.
`
`SUMMARY OF THE INVENTION
`
`[0022]
`In accordance with the above, this invention pro(cid:173)
`vides a system and method for facilitating access to financial
`instruments such as credit and debit card accounts, checking
`accounts, bank accounts and the like. Secondary program(cid:173)
`mable account numbers (SPANs) are issued in response to
`verified customer requests, verification of a customer
`request being provided for example by a verification mod(cid:173)
`ule. Each SPAN is associated with at least one customer
`financial instrument, and each span has usage parameters
`assigned thereto. When a SPAN is presented to a party for
`payment, an authorization module receives request for
`authorization from such party. Such module may authenti(cid:173)
`cate the SPAN verify that usage parameters for the SPAN
`have been complied with, deny authorization if the SPAN is
`not authenticated or if usage parameters for the SPAN are
`not complied with, and, if the SPAN is authenticated and
`usage parameters are complied with, update usage param(cid:173)
`eters based on the authorization request, update the associ(cid:173)
`ated customer primary account/financial instrument and
`send an authorization output.
`
`[0023] More specification, the invention provides a mod(cid:173)
`ule for issuing secondary programmable account numbers
`(SPANs) to a customer, which module includes a verification
`module which receives SPAN requests and verifies the
`validity of such requests; a generating module operative in
`response to a verified SPAN request for providing at least
`one SPAN, each SPAN being associated with at least one
`customer primary account/financial instrument; a usage
`module assigning usage parameters to the SPANs; and an
`issuing module which issues each SPAN to a customer
`specified party, the issued SPAN being usable only within
`the assigned usage parameters. The invention also includes
`a method for issuing SPANs to a customer which includes
`the customer inputting a SPAN request to an issuing system;
`the system verifying at least one of the customer and the
`request; the system providing at least one SPAN in response
`to a verified SPAN request, each SPAN being associated
`with a selected customer primary account/financial instru(cid:173)
`ment; the system assigning usage parameters to the SPANs;
`and the system issuing each SPAN to a customer specified
`party, the issued SPAN being usable by such party only
`within the assigned usage parameters. Either the module or
`method may include a memory storing preferred usage
`parameters for the customer, which preferred usage param(cid:173)
`eters are used as default usage parameters for each SPAN for
`the customer. Each SPAN request may also include at least
`one usage parameter, the at least one usage parameter of the
`request being assigned to the corresponding SPAN in lieu of
`the corresponding preferred usage parameter. Where no
`preferred usage parameters are provided, the usage param(cid:173)
`eters included with the SPAN request are utilized as assigned
`usage parameters. Usage parameters can include, but not are
`not limited to, at least two of SPAN duration, SPAN face
`
`TWILIO INC. Ex. 1015 Page 16
`
`

`
`US 2001/0032192 A1
`
`Oct. 18, 2001
`
`3
`
`value, SPAN credit limit, permitted merchants, excluded
`merchants, value velocity, use velocity, period of use, and
`number of uses for the SPAN. A mechanism may be pro(cid:173)
`vided for altering at least one of the usage parameters after
`the SPAN has issued in response to a request from the
`customer and/or the party to whom the SPAN is issued.
`[0024] At least selected SPANs may be issued to a third(cid:173)
`party designated by the customer. The customer may also
`have a plurality of primary accounts or other financial
`instruments, a mechanism being provided for selecting the
`financial instrument with which each SPAN is associated.
`For some embodiments, the financial instrument selected for
`each generated SPAN is the same as the instrument selected
`for the previously generated SPAN unless the customer
`otherwise indicates, for example in the SPAN request. The
`financial instrument selected for a SPAN can also be
`changed by the customer after the SPAN has issued.
`[0025] For some embodiments, a plurality of acceptable
`SPANs are generated and stored. When a SPAN request is
`received, at least one SPAN is then provided from the stored
`acceptable SPANs. A mags tripe writing device may also be
`provided, the writing device recording a SPAN to be issued
`on a magstripe of a suitable token. A plurality of SPANs may
`also be provided and issued as for example a book to which
`the usage parameters are assigned. At least one usage
`parameter may be assigned to each book, each SPAN in the
`book being usable so long as the cumulative use of the
`SPANs for the book do not exceed any usage parameter
`assigned to the book. However, usage parameters may be
`assigned to each SPAN of the book in addition to the usage
`parameters assigned to the book.
`[0026] A SPAN may be usable to access funds from a
`customer selected financial instrument, for example a cus(cid:173)
`tomer checking account. A SPAN assigned to a check and
`may be usable as a check also as a credit card number.
`Where financial networks having given protocols utilize the
`module and method of this invention, a bridge may be
`included permitting use of SPANs across such financial
`networks.
`[0027] One usage parameter may be SPAN duration, a
`SPAN normally remaining viable for its assigned duration.
`A customer may be provided with the ability after a SPAN
`is issued to change its assigned duration. Time durations for
`SPANs may be set in relatively small time intervals, for
`example time intervals not exceeding days. The system may
`also detect the issuance of an excessive number of SPANs to
`a customer during a given time interval and/or an unusual
`pattern of SPANs request for a customer, and the system may
`at least terminate the issuing of new SPANs for the customer
`in response to such detection.
`[0028] The invention may also include an authorization
`module which receives request for authorization from a
`party to whom a SPAN, issued as indicated above, has been
`presented for payment, the module authenticating the SPAN,
`verifying that usage parameters for the SPAN have been
`complied with, denying authorization if it cannot authenti(cid:173)
`cate the SPAN or if usage parameters for the SPAN are not
`complied with and, if the SPAN is authenticated and usage
`parameters met, updating usage parameters based on the
`authorization request, updating the associated customer
`financial instrument and sending an authentication output.
`Similarly, the invention includes a method for authenticating
`
`requests for authorization from a party to whom a SPAN,
`issued as described above, is presented for payment, which
`method includes: authenticating the SPAN, verifying that
`usage parameters for the SPAN have been complied with,
`denying authorization of the SPAN is not authenticated or if
`usage parameters for the SPAN are not complied with, and,
`if this SPAN is authenticated and usage parameters are
`complied with, (i) updating usage parameters based on the
`authorization request, (ii) updating the associated customer
`primary account, and (iii) sending an authorization output.
`
`[0029] Either the authorization module or method may
`involve the person authorized to use a SPAN having a token
`which facilitates identification of the person from a remote
`site, the authorization module or system receiving informa(cid:173)
`tion from the token and utilizing such information to verify
`that the party is authorized to use the SPAN for the received
`request. The token may be a dongle, a card with a mags tripe
`or a device generating a time varying value which is
`substantially unique to an individual at each time interval.
`For some embodiments, once a SPAN is presented for
`payment to a given party, the authorization module permits
`such SPAN to be used thereafter only for payments to such
`party. A usage parameter may be the number of times a
`SPAN may be used, some embodiments treating all items
`ordered together on a SPAN as a single use, even if the items
`are shipped and/or invoiced separately. For some embodi(cid:173)
`ments, the identity of the party to whom the SPAN is issued
`is not revealed to the party to whom the SPAN is presented
`for payment and is not required either as an input or an
`output from an authentication module. One option would be
`to provide a pseudo identity for the person using the SPAN
`to the merchant or other party to whom the SPAN is
`presented for payment. The authorization module and/or
`method preferable includes at least one fraud detection
`mechanism. For example, an unusual pattern of authoriza(cid:173)
`tion requests from a party requesting such authorizations
`and/or an unusual pattern of use for SPANs previously
`received by such party may serve as an indication of
`potential fraud. At least notification to a customer over
`appropriate media may be provided of at least any suspi(cid:173)
`cious authorization request for a SPAN issued at the request
`of such customer. Where there are fraud detection programs
`in effect for the primary account/financial instrument, use of
`such programs may be facilitated by mapping SPANs to the
`corresponding financial instrument for such programs. A
`plurality of purses may also be provided for at least selected
`SPANs, each purse being for a different category of pay(cid:173)
`ments, each received authorization request for a SPAN being
`allocated to the appropriate purse.
`
`[0030] The foregoing and other objects features and
`advantages of the invention will be apparent from the
`following more particular description of a preferred embodi(cid:173)
`ment of the invention as illustrated in the accompanying
`drawings, the same reference numeral being utilized for
`common elements in the various figures.
`
`IN THE DRAWINGS
`
`[0031] FIG. 1 is a schematic representation of an illustra(cid:173)
`tive embodiment integrated with financial networks.
`
`[0032] FIG. 2 is a flow diagram of the authorization
`process that occurs when a SPAN is used in credit/debit
`transaction.
`
`TWILIO INC. Ex. 1015 Page 17
`
`

`
`US 2001/0032192 A1
`
`Oct. 18, 2001
`
`4
`
`[0033] FIG. 3 is a flow diagram of the account registration
`process.
`
`[0034] FIG. 4 is a flow diagram showing the relationship
`between a primary account and SPANs.
`
`[0035] FIG. 5 is a diagram of modifiable and non-modi(cid:173)
`fiable authorization parameters.
`
`[0036] FIG. 6 is a flow diagram of the authorization
`process.
`
`[0037] FIG. 7 is a diagram of the customer module and
`associated tools.
`
`[0038] FIG. 8 is a flow diagram of authorization param(cid:173)
`eters modification process.
`
`[0039] FIG. 9 is a flow diagram of a SPAN-issuing
`process.
`
`[0040] FIG. 10 is a flow diagram of SPAN-generation
`process.
`
`[0041] FIG. 11 is a diagram of the service module.
`
`[0042] FIG. 12 is a diagram of the integration of different
`payment methods.
`
`[0043] FIG. 13 is a flow diagram of the single purchase
`authorization.
`
`DETAILED DESCRIPTION
`
`illustrative
`the figures, an
`to
`[0044] With reference
`embodiment of the current invention is now described. FIG.
`1 is a schematic representation of the illustrative embodi(cid:173)
`ment 30 of the invention integrated with financial networks
`320 and communication interfaces 55. The illustrative
`embodiment 30 includes payment switches 305, program(cid:173)
`mable payments module 300 and an online interface 50. As
`used in this application, a module may be a software
`program or a hardware module or a combination of the two.
`Programmable payment module 300 may include a network
`of service providers, such as financial institutions, internet
`services providers, money management software providers
`and other organizations which provide support for the pro(cid:173)
`grammable payment module and its databases. In the illus(cid:173)
`trative embodiment, programmable payments module 300 is
`implemented as a stand-alone software program running on
`several computers, each containing at least one processor, a
`memory cache, at least a primary memory element and at
`least one memory disk. Online interface 50 is implemented
`as a software module that is integrated with a software web
`server (not shown) serving web pages to customers 100.
`
`[0045] Payment switches 305 interface to standard o