THE MAIN TEA ETA DATELOR UT A MAI
`US 20180197167A1
`( 19 ) United States
`( 12 ) Patent Application Publication ( 10 ) Pub . No . : US 2018 / 0197167 A1
`Jul . 12 , 2018
`( 43 ) Pub . Date :
`Ganesan
`
`( 54 ) SYSTEM AND METHOD FOR
`PERSON - TO - PERSON PAYMENTS
`( 71 ) Applicant : Early Warning Services , LLC ,
`Scottsdale , AZ ( US )
`( 72 ) Inventor : Ravi Ganesan , San Diego , CA ( US )
`( 73 ) Assignee : Early Warning Services , LLC ,
`Scottsdale , AZ ( US )
`( 21 ) Appl . No . : 15 / 403 , 560
`( 22 ) Filed :
`Jan . 11 , 2017
`Publication Classification
`
`( 51 )
`
`Int . Cl .
`G06Q 20 / 22
`G060 20 / 40
`G06Q 20 / 04
`G06Q 20 / 24
`G06Q 20 / 32
`
`( 2006 . 01 )
`( 2006 . 01 )
`( 2006 . 01 )
`( 2006 . 01 )
`( 2006 . 01 )
`
`G06Q 20 / 10
`( 2006 . 01 )
`G06Q 20 / 02
`( 2006 . 01 )
`( 52 ) U . S . CI .
`CPC . . . . . . G06Q 20 / 223 ( 2013 . 01 ) ; G06Q 20 / 4016
`( 2013 . 01 ) ; G06Q 20 / 405 ( 2013 . 01 ) ; G06Q
`20 / 02 ( 2013 . 01 ) ; G06Q 20 / 24 ( 2013 . 01 ) ;
`G06Q 20 / 3226 ( 2013 . 01 ) ; G06Q 20 / 108
`( 2013 . 01 ) ; G06Q 20 / 042 ( 2013 . 01 )
`( 57 )
`ABSTRACT
`A person - to - person ( P2P ) payment system provides pay
`ment from a payer to a payee without the payer identifying
`a payee payment receiving preference , such as the payee
`account into which funds are to be posted . The payment
`system includes a setup system for setting up payment
`between the payer and the payee and a messaging system for
`handling messages between the payer and the payment
`system and the payee and the payment system , including
`communications with the payee by way of a payee phone
`number or email address provided by the payer . A risk
`assessment system determines a risk score for the P2P
`transaction and , based on that score , the bank of the payer
`provides a guarantee to the bank of the payee .
`
`PAYER
`
`130
`
`PAYMENT SETTLEMENT
`SYSTEM
`
`100
`
`PAYEE
`
`NETWORK
`
`BANK 1
`
`TO BANK 2
`
`140
`
`BANK
`
`PAYMENT
`SETUP SYSTEM
`
`MESSAGING
`SYSTEM
`
`ACCOUNT
`MANAGEMENT
`SYSTEM
`
`RISK
`ASSESSMENT
`SYSTEM
`
`U
`
`W
`
`* * * *
`
`*
`
`WWW
`
`.
`
`o
`
`wwwwwwwwwwwwwwwwwwwww ENROLLMENT
`XXXXXXXX000000wwwwww
`
`DATA
`
`Wwwwwwwwwww
`WWWXXXXXXX SETTLEMENT
`
`ACCOUNT
`DATA
`
`0000
`
`0
`
`0000000000
`
`TRANSACTION
`DATA
`
`ww
`
`120
`
`Petitioner Kiosoft Exhibit 1011
`1
`
`

`

`Patent Application Publication
`
`Jul . 12 , 2018 Sheet 1 of 6
`
`US 2018 / 0197167 A1
`
`PAYMENT SETTLEMENT
`SYSTEM
`
`PAYER
`
`PAYEE
`
`BANK 1
`
`140
`
`130
`
`NETWORK
`
`BANK 2
`
`BANK n
`
`PAYMENT
`SETUP SYSTEM
`
`MESSAGING
`SYSTEM
`
`ACCOUNT
`MANAGEMENT
`SYSTEM
`
`RISK
`ASSESSMENT
`SYSTEM
`
`W
`
`you
`
`* *
`
`SETTLEMENT
`ACCOUNT
`DATA
`Nosso
`
`. . . . . . . . . . . . . . . .
`
`*
`
`TRANSACTION
`DATA
`
`124
`
`Oo600W
`
`ENROLLMENT
`ovax0000
`DATA
`
`120
`
`FIG . 1
`
`Petitioner Kiosoft Exhibit 1011
`2
`
`

`

