US 20110066550A1
`
`(19) United States
`(12) Patent Application Publication (10) Pub. No.: US 2011/0066550 A1
`
` Shank et a1. (43) Pub. Date: Mar. 17, 2011
`
`
`(54) SYSTEMAND METHOD FOR A SECURE
`FUNDS TRANSFER
`
`(52) US. Cl. ............. 705/43; 705/44; 701/300; 701/213;
`455/412; 455/41.1; 455/466
`
`(76)
`
`Inventors:
`
`(21) App]. No.:
`
`Clinton L. Shank, Dallas; TX
`(US); Mark A. Brousseau, York,
`PA (US)
`12/560,750
`
`(22)
`
`Filed:
`
`Sep. 16, 2009
`
`Pubhcatlon Class1ficat10n
`
`(51)
`
`Int. Cl.
`G06Q 40/00
`G06Q 20/00
`G01C 21/00
`H043 7/00
`H0413 5/00
`H04 W 4/00
`
`(2006.01 )
`(2006.01 )
`(2006.01)
`(2006.01)
`(200601)
`(2009.01)
`
`(57)
`
`ABSTRACT
`
`According to one embodiment, a gateway receives a transac-
`tion from a first device in local communication with a second
`
`device. The transaction includes a payment amount and a
`plurality of authorization codes. The gateway uses the autho—
`rization codes to authorize the transaction and to determine an
`account for each device. The gateway then instructs an
`account manager to Withdraw the payment amount from the
`account ofthe first device and to deposit it into the account of
`the second device. A result is received at the gateway, and the
`gateway sends the result to each device.
`
`BILLINCDEVICE
`
`12b
`» 202a
`
`204
`
`123
`2021)
`
`PAYINGDEVICE 14\-15a PAYINGBANK
`LOGIN
`‘
`II
`I
`1
`
`16b
`
`/ 200
`
`I
`
`206
`L _ _ _ _ PE%B%§TPE\QCE LD_ _/_ _ +
`, , h J92 EfT_D_E\_"9F_”L ,,,,,,
`/y
`ESTABLISH PEER—TO—PEER CONNECTION
`
`
`
`
`
`
`
`208
`
`214
`216’
`
`SEND ACTIVE BILLS
`210 (T
`hj—-fi——~—>
`212
`, .
`ACCEET BILL
`,U’—-—i
`SEND "PAY TO" INFORMATION
`. 7w——~
`OPEN CONNECTION
`72/0
`’
`
`CONgvPEECNmV 218
`I
`I
`
`PAYMENT
`PAYMENT TRANSACTION
`TRANSACTION 224
`INFORMATION
`flf *% INFORMATION
`
`230
`NOTIFICATION
`
`232
`NOTIFICATICN AND
`<
`5
`AND KEY UPDATE
`‘
`K‘
`KEY UPDATE
`
`222
`
`RESIJLT
`
`228
`
`‘
`.
`I
`I
`
`
`
`PAYMENT
`f4
`926
`
`‘
`
`934/
`
`RELEASE
`
`RELEASE
`
`238
`\
`
`-
`
`7
`RELEASE
`‘——<:\ 236
`
`Google LLC v. RFCyber Corp. / Page 1 of 20
`
`GOOG-1011
`
`GOOG-1011
`Google LLC v. RFCyber Corp. / Page 1 of 20
`
`

`

`Patent Application Publication Mar. 17, 2011 Sheet 1 0f 10
`
`US 2011/0066550 A1
`
`10
`/
`
`
`
`
`
`
`
`
`
`
`(ACH)ORCHECK
`
`ELECTROPHC
`
`BHLERSBANK
`
`PAYERSBANK
`
`I7l(}. 1
`
`
`
`LOGIC
`
`PROCESSOR
`
`MEMORY
`
`44
`
`40
`
`APPUCANONS
`
`3—4
`
`INTERFACE
`
`JFTII:?. L?
`
`Google LLC v. RFCyber Corp. / Page 2 of 20
`
`GOOG-1011
`
`GOOG-1011
`Google LLC v. RFCyber Corp. / Page 2 of 20
`
`

`

`Patent Application Publication
`
`Mar. 17, 2011 Sheet 2 0f 10
`
`US 2011/0066550 A1
`
`
`
`
`
`
`
`36?:85mmmmQ:wmcomsoo$.28;
`
`
`
`mmmmx\fl22%own”.5233“m.0:.0IEEE\Em.0“WW8$555nag
`
`
`
`mm.Emaoa:5658:9:m8“me:
`
`ES$ch2:Ba:Ermam2263m
`
`50E2:.89582,So3%gm:mgE:53:5»$5E830>=.Emaoa
`
`
`
`So5oczmeozaa25:8Em
`
`2:8QEWQBES6am:E250
`
`LEEmez5:95282Swan95E5%2:$255SEESmm;
`
`
`
`22EB:88:382:$2228
`
`YES53.mmmuom82.,Em£8335
`
`
`
`//»{NfizJ@CA»KWQWm
`
`
`
`_>_<mmum
`MW52Emma
`
`om
`
`_>_<mmnm
`
`SEEK
`
`3geommmmQB3703
`
`
`
`tobmhgmmm%
`
`mm.ooG
`02fo3e9aPla.roCrebV.CFRv.CLLb9ooG
`
`GOOG-1011
`Google LLC v. RFCyber Corp. / Page 3 of 20
`
`
`
`
`
`
`
`
`
`

`

`Patent Application Publication
`
`Mar. 17, 2011 Sheet 3 0f 10
`
`US 2011/0066550 A1
`
`32.85mmGfi<Emma
`
`
`
`
`
`vmmomoz»___IEqmco“EN3me55
`
`
`
`
`
`325;m2.“mEmz
`
`9::53
`
`SEcommomhm:E3“
`
`0::Em:
`
`wwocmiwow
`
`
`
`
`
`NZLWE52mwmfiMwmfiv<
`
`
`
`NEW5%maramen?
`
`
`
`
`
`Hmcfiwmuummucfiu:n__m_>_mEtc:
`
`
`
`
`
`
`
`
`
`vmmr-§mm-mmm<5
`
`¥kv.»by¥EQHCWIGI
`
`
`
`¥¥¥1bn¥n.Uhogwwml
`
`5;:”€025,me
`
`EmEmEocE;E:22:?:39E35E;:msfi:<.2583So282952
`
`
`
` cozméum2:52m«85%m>onm9:EEm30>8:0.cozmgaamBESEES9cm»:__;>:3REi;3:951.
`
`
`
`campmm:coszSE63:853
`
`
`
` 2595a3:282@88m2:5>3,
`
`
`
`cmES,__m_>_mcm352%newas23:33:3coszBE9:Egg25
`
`SELE.2;9E339E562%
`
`gm.mwmooa8m93mm_3%szme
`
`
`
`Bmano533$8083SEE/ca
`
`.EE%$35$2959:E93amum
`
`mGooG
`o2fO4e9aPla.rOCrebV.CFRv.CLLb9OOG
`
`
`
`
`
`Ecfim©mmu§£”=me$8:
`
`«$8oz.2:635“EN2%.35
`
`GOOG-1011
`Google LLC v. RFCyber Corp. / Page 4 of 20
`
`
`

`

`Patent Application Publication
`
`Mar. 17, 2011 Sheet 4 0f 10
`
`US 2011/0066550 A1
`
`32ooumwmbmh<Emma
`
`mat.
`
`5582528a35:g
`
`HDan
`
`
`
`
`
`
`
`
`
`
`
`
`
`ES5%2:63:852522
`
`:53;”98>QOEmu:qu
`
`qmmwhmmvmmfi«wE88<:85E2.:
`
`
`
`11:11:11EBB
`
`«.‘1¥¥¥¥¥¥*¥
`
`”Eo‘smwmm
`
`
`
`
`
`
`
`3x85
`
`mmmooooCgmxcwm
`
`9285
`
`85wa
`
`EE:2
`
`
`
`
`
`
`
`
`
`
`
`
`
`EEES
`
`
`
`
`
`0::5m:9538£5.83
`
`
`
`mmNONE
`
`mm.ooG
`02fo5e9aPla.roCrebV.CFRv.CLLb9ooG
`
`GOOG-1011
`Google LLC v. RFCyber Corp. / Page 5 of 20
`
`
`
`
`

`

`Patent Application Publication
`
`Mar. 17, 2011 Sheet 5 0f 10
`
`US 2011/0066550 A1
`
`
`
`_>_<Comm
`
`9:25
`
`8SEEma.
`
`
`
`$333925
`
`SEcommomhmbxEgan
`
`
`
`
`
`
`
`
`
` mExomsoGum/‘10”E28041
`
`
`
`
`
`
`
`Amcocv”a;
`
`
`
`
`
`
`
`
`
`
`
`EEO®mw<i“2:82
`
`
`
`
`
`ӣ53Emgmm
`
`
`
`
`
`
`
`
`
`
`
`
`
`93m#
`
`222::5m59:25
`
`®
`
`
`
`
`
`
`fixfi
`
`
`8558
`
`
`
`mzsfima258$
`
`
`
`CM.UNHN
`
`mm.ooG
`02fo6e9aPla.roCrebV.CFRv.CLLb9ooG
`
`GOOG-1011
`Google LLC v. RFCyber Corp. / Page 6 of 20
`
`
`
`
`

`