`Patent Application Publication
`
`Jul . 12 , 2018 Sheet 2 of 6
`
`US 2018 / 0197167 A1
`
`PAYER ACCESSES PAYMENT
`APPLICATION
`
`202
`
`212
`
`PAYER PROVIDES PAYMENT
`INFORMATION
`
`REQUEST
`FURTHER
`INFORMATION
`
`VALID
`MAILING
`ADDRESS ?
`
`EN USABLE PAYEE PHONE NO .
`OR EMAIL ADDRESS ?
`
`GENERATE
`CHECK
`
`218
`
`FIG . 2
`
`PAYMENT SYSTEM NOTIFIES
`PAYEE
`
`320
`
`PAYEE SELECTS PAYMENT
`METHOD
`
`PAYMENT SYSTEM CONFIRMS
`PAYMENT SOURCE & PAYMENT
`DESTINATION , & DETERMINES
`RISK SCORE
`
`esh
`PAYMENT SOURCE GUARANTEES
`ELECTRONIC PAYMENT
`
`PAYMENT SYSTEM PROVIDES
`REAL TIME PAYMENT TO PAYEE
`
`PAYMENT SYSTEM RECONCILES
`SETTLEMENT ACCOUNT BETWEEN
`PAYMENT SOURCE & PAYMENT
`DESTINATION
`
`228
`
`234
`
`240
`
`Petitioner Kiosoft Exhibit 1011
`3
`
`

`

`Patent Application Publication
`
`Jul . 12 , 2018 Sheet 3 of 6
`
`US 2018 / 0197167 A1
`
`$ 850 . 27
`
`DOLLARS
`
`
`
`JOHN SMITH
`
`DATE : SEPTEMBER 1 , 2016
`
`Cox ] OX |
`
`PAYMENT SERVICE ACCT XXXXXX
`
`
`
`
`JOHN SMITH
`
`PAYEE ADDRESS : 23 MAPLE ST , ANY TOWN , USA
`
`
`
`PAYEE EMAIL : JDOE @ EMAIL . COM PAYEE
`PHONE NO . : 480 - 555 - 1234 PAYMENT
`
`
`AMT : $ 850 . 27 MEMO LINE : HOME DECORATIONS
`
`
`
`
`
`PAYEE NAME : JANE DOE
`
`
`
`
`
`WHEN FINISHED , CLICK HERE
`
`FIG . 3
`
`310
`
`
`
`EIGHT HUNDRED FIFTY AND 27 / 100
`
`
`
`
`
`
`1 : 3020750181 : 01484543827
`
`FOR : HOME DECORATIONS
`
`
`
`THE ODER OF JANE DOE
`
`PAY TO
`
`320
`
`
`
`
`
`PLEASE ENTER YOUR PAYMENT INFORMATION
`
`
`
`
`
`Petitioner Kiosoft Exhibit 1011
`4
`
`

`

`Patent Application Publication
`
`Jul . 12 , 2018 Sheet 4 of 6
`
`US 2018 / 0197167 A1
`
`PAYEE : JANE DOE
`
`A REQUEST HAS BEEN MADE FOR PAYMENT TO YOU THROUGH OUR PAYMENT SYSTEM . PLEASE SELECT HOW
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`YOU WOULD LIKE TO RECEIVE THE PAYMENT & ENTER THE INFORMATION REQUESTED :
`
`
`
`USE MY ACCOUNT AT PENNY PAYMENT SERVICE MY PAYMENT
`
`SERVICE ACCOUNT IS :
`
`
`
`
`
`
`
`SEND A CHECK VIA EMAIL FOR ME TO CAPTURE AND REMOTELY DEPOSIT
`
`
`
`SEND A PAPER CHECK VIA MAIL TO MY ADDRESS AT
`DEPOSIT THE PAYMENT IN MY BANK ACCOUNT MY ROUTING & ACCOUNT NO IS :
`
`
`
`
`
`
`
`480 - 555 - 1234
`
`
`
`PAYMENT NOTIFICATION
`
`TO
`
`
`
`PAYER : JOHN SMITH
`
`AMT : $ 850 . 27
`
`O
`
`O
`
`O O
`
`1 .
`
`2 .
`
`3 . 4 .
`
`
`
`
`
`ENTER THE NUMBER CORRESPONDING TO YOUR PREFERENCE & CLICK HERE
`
`
`
`
`
`FIG . 4
`
`410
`
`Petitioner Kiosoft Exhibit 1011
`5
`
`

`