`Patent Application Publication
`
`Mar. 17, 2011 Sheet 6 0f 10
`
`US 2011/0066550 A1
`
`8N\
`
`
`
`3vMinx
`
`wmm
`
`H2m_>_><m
`
`TLJ
`
`
`
`com
`
`259as“NewI
`
`53mmwz_j_m
`
`:5E82
`
`288228
`
`mm.ooG
`02fo7e9aPla.roCrebV.CFRv.CLLb9ooG
`
`
`
`
`
`DE.xz<mw2_._.=mmm:><>>E.<w:xz<mwz_><n_
`
`
`
`
`
`
`
`|L4llvE25:E92fl222055252mg
`ENzo_5<mz<zzo_2_\/_mom_w__2><n_CNN
`
`
`53%292352ommN292382.Al||fl<NNN
`Em§><mZQFQ<m2<E.H
`
`wmm‘1E55Efv
`wmmKLVU.mmfidx/,mmfidmwmm,Em_.1hmwfidm,
`
`A‘\IFI
`
`
`
` zmaom238228‘IH/xmama7E02922ng.9a;96mSN
`
`1IIIIh983%E02
`+\255%fiéoflomm-
`1il|lh\
`1\(Nagmw>5<9%oE1
`
`
`
`228228SundialImjmimmLaw
`
`
`
`
`
`
`GOOG-1011
`Google LLC v. RFCyber Corp. / Page 7 of 20
`
`
`
`

`

`Patent Application Publication
`
`Mar. 17, 2011 Sheet 7 0f 10
`
`US 2011/0066550 A1
`
`
`
`
`
`
`32commmm5?Emma
`
`Emma
`
`
`
`
`
`9:025@mmia“E38,;
`
`835m:23
`
`8.3%“2:23
`
`gm2E
`
`om
`
`835m:33
`
`gm?
`
`am52Emma
`
`8:5
`
`uczoE<
`
`mm
`
`
`
`mad;2&5me
`
`
`
`”25mm
`
`
`
`
`
`
`
`
`
`“2mg>$
`
`00.3%8.0me©2:mm.m
`
`{xceauagz<
`
`mm:wxx?
`
`
`
`
`
`
`
`NEE
`
`EmmEQ
`
`
`
`
`
`
`
`
`
`
`
`
`
`@®@\@
`
`3%292:ESE955
`
`
`
`@fi’fljxfl
`
`
`
`
`
`3mm2%:252$8::
`
`
`
`mm.ooG
`02fo8e9aPla.roCrebV.CFRv.CLLb9ooG
`
`GOOG-1011
`Google LLC v. RFCyber Corp. / Page 8 of 20
`
`
`
`
`
`

`

`Patent Application Publication
`
`Mar. 17, 2011 Sheet 8 0f 10
`
`US 2011/0066550 A1
`
`
`
`
`
`_>_<EOEEE“Ema>5
`
`9:35@fisé€582
`
`
`
`
` 8afl_.fl.>H,mm€%Moam
`
`
`
`
`
`835m553no;
`
`
`
`oobmmuE30E<
`
`22:ng8:gm2E
`
`
`
`
`
`835m@553393m
`
`Emwmi
`
`SEcommwmhm._.<Esau
`
`EoEm
`
`SEcommumbwhqEsau
`
`mm?
`
`
`
`mmwmrmvm«wcozwmtocS<
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`aammmm
`
`Q’cflfi
`
`2%:ESEBE
`
`@®@®
`
`
`
`3mm293:Emimm9:25
`
`
`
`mm.ooG
`02fo9e9aPla.roCrebV.CFRv.CLLb9ooG
`
`GOOG-1011
`Google LLC v. RFCyber Corp. / Page 9 of 20
`
`
`
`
`

`

`Patent Application Publication
`
`Mar. 17, 2011 Sheet 9 0f 10
`
`US 2011/0066550 A1
`
`2:.
`
`
`:33p.81commw:50AM
`
`
`
`9:qu0
`
`23d:2%u:88
`Am.<
`
`:6ng«w3:553
`
`
`
`5r£_Ewm2.HSEma
`
`
`
`8::meE535::
`
`2252mmCum5%
`
`09mmw
`
`EsEmxm_<
`
`25202Emmcommé
`
`
`
`553$2,oo.mmw
`
`22%mm52Egg
`
`32Demo0m5w:
`
`Emma
`
`006$”58
`
`
`
`
`
`mmdE22552
`
`
`
`
`
`
`
`
`
`8.me8de@mEmm.m
`
`
`
`
`
`“25mm
`
`
`
`
`
`no.“wx3
`
`
`
`
`
`
`
`
`
`3%mmE95%
`
`
`
`92%
`
`
`
`39m:.5153:5
`
`mm
`
`.lOC.lebV.CFRv.CLLbg0OG
`
`mm.ooG
`o2fOo1egaPla.
`
`GOOG-1011
`Google LLC v. RFCyber Corp. / Page 10 of 20
`
`
`

`

`Patent Application Publication
`
`Mar. 17, 2011 Sheet 10 0f 10
`
`US 2011/0066550 A1
`
`
`
`
`
`_>_<006
`
`
`
`umEm:Emma
`
`2&4
`
`$353mag;
`
`
`
`52co.a0mSN:Emma
`
`now8.00%
`
`mm?
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`mg
`
`
`
`
`
`9:85@meo238%
`
`“E282
`
`
`
`>82295m
`
`
`
`
`
`
`
`
`
`“59:32955
`
`
`
`
`
`m.UNK
`
`93m502:
`fig
`EmmE255@@
`
`was:3850E:5353:5OJ,1Nmow@11a
`
`
`
`b.UNK
`
`mm.ooG
`o2fo11e9aPla.roCrebV.CFRv.CLLb9ooG
`
`GOOG-1011
`Google LLC v. RFCyber Corp. / Page 11 of 20
`
`
`
`
`

`

`US 2011/0066550 A1
`
`Mar. 17, 2011
`
`SYSTEIW AVD VIETHOD FOR A SECURE
`FUNDS TRANSFER
`
`TECI INICAL FIELD
`
`[0001] This disclosure relates generally to funds transfers,
`and more particularly to a system and method for a secure
`fluids transfer.
`
`BACKGROUND
`
`[0002] A payer may transfer funds to a biller using a tradi-
`tional payment instrument, such as cash, a check, or a credit
`card. These payment instruments, however, may be vulner-
`able to loss or theft. Additionally, an unauthorized user may
`easily obtain the account numbers of checks and credit cards
`and may use the account numbers to access the funds.
`[0003] Mobile phone payment systems may use bank web
`pages or text messages, and may provide an alternative to
`traditional payment instruments. These systems, however,
`may fail to adequately secure funds transfers. Accordingly.
`these systems may limit the functionality available to a user
`and/or the dollar amount that may be transferred in order to
`minimize the affects of fraud,
`
`SUMMARY
`
`[0004] According to one embodiment, a gateway receives a
`transaction from a first device in local communication with a
`second device. The transaction includes a payment amount
`and a plurality of authorization codes. The gateway uses the
`authorization codes to authorize the transaction and to deter-
`mine an account for each device. The gateway then instructs
`an account manager to withdraw the payment amount from
`the account ofthe first device and to deposit it into the account
`of the second device. A result is received at the gateway, and
`the gateway sends the result to each device.
`[0005] Certain embodiments of the invention may provide
`one or more technical advantages. A technical advantage of
`one embodiment may be that the security of funds transfers
`may be increased and vulnerabilities to fraud may be
`decreased. As an example, payees may be created dynami-
`cally and discarded after a single transaction, and payments
`may be made without transmitting certain confidential infor-
`mation, such as account numbers. As another example, funds
`transfers may require paying and billing devices to be in close
`proximity. In some embodiments, the proximity requirement
`may be enforced by comparing the location coordinates ofthe
`devices. Another technical advantage may be that transaction
`times may be improved over paper checks by instructing a
`bank to transfer funds at approximately the time the device
`requests the funds transfer, Additionally, an accotmt balance
`may be verified at approximately the time the device requests
`the funds transfer to ensure that a paying account contains
`sufficient fiands to complete the transaction. As yet another
`example, the secure funds transfer may transact payments and
`record the payments electronically, and may therefore reduce
`the paper usage required by paper checks and paper records
`systems. Decreasing fraud, ensuring the availability of funds,
`and reducing paper usage may allow for transactions costs to
`be reduced.
`
`[0006] Certain embodiments of the invention may include
`none, some, or all of the above technical advantages. One or
`
`more other technical advantages may be readily apparent to
`one skilled in the art from the figures, descriptions, and claims
`included herein.
`
`
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`[0007] A more complete understanding of embodiments of
`the disclosure will be apparent from the detailed description
`taken in conjunction with the accompanying drawings in
`which:
`F G. 1 illustrates an example of a network for trans—
`[0008]
`acting a secure funds transfer;
`[0009]
`F G. 2 illustrates an example of a node for transact-
`ing a secure funds transfer;
`[0010]
`F GS. 3A-3G illustrate an example method for set-
`ting up a device to securely transfer funds using the gateway
`of FIG. 1;
`[0011]
`F GS. 4A-4F illustrate an example method for trans-
`acting a secure funds transfer;
`[0012]
`F GS. 5A-5B illustrate an example of an archive for
`tracking completed secure funds transfers;
`[0013]
`F G. 6 illustrates an example of a secure funds trans-
`fer that may be completed by the paying device alone; and
`[0014]
`F G. 7 illustrates an example of an ATM interface
`for transacting a secure funds transfer.
`
`
`
`DETAILED DESCRIPTION
`
`invention and its
`[0015] Embodiments of the present
`advantages are best understood by referring to FIGS. 1
`through 7 of the drawings, like numerals being used for like
`and corresponding parts of the various drawings.
`[0016]
`In some embodiments, a payment may be trans-
`ferred between devices, such as mobile phones, using a secure
`funds transfer. The secure funds transfer may ensure that each
`device is authorized to access the bank accounts selected for
`making and receiving the payment. The secure funds transfer
`may be transacted by individuals, small businesses, such as
`lawn businesses or babysitters, merchants, such as grocers,
`gas stations, or dry cleaners, and/or other suitable parties. The
`funds may be transferred for any suitable purpose, including
`paying rent, purchasing dinner, or receiving an income tax
`loan. In some embodiments, the secure funds transfer may
`reduce the costs, fraud risks. and time requirements of funds
`transfers. For example, funds may be transferred approxi-
`mately in real-time such that a bank receives instructions to
`perform a funds transfer within approximately a few minutes
`ofa user requesting the funds transfer. In some embodiments,
`funds may be transferred between users who are not already
`signed up with the same bank or credit card company, thereby
`allowing for convenient access to funds.
`[0017]
`FIG. 1 illustrates an example of a network 10 for
`transacting a secure funds transfer. In some embodiments,
`network 10 may comprise a plurality of nodes. A node may
`comprise an interface, logic, and memory, such as the node 20
`described in FIG. 2 below. Examples of the nodes of the
`network 10 may include one or more devices 12, a gateway
`14, and one or more account managers 16. In some embodi—
`ments, the gateway 14 may authorize a device 12 to initiate a
`function. For example, the gateway 14 may receive a number
`of authorization factors describing the device 12, authorize
`the device 12 according to the authorization factors, and
`instruct the account manager 16 to perform the function ifthe
`authorization is successful. In some embodiments, the func-
`tion may comprise a funds transfer and the authorization
`
`
`
`Google LLC v. RFCyber Corp. / Page 12 of 20
`
`GOOG-1011
`
`GOOG-1011
`Google LLC v. RFCyber Corp. / Page 12 of 20
`
`

`

`US 2011/0066550 A1
`
`Mar. 17, 2011
`
`factors may include a transaction indicating a payment
`amount and a plurality of authorization codes for authorizing
`one or more devices 12.
`[0018] The device 12 may comprise any device requiring
`authorization to initiate a function. In some embodiments, the
`device 12 may be a mobile device, such as a mobile phone, a
`Personal Digital Assistant (PDA), or a laptop computer. In
`some embodiments, the device 12 may be configured to deter—
`mine its current location. For example, the device 12 may
`include a Global Positioning System (GPS) receiver operable
`to determine its latitude and longitude coordinates according
`to a signal received from a GPS transmitter, such as a satellite
`system, or other device suitable to establish geographic loca-
`tion.
`
`In some embodiments, the device 12 may be con—
`[0019]
`figured to communicate locally with another device 12. Local
`communication may be characterized by communication that
`may not extend beyond a specified radius, such as less than
`100 feet or, for example, less than 25 feet. The local commu-
`nication may be through a physical connection, such as a wire
`or cable, or a wireless connection, such as a short-range
`wireless communication protocol. Examples of short-range
`wireless communication protocols include BLUFTOOTH
`and Near Field Communication (NFC). In some embodi—
`ments, short—range wireless transmissions may comprise
`radio transmissions,
`infrared transmissions, or any other
`short—range transmissions. In some embodiments, the short—
`range wireless communication protocol may be configured
`for a high level of security.
`[0020]
`In some embodiments, the network 10 may include
`a paying device 12a and a billing device 1219. The billing
`device 1219 may be a mobile device as described above or a
`stationary device, such as an Automatic Teller Machine
`(ATM) or a payment terminal at a store. The paying device
`12a and the billing device 12b may establish a local commu-
`nication session to generate a transaction. The devices 12 may
`exchange terms ofthe transaction, such as a payment amount,
`the account from which funds will be withdrawn, and the
`account to which the fiinds will be deposited. Upon a deter-
`mination that the transaction terms are complete, the paying
`device 12a may send the transaction to the gateway 14.
`[0021]
`In some embodiments, the gateway 14 may be a
`node, such as a computer, or a number of nodes, such as a
`network, for controlling access to other nodes of the network
`10. For example, the gateway 14 may control access by autho-
`rizing the device 12 to initiate a requested function. In some
`embodiments, the authorization may be determined accord-
`ing to a plurality of authorization factors. If the authorization
`succeeds, the gateway 14 may instruct other nodes ofnetwork
`10 to perform the function requested by the device 12. If the
`authorization fails, the gateway 14 may not initiate the func-
`tion requested by the device 12.
`the authorization factors
`[0022]
`In some embodiments,
`may include the GPS coordinates of the dcvicc(s) 12 being
`authorized. The GPS coordinates of each device 12 may be
`compared to the GPS coordinates of the device’s expected
`location to verify that the coordinates substantially match. As
`an example, the expected location of a device 12 may be a
`home address or a business address indicated by a user profile
`associated with the device 12. As another example,
`the
`expected location ofthe paying device 1201 may be proximate
`to the current location of the billing device 121). The coordi-
`nates may substantially match if they are within close prox-
`imity to one another, such as less than 100 feet or, for example
`
`less than 2 feet. A known margin of error of the location
`technology may be considered in determining whether the
`coordinates substantially match.
`[0023]
`In some embodiments, the gateway 14 may instruct
`an account manager 16 to perfonn an authorized function In
`some embodiments, the account manager 16 may be a com-
`puter or a computer network configured to perform a func—
`tion, for example,
`to manage the funds of an account.
`
`,3xamples of accounts may include savings accounts, check—
`ing accounts, credit card accounts, debit card accounts, stored
`value cards, lines ofcredit, mobile credit accounts, and/or any
`other suitable account. Accounts may be located anywhere in
`the world and are independent of the location of the device.
`The accotmt manager 16 may be administered by an entity,
`such as a bank or a credit card company associated with the
`account.
`
`In some embodiments, the gateway 14 may receive
`[0024]
`a transaction from the paying device 12a requesting to trans-
`fer funds from a payer’s account managed by a payer’s
`account manager 16a. The device 120 may request that the
`funds be transferred to a biller’s account managed by a biller’s
`account manager 1 6b. The account managers 16 may or may
`not be administered by the same entity depending on whether
`the payer and the biller hold accounts with the same entity
`(e.g., the same bank). The gateway 14 may authorize the
`transaction and may instruct the payer’s account manager 1 6a
`to transfer the funds. The payer’s account manager 16a may
`transfer the funds using any suitable method, such as an
`
`electronic Funds Transfer (EFT), for example, an Automated
`Clearing House (ACH) transfer, or a check. The payer 5
`account manager 16a may transfer funds directly to the bill-
`er’s account manager 16/), or may transfer the ftmds via an
`intermediary such as the gateway 14, The payer’s account
`manager 16a may then return a result to the gateway indicat-
`ing whether the transfer was successful or unsuccessful.
`Example causes of an unsuccessful result may include insuf—
`
`icient funds1n the payer’s account, failure to receive a correct
`bank password, or network error.
`[0025] The nodes of network 10 may communicate using
`any suitable network configuration. Examples may include,
`but are not limited to, a public or private data network; a local
`area network (LAN); a metropolitan area network (MAN); a
`wide area network (WAN); a wireline or wireless network; a
`local, regional, or global communication network; an optical
`network; a satellite network; an enterprise intranet; other
`suitable communication links; or any combination of the
`preceding. In some embodiments, the gateway 14 may corn-
`municate with a device 12 using a browser-based mobile web
`service, and the gateway 14 may commtmicate with an
`account manager 16 using the internet.
`[0026] Modifications, additions, or omissions may be made
`to systems described herein without departing from the scope
`of the invention. The components of the systems may be
`integrated or separated. Moreover, the operations of the sys-
`tems may be performed by more, fewer, or other components.
`For example, in some embodiments, certain mes sages may be
`communicated directly between the gateway 14 and the bill-
`ing device 12b and/or the gateway l4 and the biller’s account
`manager 16]). Operations of the systems may be performed
`using any suitable logic comprising software, hardware, and/
`or other logic. As used in this document, “each” refers to each
`member of a set or each member of a subset of a set.
`
`FIG. 2 illustrates an example of a node 20 for trans-
`[0027]
`acting a secure funds transfer. In certain embodiments, the
`
`
`
`Google LLC v. RFCyber Corp. / Page 13 of 20
`
`GOOG-1011
`
`GOOG-1011
`Google LLC v. RFCyber Corp. / Page 13 of 20
`
`

`