`Patent Application Publication
`
`Jul . 12 , 2018 Sheet 5 of 6
`
`US 2018 / 0197167 A1
`
`PAYMENT SELECTION
`
`534
`
`PAYEE ACCOUNT
`CONFIRM
`
`PAYER ACCOUNT
`CONFIRM
`
`532
`
`PAYEE FI SYSTEM
`
`
`
`PAYEE DEVICE
`
`! PAYER FI SYSTEM
`
`PAYEE ACCOUNT
`CREDIT
`
`pad
`
`DISPLAY IMMEDIATE AVAILABILITY
`
`* XXXXXXXXX
`
`556
`
`558
`
`oxoxxconocomando
`PAYMENT GUARANTEE
`
`x
`
`RECEIVE SETTLEMENT ACCOUNT
`BALANCE
`
`562
`
`RECEIVE SETTLEMENT ACCOUNT
`BALANCE
`
`562
`
`
`
`SCORE
`
`
`
`PAYER & PAYEE REQUEST ACCOUNTS CONFIRMATION & RISK
`
`
`
`
`
`PAYMENT SETTLEMENT SYSTEM
`
`PAYER DEVICE
`
`PAYMENT INFORMATION 5127
`REQUEST
`REQUEST PAYMENT
`
`PAYEE SELECTION
`REQUEST
`
`ELECTRONIC CHECK - - -
`
`| 520 PREPARE PAPERIL
`
`
`nomenament de series
`or
`
`r
`
`T
`
`510
`
`REQUEST
`
`PAYER FI GUARANTEE
`
`L
`PAYEE OF IMMEDIATE PAYMENT / DEPOSIT
`NOTIFY
`
`RECONCILE SETTLEMENT ACCOUNT ( PAYER FI / PAYEE FI )
`
`560
`
`FIG . 5
`
`Petitioner Kiosoft Exhibit 1011
`6
`
`

`

`Patent Application Publication
`
`Jul . 12 , 2018 Sheet 6 of 6
`
`US 2018 / 0197167 A1
`
`605
`
`PROCESSOR ( S )
`
`WORKING
`MEMORY
`
`610
`
`625
`
`615
`
`620
`
`635
`
`STORAGE
`DEVICE ( S )
`
`OUTPUT DEVICE ( S )
`
`COMMUNICATIONS
`SUBSYSTEM
`
`FIG . 6
`
`INPUT DEVICE ( S ) 0 , 50 645
`
`OPERATING
`SYSTEM
`
`640
`
`APPLICATION ( S )
`
`| 630
`
`Petitioner Kiosoft Exhibit 1011
`7
`
`

`

`US 2018 / 0197167 A1
`
`Jul . 12 , 2018
`
`SYSTEM AND METHOD FOR
`PERSON - TO - PERSON PAYMENTS
`BACKGROUND OF THE INVENTION
`[ 0001 ] Person - to - person ( P2P ) payment systems have
`become popular for transferring money between individuals .
`P2P payment systems provide many benefits , including
`convenient transfer of payments , as well as providing acces
`sible electronic records of the payments . However , many
`P2P payment systems require that both the person making
`payment ( payer ) and the person receiving payment ( payee )
`be enrolled with the system . Enrolling typically includes
`providing preferences , such as the payer account from which
`payment funds will be taken and payee account to which
`payment funds will be deposited .
`[ 0002 ]
`The convenience of P2P payments is affected ,
`however , when both parties have not already enrolled or
`pre - registered with the payment system . In those circum
`stances , one party ( usually the payee ) will need to go
`through the process of enrolling and providing preferences
`prior to receiving payment , which can delay the receipt of
`payment . Since the number of different P2P payment sys
`tems has increased in recent years , a payee may need either
`to have pre - registered or to register at the time the payment
`with a number of P2P providers , depending on which
`provider and system is being used by the payer . Some
`consumers are hesitant to provide financial information
`( such as account preferences ) to
`a number of different
`entities because of the risk that such information might
`compromised ( e . g . , by hackers surreptitiously gaining
`access to the payment systems ) . Thus , a payer ( or payee )
`may prefer to conduct most if not all of the payers transac
`tions using only one or two preferred payment systems ( to
`limit the risk that financial information might be compro
`mised ) , which payment systems may not be the payment
`system preferred by the other party .
`[ 0003 ] While some P2P payment systems may permit a
`payer to enter payee account information ( so that the payee
`need not be registered with the system ) , the extra steps
`required of the payer to conduct the transaction ( knowing
`how the payee would like to be paid and providing that
`information to the system ) make the system less convenient
`for the payer to use .
`[ 0004 ] Further , some consumers simply do not want to
`receive payments electronically , but rather prefer being paid
`either in cash or by check . Where a payee has not registered
`or does not want to register with a P2P system , a payer is not
`be able to achieve the benefits of using a P2P payment
`system .
`[ 0005 ] Thus , current P2P payment systems are not always
`able to achieve features and advantages for which they are
`designed .
`
`BRIEF SUMMARY OF THE INVENTION
`[ 0006 ] There is provided , in accordance with embodi
`ments of the present invention , a network / system and
`method for providing for person - to - person payments , where
`payment can be provided to any payee ( whether pre - regis
`tered or not ) based on the preferences of the payee , but
`without the payer needing to know those preferences or
`having to provide them for purposes of completing the
`transaction .
`
`[ 0007 ] In one embodiment , a person - to - person payment
`system for providing payment from a payer to a payee using
`a mobile device of the payer includes a payment setup
`system and a risk assessment system . The payment setup
`system is programmed for : enrolling the payer , including
`receiving from the payer an account identifier for identifying
`an account of the payer that is used to fund payment from the
`payer to the payee ; receiving , through a payment messaging
`system , a payment request message from a payer device , the
`payment message request including a payment amount and
`payee identification information , the payee identification
`information including at least one of a payee phone number ,
`a payee email address and a payee mailing address ; deter
`mining whether the payee phone number and the payee
`email address have been provided , and whether at least one
`of the provided payee phone number and payee email
`address is usable to communicate with the payee ; upon
`determining that the at least one of the provided payee phone
`number and payee email address is not usable to commu
`nicate with the payee , determining that a payee mailing
`address has been provided as part of the payee identification
`information , and generating correspondence to the payee
`using the payee mailing address ; upon determining that the
`at least one of the provided payee phone number and payee
`email address is usable to communicate with a payee ,
`sending an electronic communication through the payment
`messaging system to the payee device requesting that the
`payee select one payment method from a group of payment
`methods for receiving payment from the payer , the group of
`payment methods comprising : 1 ) receiving a paper check , 2 )
`receiving a check image electronically , and 3 ) receiving an
`electronic deposit to an account of the payee ; after selection
`by the payee , as the one payment method , for receiving a
`paper check or for receiving a check image electronically ,
`providing the paper check or the check image to the payee ;
`and after selection by the payee , as the one payment method ,
`for receiving an electronic deposit to an account of the
`payee , receiving at the payment settlement system from a
`payee device an account identifier for identifying the
`account of the payee . The risk assessment system is pro
`grammed for : receiving from the payment settlement system
`at least the identifier for the identified account of the payer
`and the identifier for the identified account of the payee ; and
`generating , in response to receiving the identifiers for the
`identified account of the payer and identified account of the
`payee , a risk score reflecting the degree of risk associated
`with the requested payment from the identified account of
`the payer to the identified account of the payee , and pro
`viding the risk score to a first financial institution maintain
`ing the identified account of the payer . The payment system
`receives , from the first financial institution maintaining the
`identified account of the payer , and in response to the risk
`score , a message having a payment guarantee for the amount
`of the payment to a second financial institution maintaining
`the account of the payee , the payment guarantee based at
`least in part on the risk score . The payment guarantee is
`provided to the second financial institution maintaining the
`identified account of the payee in order to immediately
`credit the identified account of the payee with at least a
`portion of the amount payment .
`[ 0008 ] .
`A more complete understanding of the present
`invention may be derived by referring to the detailed
`description of the invention and to the claims , when con
`sidered in connection with the Figures .
`
`Petitioner Kiosoft Exhibit 1011
`8
`
`

`

`US 2018 / 0197167 A1
`
`Jul . 12 , 2018
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`[ 0009 ] FIG . 1 is a general block diagram illustrating one
`embodiment of a payment settlement system for making
`person - to - person payments between a payer and a payee .
`[ 0010 ] FIG . 2 is a flow diagram illustrating the overall
`operation of the payment settlement system of FIG . 1 ,
`including interaction with a payer and payee .
`[ 0011 ]
`FIG . 3 illustrates a display screen at a payer device
`in response to messaging between the payment settlement
`system and the payer device , for purposes of entering
`payment information by the payer .
`[ 0012 ]
`FIG . 4 is a message displayed at a payee device , for
`the payee to provide selection of a method of payment
`through the payment settlement system .
`[ 0013 ] FIG . 5 is a diagram illustrating messaging between
`a payer device , a payment settlement system , a payer
`financial institution system , a payee device and a payee
`financial institution system , for purposes of implementing a
`person - to - person payment .
`[ 0014 ] FIG . 6 is a block diagram illustrating an exemplary
`computer system that is specially designed and programmed
`in order to implement various features of the invention .
`DETAILED DESCRIPTION OF THE
`INVENTION
`[ 0015 ] There are various embodiments and configurations
`for implementing the present invention . One such imple
`mentation is shown in FIG . 1 , where according to an
`embodiment of the invention , a payment settlement system
`100 facilitates payment transactions between a payer 102
`and a payee 104 . In described embodiments , the system 100
`is a of a type commonly referred to as a " person - to - person ”
`( P2P ) payment system , although it should be understood that
`in some embodiments the payer and payee may be an entity
`rather than a person or individual ( e . g . , a merchant entity
`either receiving payment as a payee from a customer or that
`same merchant entity making payment as a payer to a
`supplier ) .
`[ 0016 ] The payment settlement system 100 includes a
`payment setup system 108 for setting up payment in
`response to payment information from a party to a transac
`tion , a messaging system 110 used for receiving and gen
`erating messages as part of the payment process , an account
`management system 112 for managing information provided
`during enrollment and for maintaining a settlement account
`between banks ( for purposes to be described in greater detail
`later ) , and a risk assessment system 114 that may be used to
`assess the risk of any payment transaction ( for purposes also
`to be described in greater detail later ) . The payment settle
`ment system 100 also maintains and manages several
`m
`memory or database systems in order to carry out its
`functions , the databases including an enrollment database
`120 , a settlement account database 122 , and a transaction
`database 124 . In some embodiments , the databases 120 , 122
`and 124 may be accessed at a location remote from the
`payment settlement system 100 .
`[ 0017 ]
`The payment settlement system 100 communicates
`with the payer and payee over a communications network
`130 , which may include the Internet , dedicated telecommu
`nications networks , or combinations thereof . The payer and
`payee may communicate with the network 130 using various
`electronic devices , such as mobile smart phones , personal
`computers , tablet computers and other similar devices ,
`
`although in some embodiments , as will be described later ,
`one party ( e . g . , the payee 104 ) may use the payment
`settlement system 120 for purposes of receiving payment
`without the use of an electronic device .
`[ 0018 ] Also illustrated in FIG . 1 are systems at a plurality
`of banks 140 ( Bank 1 through Bank n ) , any one of which
`may maintain an account of the payer 102 ( from which
`payment may be sent ) and or an account of the payee 104
`( into which payment may be deposited ) . It should be appre
`ciated that while the term “ bank ” is used in conjunction with
`FIG . 1 , banks 140 need not be traditional banks , but rather
`may be any financial institution or other entity that maintains
`accounts accessible to a payer or payee , such as credit
`unions , savings and loans , investment firms , credit card
`companies , government agencies , insurance companies and
`the like .
`[ 0019 ] The operation of the various systems illustrated in
`FIG . 1 will be described in greater later in conjunctions with
`other figures . Briefly , when a payer 102 wants to make
`payment to a payee 104 , the payer accesses the payment
`settlement system 100 over the network 130 . The access
`may be facilitated by an application resident on a payer
`device or through a website that interfaces with the payment
`settlement system 100 . It is assumed for purposes of the
`present discussion that the payer 102 has previously enrolled
`for using the P2P service implemented at the payment
`settlement system 100 , and has provided payment prefer
`ences ( such as one or more accounts to be used by the payer
`to fund payments ) . As such , the payment setup system 108
`retrieves , from the enrollment database 120 , the account of
`the payer that will be used to fund the payment .
`[ 0020 ]
`Through various messages handled by the messag
`ing system 110 , the payment settlement system 100 deter
`mines how to contact the payee 104 and determine how the
`payee would like payment made . One feature of the present
`invention is that the payee need not be enrolled with the
`payment settlement system , but rather can be reached
`through a phone number , email address or physical address
`provided by the payer 102 . The payee can select , for
`example , payment to be made into a payee account at one of
`the banks 140 , using the messaging system 110 . As another
`example , the payee 104 may elect to receive a paper check
`through the mail . When the payee elects to have funds
`automatically or electronically transferred to an account , the
`risk assessment 114 may be used to assess the risk of the
`transaction . This risk assessment may be used by the bank of
`the payer to determine whether it is willing to guarantee ( or
`make “ a promise to pay ” ) the amount to the bank of the
`payee . Risk assessment may be accomplished , for example ,
`by accessing the transaction database 124 , which may
`include data pertaining to any payer account ( s ) , any payee
`account ( s ) , and transactions at those accounts . Based on
`analysis of that data , the risk assessment system can develop
`a risk assessment or score related to the payment transaction .
`The transaction database 124 may collect data across many
`financial institutions ( such as banks 140 ) and accounts at
`those institutions , in order to have access to sufficient data to
`develop a risk assessment . One example of a risk assessment
`system and related databases can be found in U . S . Pat . No .
`8 , 682 , 766 , issued to Robin S . Love et al . , commonly owned
`with the present application , and hereby incorporated by
`reference . The transaction database 124 may also store ( for
`use independent of the risk assessment system 114 ) P2P
`
`Petitioner Kiosoft Exhibit 1011
`9
`
`

`

`US 2018 / 0197167 A1
`
`Jul . 12 , 2018
`
`payment transactions completed by the system 100 ( e . g . ,
`stored as a record accessible by the payer or payee ) .
`[ 0021 ]
`In alternative embodiments , where a less compre
`hensive risk assessment is acceptable , the risk assessment
`system 114 may simply request a “ good funds ” response
`from the payer bank , namely that the payer has sufficient
`funds in the account being used to fund the amount of the
`payment and that such amount has been either debited for
`the benefit of the payee or has been subjected to a “ hold ” so
`that the funds are committed for the P2P payment . In some
`embodiments , a " good funds ” response may be used as part
`of broader risk assessment at the system 114 , e . g . , even
`though sufficient funds are available in the payer account ,
`other elements of risk , such as the risk that someone other
`than the payer is attempting to make payment using the
`payer ' s identity , might be desired by the banks / parties
`involved .
`[ 0022 ] The account management system 112 may be used
`to manage settlement accounts between the banks 140 . For
`example , if the bank of the payee immediately credits the
`payee account based on a payer bank ' s guarantee or promise
`to pay , a settlement account between those two banks
`receives a credit for the payee bank , and a debit for the payer
`bank . The payment settlement system may reconcile the
`settlement account , for example , at the end of each day , such
`that any transfers posted between two banks ( whether credits
`or debits ) are accounted for , and a payment can made by any
`one bank to another bank in order to bring their settlement
`account to a zero balance .
`[ 0023 ]
`It should be noted that the functions performed by
`payment settlement system 100 as just described relating to
`facilitating payments between a payer and a payee offer
`numerous advantages to the payer and payee , as well as
`improved and efficient operation of computing devices mak
`ing up the payment settlement system 100 . For example , the
`payer need not know the method by which the payee would
`like to receive payment , but simply identifies a method of
`communicating with the payee in order for the payee to
`make that selection . Furthermore , the payee need not have
`registered or pre - enrolled with the payment settlement sys
`tem , but only needs to interact with the payment settlement
`system when it wants to be paid and then only one time for
`purposes of receiving a payment . Furthermore , when a payer
`bank determines that the transaction is an acceptable risk
`level ( as determined by the risk assessment system 114 ) ,
`payment can be immediately credited to a payee account for
`access by the payee , with the settlement account between the
`payer bank and payee bank reconciled later to take into
`account any such payments .
`[ 0024 ] Turning now to FIG . 2 , there is illustrated in greater
`detail a process implemented at the payment settlement
`system 100 for making a P2P payment between a payer 102
`and a payee 104 . The process may be implemented by one
`or more applications ( uniquely designed as described herein )
`running at the payment settlement system 100 . It is assumed ,
`for purposes of this description , that the payer 102 has
`previously enrolled with payment settlement system and has
`provided various personal and identifying information ,
`" ,
`including the payer ' s preferences , such as a bank account
`from which funds are withdrawn to make the payment .
`[ 0025 ] At step 202 , the payer uses a device ( such as a
`mobile smart phone ) to access the payment settlement
`system 100 . As mentioned earlier , access may be accom -
`plished , as examples , through an app on the payer device or
`
`through a website hosted at a server at the payment settle
`ment system . Alternatively , the payer may have a P2P
`service provided by the payer ' s bank ( one of the banks 140 ) ,
`and access to the payment settlement system may be by way
`of the payer bank website . As an example , the operator of the
`payment settlement system 100 may be a third - party that
`offers , through member banks , a P2P service that can be used
`by any customer of those member banks .
`[ 0026 ] As part of step 202 , the payer may provide a
`username and password that permits the system to authen
`ticate the payer and also retrieve personal information and
`preferences of the payer from the enrollment database 120 .
`[ 0027 ] At step 204 , the payer provides payment informa
`tion through the network 130 to the payment settlement
`system . The payment information in one embodiment could
`be the name of the payee , the amount of the payment , and
`one or more of a physical address of the payee , an email
`address of the payee , and a phone number the payee . An
`example of a screen that appears on the payer ' s device for
`purposes of entering payment information is illustrated in
`FIG . 3 .
`In the embodiment of FIG . 3 , and input screen 310
`10028 ] .
`provides various visual prompts for entering information
`and displays the entered information as it might appear on a
`check made out to the payee . In this example , the payer
`( John Smith ) maintains a payment service account at the
`payment settlement system ( identified by a payment service
`account number ) . Various information concerning the payer
`is associated with the payment service account number in
`enrollment database 120 ) , including the preferred account at
`one of the banks 140 from which the payment is to be made .
`As illustrated , as the payer enters various information ( payee
`name , payee address , payee email address , payee phone
`number , payment amount and memo line ) , and some or all
`of that information may be auto - populated onto an image
`320 of a check . While in most transactions a paper check
`will not be sent to the payee , the display check image
`provides a familiar format for the payer to confirm details of
`the payment being made . However , as will be described
`shortly , in some cases , depending on the selection made by
`the payee , a paper check resembling the check image 320
`could be provided to the payee .
`10029 ] . As noted earlier , one important feature of the
`payment settlement system 100 is its operation that permits
`payment to a payee , regardless of whether the payee has
`registered with the system and regardless of whether the
`payer has any information on how the payee prefers to be
`paid . This operation is largely carried out by the function
`ality and underlying messages transmitted and received at
`the system 100 that are represented by steps 210 - 234 in FIG .
`2 , and implemented within the system 100 by the payment
`setup system 108 and messaging system 110 .
`[ 0030 ] At step 210 , the system determines the nature of the
`identifying information that has been provided about the
`payee from the payer , and in particular whether a usable
`phone number or email address has been provided . The
`system 100 will generate to the payee ) a mobile message
`( e . g . , SMS text message ) if a usable mobile phone number
`is provided or generate an email message if a usable email
`address is been provided ( or in some embodiments , generate
`both ) . If neither a usable phone number or email address is
`received from the payer at step 210 , then the system deter
`mines whether a valid physical mailing address has been
`provided , step 212 . If no valid mailing address is provided
`
`Petitioner Kiosoft Exhibit 1011
`10
`
`

`

`US 2018 / 0197167 A1
`
`Jul . 12 , 2018
`
`at step 212 , then the system sends a message back to the
`payer requesting the needed contact information for the
`payee , step 214 .
`[ 0031 ] It should be appreciated that when the payer pro
`vides payment information , such as through the use of the
`input screen seen in FIG . 3 , the payer can be required to
`provide at least one of a physical address , email address or
`mobile phone number in order to initiate the payment
`process , and be informed by a display on that screen ( not
`shown ) that the method of payment may be based on the
`information provided . In some embodiments , the input
`screen 310 may have associated scripts running in the
`background that will not permit the payer to submit the
`information unless the payer has provided at least one of a
`phone number , email address or physical mailing address .
`The payment setup system ( through messaging between the
`payer device and the system
`100 ) can check provided
`information and verify that it is usable , such as by accessing
`external third - party telephone , email address and post office
`databases ( not shown ) .
`[ 0032 ]
`If a valid physical mailing address has been pro
`vided at step 212 , then the system 100 automatically prints
`a check ( similar to the check image 320 in FIG . 3 ) at an
`associated printing system ( not shown ) and sends that check
`( e . g . , via mail ) to the payee at the mailing address provided ,
`step 218 . In some embodiments , the system 100 may first
`print and mail to the payee a letter informing the payee that
`a check will be sent absent hearing back ( e . g . , the letter may
`show a phone number for the payee to call and request some
`other form of payment , if a check is not desired ) .
`0033 ]
`If a usable phone number or email address has been
`provided at step 210 , then the payment system 100 generates
`an electronic message ( at messaging system 110 ) to the
`payee informing the payee of the payment that is being made
`by the payer , step 220 .
`[ 0034 ]
`It should be noted that in some cases , the payee
`may have previously enrolled with the system 100 , even
`though not required for purposes of receiving payment . In
`such case , identifying information ( such as a phone number
`or email address ) provided at step 204 may be used to look
`up the payee account and the payee ' s preferences for receiv
`ing payment ( e . g . , at the enrollment database 120 ) .
`[ 0035 ] An example of a message ( such as a text message )
`sent to the payee at step 220 is seen in FIG . 4 . This message
`410 includes information on the payment ( including the
`payer and the amount ) and requests that the payee select the
`method through the payment is to be made , step 224 . As seen
`in the exemplary message of FIG . 4 , if the payee has
`previously enrolled with the payment service ( and has a
`payment service account associated with at enrollment ) , the
`payee can provide , at option 1 , a payment service account
`number ( the payment amount will be credited to a stored
`value or holding account at the payment service for later
`withdrawal or use by the payee ) . If the payee would prefer
`to have an electronic transfer of the payment , such as by an
`ACH transaction , crediting the payment to a bank account of
`the payee , the payee can select option 2 and provide a bank
`routing and account number , identifying the account into
`which the payment is to be deposited . If the payee prefers a
`paper check be mailed , the payee can select option 3 . If the
`payee prefers a check to be emailed to the payee , then option
`4 is selected . Option 4 permits the payee to either print a
`
`paper check from the returned email or use an image of the
`check for remote electronic deposit to a bank account using
`the payee ' s device .
`[ 0036 ] Returning to FIG . 2 , and in response to the selec
`tion made by the payee at step 224 , a message is returned to
`the messaging system 110 and the pertinent data is provided
`to the payment setup system 108 in order to confirm the
`details of the payment , step 226 . The confirmation by the
`system may include confirming the payment source account
`( the status of the account of the payer and its balance to
`make sure there are sufficient funds , such as by sending a
`bank balance query message to the payer ' s bank ) , confirm
`ing the payment destination account ( such as by sending an
`account verification query to the payee ' s bank to confirm the
`that payee account and the payee personal