`US 2011/0066550 A1
`
`Mar. 17, 2011
`
`Li.)
`
`node 20 may comprise a device, a gateway, or an account
`manager, such as the device 12, the gateway 14, or the account
`manager 16 of FIG. 1.
`[0028]
`In certain embodiments, node 20 may include an
`interface 30, logic 32, memory 34, and/or other suitable ele-
`ments. Interface 30 receives input, sends output, processes the
`input andjor output, and/or performs other suitable opera—
`tions. In certain embodiments, an interface 30 of gateway 14
`receives one or more authorization factors for authorizing a
`function and outputs an instruction to perform the authorized
`function. Interface 30 may comprise hardware and/or soft-
`ware.
`
`[0029] Logic 32 performs the operations ofthe component,
`for example, executes instructions to generate output from
`input. In certain embodiments, logic 32 of gateway 14 may
`authorize a function, such as a funds transfer, according to the
`authorization factors, such as a plurality of authorization
`codes (e.g., security keys). In some embodiments, the autho-
`rization codes may be configured to represent confidential
`information. Examples of confidential
`information may
`include a user name or an account number for a bank account.
`As an example, a transaction may be requested for an account
`number “ 1 2345678.” Logic 32 may generate an authorization
`code, such as “22B746SZ,” to represent the account number.
`Authorization codes may include any suitable number of
`bytes and any suitable characters. In some embodiments, the
`authorization code may be valid for a single transaction. The
`authorization code may be deleted after the single transaction
`and an updated authorization code may be generated for a
`next transaction. In some embodiments, the authorization
`codes may be encrypted prior to transmission from a first
`node 20 and decrypted upon receipt at a second node 20. In
`some embodiments, separate account authorization codes
`may be generated for each account of a particular device.
`[0030] Logic 32 may include hardware (such as a processor
`40), software (such as applications 44), and/or other logic.
`Logic 32 may be encoded in one or more tangible media and
`may perform operations when executed by a computer. Cer-
`tain logic 32, such as a processor 40, may manage the opera-
`tion of a component. Examples of a processor 40 include one
`or more computers, one or more microprocessors, one or
`more applications, and/or other logic.
`[003]]
`In particular embodiments, the operations of the
`embodiments may be performed by one or more computer
`readable media encoded with a computer program, software,
`computer executable instructions, and/or instructions capable
`of being executed by a computer. In particular embodiments,
`the operations of the embodiments may be performed by one
`or more computer readable media storing, embodied with,
`and/or encoded with a computer program and/or having a
`stored and/or an encoded computer program.
`[0032] Memory 34 stores information. Memory 34 may
`comprise one or more tangible, computer-readable, and/or
`computer-executable storage medium, and may exclude sig-
`nals or carrier waves. Examples ofmemory include computer
`memory (for example, Random Access Memory (RAM) or
`Read Only Memory (ROM)), mass storage media (for
`example, a hard disk), removable storage media (for example,
`a Compact Disk (CD) or a Digital Video Disk (DVD)), data-
`base and/or network storage (for example, a server), and/or
`other computer-readable medium.
`[0033] Modifications, additions, or omissions may be made
`to node 20 without departing from the scope of the invention.
`The components of node 20 may be integrated or separated.
`
`Moreover, the operations of node 20 may be performed by
`more, fewer, or other components. Additionally, operations of
`node 20 may be performed using any suitable logic compris—
`ing software, hardware, andjor other logic.
`[0034]
`FIGS. 3A-3G illustrate an example method for set-
`ting up a device 12 to securely transfer funds using the gate-
`way 14 of FIG. 1. Setting up the device 12 may include
`registering and activating a user profile. The registration and
`activation may utilize one or more security checks. Accord—
`ingly, in some embodiments, setting up the device 12 may be
`required prior to conducting the first funds transfer.
`[0035]
`In some embodiments, the method begins with a
`user downloading a funds transfer application to the device.
`The application may be downloaded from any suitable
`source, such as a bank’s website, an email attachment, or an
`application store of a software provider. The application store
`may include a list of available applications sorted according
`to newness, popularity, interest (e.g., finance), or any other
`suitable category. FIG. 3A illustrates an example of a finance
`category 50 that includes a Peer-to-l’eer (P2P) Payment appli-
`cation 52. The user may select the P2P Payment application
`52 for more information. FIG. 3B illustrates sample informa-
`tion for the application including a software provider’s name
`54, a rating 56, a link to customer reviews 58, a download
`price button 60, and a description of the application 62. The
`description 62 may indicate the application’s purpose, the
`device requirements for the particular embodiment of the
`application, and a list of participating entities. The user may
`review the information and may select to download the appli-
`cation, for example, by pressing the download price button
`60.
`
`[0036] After downloading the application, the user may
`create a user profile. FIG. 3C illustrates an example of a user
`profile 66. In some embodiments, the user profile may be
`accessed from a user configuration menu 64, and it may
`include a user name, a street address (e.g., a home address or
`a business address), an email address, and/or an application
`password. The application password may be a password for
`accessing the application, and it may be configured to be
`verified by any suitable node, such as the device 12 itself or
`the gateway 14. Verifying the application password at the
`gateway 14 may reduce the likelihood of the application
`being accessed if the device 12 becomes lost or stolen.
`[0037]
`In some embodiments, the user may press a regis-
`tration button 64 to instruct the device 12 to send the com-
`pleted user profile 66 to the gateway 14. The gateway 14 may
`register the user profile 66 and may store the registered profile
`in a database that may be accessed during subsequent funds
`transfers. Accordingly, the user need not re-enter the infor-
`mation for each funds transfer.
`
`[0038] The method may require activating the user profile
`66 prior to the first transaction. In some embodiments, the
`gateway 14 may send an activation key to the user for acti-
`vating the registered user profile 66. For example, the activa-
`tion key may be sent to the email address indicated by the user
`profile. The activation key may include one or more security
`features. As an example, the activation key may expire after a
`relatively short period of time.
`[0039]
`To activate the user profile 66. the user may create an
`activation request including the application pas sword and the
`activation key 70, as shown in FIG. 3D. The user may instruct
`the device 12 to send the activation request to the gateway by
`pressing an activation button 72. In some embodiments, the
`device 12 may include the GPS coordinates of its current
`
`
`
`Google LLC v. RFCyber Corp. / Page 14 of 20
`
`GOOG-1011
`
`GOOG-1011
`Google LLC v. RFCyber Corp. / Page 14 of 20
`
`

`

`US 2011/0066550 A1
`
`Mar. 17, 2011
`
`location in the activation request. The gateway 14 may autho-
`rize the device 12 by verifying the application password, the
`activation key 70, and/or the GPS coordinates. In some
`embodiments, the GPS coordinates may be compared to the
`street address indicated by the user profile 66. The registration
`may be activated if the GPS coordinates substantially match
`the street address, for example, if the GPS coordinates are
`within 100 feet of the street address. The gateway 14 may be
`configured to consider a margin of error of the location tech-
`nology when determining if the coordinates substantially
`match.
`
`the user may access an
`In some embodiments,
`[0040]
`accounts configuration menu to setup one or more accounts
`for making and/or receiving payments, performing balance
`inquiries, or any other suitable fturction. FIG. 3B illustrates an
`example accounts configuration menu 74 wherein the user
`may first select an account
`type 76 to be configured.
`Examples of account types may include savings accounts,
`checking accounts, credit card accounts, debit card accounts,
`stored value cards, lines of credit, mobile credit accounts,
`and/or any other suitable account.
`[0041]
`FIG. 3F illustrates an example for configuring a new
`checking account, however, any type of account may be con-
`figured. The user may enter account information, such as a
`bank identifier and a checking account number. For credit
`card, debit card, stored value card, and/or gift card configu—
`rations (not shown), account information may include a card
`number, an expiration date, and a card security code, such as
`a Card Verification Value (CVC) 2 code. In addition to the
`type-specific account information, each account may be con-
`figured with an account password. During a transaction, the
`accotmt password may be verified by any suitable node, such
`as the device 12 itselfor the gateway 14.Verifying the account
`password at the gateway 14 may reduce the likelihood of the
`account being accessed if the device 12 becomes lost or
`stolen. In some embodiments, the account configuration may
`include information to be passed through the gateway 14 to an
`account manager, such as a login name and a bank password
`for accessing a website of the user’s bank.
`[0042]
`In some embodiments, the user may configure the
`application to access multiple accounts. A default configura—
`tion menu 78 may be used to select preferred accounts for
`certain transactions. FIG. 3G illustrates an example of default
`settings. The user may select the default account(s) for mak—
`ing payments 80 as well as the default account(s) for receiv-
`ing payments 82. In some embodiments, the user may select
`more than one default account for making or receiving pay-
`ments. For example, the user may select to pay personal
`expenses from a checking account and to pay business
`expenses from a credit card account.
`[0043]
`In some embodiments,
`setting up the device
`includes receiving one or more authorization codes for autho-
`rizing the first transaction of the device 12. Upon completing
`the setup method, the device 12 may be used to transfer funds.
`[0044] Modifications, additions, or omissions may be made
`to the previously described method without departing from
`the scope of the disclosure. The method may include more,
`fewer, or other steps. For example, in some embodiments the
`P2P Payment application 52 may be downloaded directly
`from a bank’s website. The bank’s website may transfer an
`existing user profile 66 and account information to the gate-
`way 14 without requiring the user to separately configure,
`register, and/or activate the application. Alternatively, the
`registration and/or activation may be done offline through a
`
`call center of the bank or a file feed from a participating bank
`to an administrator ofthe gateway 14. As another example, in
`some embodiments the user may be required to re-register
`periodically and’or after modifying the user profile 66. In
`some embodiments, the user may deactivate the registration
`using a website or call center of the bank or the gateway 14.
`The user may choose to deactivate the registration if the
`devi