CA2508842A1

CA2508842A1 - Cardless transaction system

Info

Publication number: CA2508842A1
Application number: CA 2508842
Authority: CA
Inventors: George A. Mcleod; Dana M. Woods
Original assignee: FIRST NATIONAL TECHNOLOGIES INC.
Current assignee: FIRST NATIONAL TECHNOLOGIES Inc
Priority date: 2004-10-21
Filing date: 2005-05-31
Publication date: 2006-04-21

Abstract

A method of conducting cardless and cashless transactions is disclosed. A user, such as from a plurality of students of one or more clients or schools, presents a familiar user ID number and a PIN at a participating merchant. A server receives the user ID and PIN from the merchant and builds a probationary user account number from the user ID, and a client ID
associated therewith. The user ID number is padded to a greater number of digits to form the user account number to ensure it is unique amongst many users and clients at the server. Before approving the transaction, the server ascertains whether the user account number and PIN is on record and if so, then further establishes if the user has a sufficient balance in a user sub-ledger account in a source bank account corresponding with the user account number. Periodically, a settlement is made between the source account and various merchant bank accounts.

Description

1 "CARDI.ESS TRANSACTION SYSTEM"

2

3

4 FIELD OF THE INVENTION
The invention relates to a method for initiating and managing an 6 electronic transaction system for a user, more particularly an electronic payment 7 system enabling deposit thereto and withdrawals from participating merchants 8 and for clearance through automated financial clearinghouse systems.

BACKGROUND OF THE INVENTION
11 There are groups of individuals who could benefit from electronic 12 payment systems, but may be excluded from the usual credit card or debit card 13 systems for one of a number of reasons including having an age less than the 14 age of majority, lacking a credit history, or merely where individuals desire to separate their usual electronic payment means from institution-specific 16 merchants. Institution-specific merchants include those having internal merchant 17 services for employees and the like such as cafeterias, and provision of other 18 goods and services.
19 Another aspect of electronic payment systems is that it is a typical requirement to have a physical device such as a wallet-sized card as the means 21 for both identification of the individual and the individual's financial information.
22 Such cards are sometimes lost with the inconvenience and risk associated 23 therewith and additionally are simply one more item to keep track of in an ever 24 more cluttered wallet.

1 It would be desirable to have an electronic payment means 2 between specified merchants and an individual of a known group which could 3 provide financial access without a card when desirable.

7 Accordingly, in one preferred aspect, an electronic payment system 8 is provided and which functions as a virtual smart card. A physical card or other 9 identifier is not mandatory, although one can be accommodated. instead, a familiar, easily recalled user-identifying number or user ID is all that is required 11 as discussed below. The user ID need only be unique among a small 12 population, even amongst a very large number of users contemplated in the 13 system.
14 A system server is in electronic communication with one or more participating merchants. A participating merchant is authorized to provide goods 16 and services to a specified group of users of a specified client. The participating 17 merchant is permitted to interact with a user of the authorizing client and permit 18 electronic transactions, the transactions including financial and non-financial 19 transactions. The system can manage one or more clients. Participating merchants are associated and authorized for participation with only one of said 21 clients and not others. A merchant will present a unique identification in the 22 system despite the possibility of several merchants having common ownership 23 or control.

1 In one embodiment, a user is a person within a specific group of 2 persons who can register an identifying number which has a limited number of 3 digits and identifies the user from other users in the specific group. The specific 4 group is typically a client such as a school or institution. An account is created and a unique user account number is created having a more secure and greater 6 number of digits and which incorporates the identifying number for distinguishing 7 the user from other users in any other groups. A personal identification number 8 (user PIN) is assigned to the user account number. Usually a single source 9 bank account is maintained, and a database links the various users through their unique user account numbers to a fractional monetary value of the account. A
11 sub-ledger of each user's account balance is maintained in a system separate 12 from the banking system. For simplicity, the banking system sees one account 13 and one account balance despite a plurality of user and virtual sub-ledger 14 accounts.
At participating vendors or authorized merchants, at a minimum, a 16 user need only to provide the identifying number and their user PIN. No 17 particular physical medium is required. When the identifying number is used in 18 an electronic transaction, it must be distinguished from other coincidentally 19 identical identifying numbers of other clients. During a transaction, such as a withdrawal request, the merchant's location or identification, the user's 21 identifying number and user PIN is forwarded to the system server and the 22 corresponding client ID is identified and the unique user account number is 23 generated. If the user account exists and the user PIN is valid then the 24 transaction is completed.

1 On periodic batch intervals (such as once per day), the server 2 queries the banking system for any deposits made to the source account to the 3 credit of a specified user account number. The corresponding user's sub-ledger 4 balance is updated. Upon a merchant's query such as a withdrawal request, the user's balance is checked, the query authorized, and the user's balance in the 6 sub-ledger is debited. Multiple transactions can be made and a withdrawal 7 request could also comprises a refund request. After a period (such at the end 8 of the day), a settlement is made through the banking system to perform an 9 electronic funds transfer (EFT) between the source account and all transacting merchants and the sub-ledger accounts are appropriately adjusted.
11 The system manages one or more databases comprising lists and 12 cross-references of clients, users, merchants and user accounts. As discussed, 13 clients are typically a company or a school; however a client may include a 14 school district having several schools. Respectively, typical users would be employees or students. A school may include several types of merchants such 16 as a third party independent vendor or discrete legal entity operating a cafeteria 17 within a school or may include a school-operated enterprises within the school 18 itself. The school division is preferably distinguished from the school as a "client"
19 aspect by terms such as school tuck shop, client-managed cafeteria or school store. Each merchant would have a unique merchant ID or address. Each user 21 belonging to a client has a unique identification number amongst the client's 22 users and a corresponding sub-ledger user account.
23 By design, the users are preferably restricted in their access to 24 merchants; users can only conduct transactions under the system with client 1 authorized merchants, usually located on the same premises as the client.
The 2 database cross-references users, clients and merchants and particular users or 3 groups of users can be authorized to access specific merchants. Similarly, 4 merchants are only authorized to provide services and accept a payment request from users of the authorizing client. The client typically assigns the 6 authorizations.
7 Further, the system processes both financial and non-financial 8 transactions. For example, an asset management and student tracking module 9 processes non-financial transactions such as quanti>'iable management control including for the issuance, return and loss of school text books, sports and music 11 equipment, shop supplies, etc.. A student tracking module processes 12 attendance information and prints late slips online to provide direct and positive 13 communication with parents via email and an interactive Internet website.
In 14 such cases, the user account number is associated with additional fields including assets, such as school equipment and books, and performance 16 characteristics including attendance and grades.
17 Therefore, in a broad aspect, a method for conducting electronic 18 financial transactions comprises establishing a user account and a user account 19 balance in one or more source accounts for each of a plurality of users associated with a client and establishing one or more merchants authorized by 21 the client; receiving a withdrawal request from one of the plurality of users at a 22 server on a distributed network from an authorized merchant on the distributed 23 network, said withdrawal request including a withdrawal amount, a user-24 identifying number and a user PIN; establishing a probationary user account

5 1 number from the received user-identifying number, a client ID corresponding to 2 the client and padding the user-identifying number to a pre-determined number 3 of digits, and comparing the probationary user account number to a user account 4 number at the server to determine if the probationary user account number is a valid user account number for a user of the client and, if valid, comparing the

6 received user PIN to the user PIN for the user account number to validate the

7 electronic transaction.

8 Preferably, before completing the transaction the system further

9 comprises establishing that the withdrawal amount does not exceed the user account balance, and if it does not, then debiting the withdrawal amount from the 11 user account balance for the user's user account number, and periodically 12 conducting a settlement electronic financial transaction between the at least one 13 source bank account and a merchant bank account for the authorized merchant.

BRIEF DESCRIPTION OF THE DRAWINGS
16 Figure 1 is a flowchart of various users, merchants, clients, a 17 banking system and a server in electronic communication as part of a cashless 18 transaction system according to one embodiment of the invention;
19 Figure 2 is a flow chart illustrating some of the elements of the server of Fig. 1 in a transaction between a user and a merchant; and 21 Figure 3 is a flow chart illustrating aspects of the server and the 22 database of users and user account numbers.

2 With reference to Fig. 1, in one embodiment, a system is provided 3 for enabling cardless transactions for the tracking of assets including cashless 4 financial transactions and tracking of physical assets and user performance characteristics. For example, in an educational context, the system enables 6 transactions for users of the system including financial services, attendance 7 tracking and student asset tracking such as school supplies and books. The 8 assets are dispensed to users through authorized asset distributors. In one 9 preferred embodiment, financial transactions are provided between user and merchants as well as in conjunction with other asset tracking functionality.
11 In a financial context, cashless financial transactions are enabled 12 for users associated with a client and between those users and merchants.
The 13 merchants are asset distributors, said merchants being authorized by the client 14 to conduct transactions with that client's users. Illustrative, but not limiting in its context, one embodiment of the invention would enable a student Smith in a first 16 school to present an easily remembered or familiar user-identifying number 17 (familiar ID or user ID) to a school cafeteria. Particularly with children as users, 18 conventional cards often become lost, yet a familiar user ID can be recited from 19 memory. Student Smith is one of a plurality of users associated with a particular client having a client identifying number or client ID, in this case the client being 21 a school or school system, and the authorized merchant could be a school 22 cafeteria. Student Smith would have funds as evidenced in a sub-ledger for 23 Smith at the server. A positive balance could result from an earlier deposit such 24 as that made by Smith or Smith's parents.

1 During a financial transaction in which the student user requests a 2 withdrawal of funds, the merchant cafeteria would obtain at least this familiar 3 user ID (being a student number or other numerical ID that could even be 4 specified by Smith and initially registered with the system) and the student's PIN.
The merchant would then electronically identify themselves to a server, such as 6 by address or other merchant identifier or ID. Thereafter is a process of 7 establishing if the student Smith in fact has a user account number in the system 8 and is authorized to make the withdrawal, both by identity and that Smith has 9 suf>~icient financial resources.
The combination of the user ID and the client ID enable 11 establishing if a user, such as student Smith of the first client or school, is 12 permitted to engage in a transaction with that client's merchant or cafeteria.
13 Upon confirming the student Smith's PIN and if Smith has sufficient funds as 14 evidenced in a sub-ledger for Smith, then the server can authorize the transaction. At some point in time, such as at the end of the day, the 16 transactions, the sub-ledger balance for a sourse bank account and the 17 merchant's bank account are reconciled through an automated clearinghouse 18 system.
19 It is possible for a user of one client to have the same user identifying ID as a user of another client, such as another school. In order for the 21 server to distinguish one user of one client from users of another client, each 22 user has a user account number which has a sufficient number of digits to be 23 unique amongst all the users of all the clients in the system. In one simple 1 embodiment, the user account number includes the user ID and the client ID
2 padded to a larger number of digits.
3 Integrity of the system is assured through assignment of this 4 unique user account number generated from the familiar ID, the user account number being unique from any other user account number at the server 6 regardless of the client. The user account numbers would be unique even if the 7 same familiar ID was used by student users or employee users at different 8 schools or places of business. Each school, or school system, would be 9 identified as a different institution or client and the user account number would reflect the membership of the student for that client. A typical client of the 11 present system comprises a school system having many schools, the students in 12 the plurality of schools in the school system all belonging to the same client and 13 having unique student ID's therein.
14 The user account number also ensures a secure system of asset management for all of the users including one or more asset accounts 16 maintained in sub-ledgers in the system for tracking assets including funds. A
17 user or some other benefactor such as a parent or the client themselves can 18 apply credit to the user's sub-ledger for establishing a credit in the sub-ledger 19 from which assets can be debited.
Accordingly, in greater detail, a system for conducting electronic 21 transactions including financial transactions comprises a server 20 in 22 communication with users 10 and authorized asset distributors such as 23 merchants 21 (such as merchants M1,M2 ...) at a known institution or client 1 (such as C1) over a distributed network 23 such as the Internet.
Geographically, 2 merchants 21,M! and M2 are usually located at the location of the client 22.
3 The server 20 manages user asset accounts and asset balances, 4 authenticates debit requests by merchants 21 for a user 10 and, in financial transactions, would settle financial accounts between a server's source account 6 25 and each merchant's account 26.
7 The server 20 includes a database 27 for managing clients 22, 8 users 10, merchants 21 and user accounts. Through an interactive interface or 9 other registration process, clients 22 and one or more of the client's users

10 are recorded in the database 27. Each user 10 belonging to a client 22 has a unique

11 use- identifying number (user ID) amongst the client's users. Each user 10 has

12 a sub-ledger for their user account. The database cross-references users 10,

13 clients 22 and merchants 21.

14 Merchants 21 are associated with a particular client 22 C1,C2 ... .
A user 10 of the client C1,C2 can include an employee 10 of a company C1, or a 16 student 10 at a school CB or alternatively students 10,10 in a school system C2.
17 A user 10 can be authorized to frequent one or more merchants 21.
18 For example, first and second merchants 21,M1 and 21,M2 and all users 10 of a 19 first client 22,C1 are authorized to conduct financial transactions according to an embodiment of the invention. A third merchant 21,M3 is not so authorized, 21 however this third merchant M3 can be authorized to conduct financial 22 transactions with users 10 of a second client 22,C2.
23 The database 27 further comprises a user account number and 24 user PIN to uniquely identify the user's accounts and authorize access thereto.

1 The user account number is generated at the server 20. The user PIN may be 2 generated and is typically changeable by the authorized user 10.
3 The user account number is a number having sufficient numbers of 4 digits to enable assignment of unique numbers to every user 10,10 ... of every client 22,C1,C2 ... in the database 27. In most instances a suitable length of 6 user account number is 20 digits.
7 A component of the user account number is the generation of a 8 numeric user ID which is unique from other numeric ID's for the client 22.
Due to 9 the finite number of users 10 for a client 22 or institution, the numeric ID
would typically be an employee number or student ID number which is familiar to the 11 user 10 and which is assigned by the client 22 or chosen by the user 10.
The 12 familiar ID or user ID, is limited in the number of digits and therefore limited in 13 numerical combinations, and is therefore restricted for distinguishing between 14 users 10 in a small population. The greater number of digits of the user account number comprises a more secure and unique number amongst all users of all 16 participating clients. The greater number of digits of the user account number 17 incorporates the fewer digits of the user ID. The familiar ID is preferably 18 parsable or recognizable within the final user account number. For example, a 19 user 10 from a first school C1 can have an 8-digit student ID "12345678".
For ease of recognition of their own user account number, it is advantageous to 21 reflect the user's 8-digit student ID as the familiar user ID and to pad it with 12 22 additional digits to form a 20-digit account number "987654321098 12345678"
23 which is unique in the server.

1 Table 2 User 12345678 Pad Number to larger 3 number of digits 12345678 for a unique account number 4 A resulting account number 6 Similarly, a 6-digit student ID "123456"
for a user from a second 7 school itional digits to C2 would form a 20-digit be padded account with 14 add 8 number "98765432109876 123456".

9 Table 14 Preferably, the unique user number includes the familiar ID, and an indication or identification of the client 22.

16 Table User _ 123456 Pad Number to larger number of digits 123456 for a unique account number A resulting accountgg765432109876123456 number User 123456 Client 001 Pad Number to larger number of digits <001123456 for a uni ue account number A resulting account gg7g5432109001123456 number There are many forms of algorithms known to those of skill in the 21 art which can provide unique account numbers from root numbers. Padding can 22 be through masks or hashing algorithms.
23 In one embodiment, the padding digits may comprise a simple 24 padding with zeros and a prefix.

1 Table 4 2 User 123456 Client 001 3 Pad Number to larger number of digits using 4 simple filler far 123456 a client and a unique account number A resulting account number having both 10000000000001123456 client ID and user ID therein In another embodiment, the padding digits may comprise a hash 6 based in part upon a unique number assigned to the particular client.
b1 7 Ta a 5 8 User _123456 Client 001 Pad Number to larger number of digits using an hash algorithm for 123456 a client and a unique account number A resulting account number in which 1 8472858335001123456 the client ID is maintained discrete from the hash 9 For financial aspects of the transactions, the server 20 is also in electronic communication with the electronic banking system such as an 11 automated clearinghouse system ACH System 30 which is authorized to engage 12 and settle electronic financial transactions.
13 The known ACH System 30 is in communication with and enables 14 transactions between the server 20, a system or source bank account 25 and one or more merchant's bank accounts 26.
16 ACH Systems 30 are known to those of skill in this art. Simply, as 17 it applies in Canada, the relevant ACH system 30 is the Automated Clearing 18 Settlement System (ACSS) handing about 99% of the volume of transactions 1 and the Large Value Transfer System (LVTS) which clears about 85% of the 2 value of the transfers such as in settlements of a day's cumulative transactions.
3 More information is available from the Canadian Payments Association at 4 www.cdnaay.ca. In the US, the Federal Reserve Banks are collectively the largest automated clearinghouse operators in an ACH System 30. There are 6 also private-sector ACH operators processing the balance of the financial 7 transactions. More information on US ACH Systems is available at the National 8 Automated Clearinghouse Association (NACHA) at www.nacha.ora.
9 In one embodiment, the system limits the user's access to participating merchants. A participating merchant 21 would be a merchant 11 authorized to receive funds from users 10 of the client 22. For example, in an 12 education institution context, a student user 10 may be able to freely access the 13 system for payment of various school fees 21,M1 and cafeteria fees 21,M2 of 14 that particular educational institution 22,C1, but would not be able to access the system for a convenience store across the street. A parent would be particularly 16 interested in such a system for controlled disbursement of funds earmarked for 17 school expenditures only.
18 A participating merchant 21 has a merchant identification ID. The 19 merchant ID is associated with a particular client institution such as 22,C1 or 22,C2 but not both.
21 The merchant 21 has a terminal for electronic access to the server 22 20. The terminal at its most elementary comprises means for entering the user 23 numeric ID and user PIN, means for communicating the user ID, PIN and some 24 identification of the merchant ID to the server 20. In one instance, the merchant 1 ID is provided in the form of a static Internet protocol (1P) address, which 2 identifies the merchant 21 and by default identifies the association with a 3 particular authorizing client 22. For example the server 20 would understand 4 that a cafeteria merchant IP address would identify both the merchant 21 (the cafeteria) and the client 22 (the particular school in which the cafeteria was 6 located).
7 More preferably, the merchant terminal comprises additional or 8 alternate means of entry. Such alternate entry means can include magstripes, 9 barcodes, and iris / palm-metric readers in those instances where a card is provided. Often cards are provided by a school client and which identify the 11 student user ID. Accordingly, the system can accept the card (as identifying the 12 user ID) and the user PIN.
13 The client 22, such as a particular school or commercial institution 14 in which the merchant 21 operates, is established. Typically, it is assumed that a merchant's terminal in communication with the server 20 is a terminal of an 16 authorized merchant 21. Therefore, a merchant ID, being identification of the 17 merchant terminal, is looked-up or cross-referenced at the server 20 to identify 18 its corresponding authorizing clients 22 or particular users 10 of the client.
19 Alternatively, the merchant terminal device could transmit or otherwise communicate the identity of the client 22.
21 With reference to Figs. 2 and 3, in use, the system include the 22 server 20 communicating over a distributed network 23 with at least one client 23 22, and at least one merchant 21. Detailed in Fig. 3, the server 20 maintains a 24 database 27 of one or more clients 22, one or more merchants 21, a plurality of 1 users 10 and assets and additional details therefor. One more clients 22 are 2 registered with the system and each are assigned a unique client ID. Users 3 of each client 22 are registered, possibly in a bulk registration initiated by the 4 client 22 or as individual users 10 indicate their interest in accessing the system.
Users 10 are provided with an access interface (not shown) to the 6 distributed network 23 for registering or amending their user account information.
7 Users preferably choose a familiar number as their user ID, such as their student 8 number. The system could suggest their student ID and provide an option to 9 enter an alternate ID which is compared against other users of the client to ensure it is unique. A user's personal identification number PIN is either initially 11 assigned and subsequently changed by the user 10 or the user is prompted to 12 enter a desired user PIN.
13 The system generates a unique user account number for the user 14 in the database 27 of all clients 22. The familiar ID is padded and generated as necessary to the greater number of digits as the user account number used to 16 uniquely identify the user. In some instances, a device may also be generated 17 including a magnetic card, or to obtain biometric data for association with the 18 user account.
19 The system maintains at least one source bank account 25 (Fig. 1 ).
The user account number is associated with a sub-ledger maintained in the 21 database which represents the user's balance in the source account. There can 22 also be sub-ledger for non-financial assets such as academic marks, books or 23 attendance for example.

1 Users or benevolent third parties can make deposits to the financial 2 sub-ledger associated with the user account number through personal online 3 banking portals; said deposits being directed to the system's source account and 4 credited to the sub-ledger which is registered with the ACH System. The system is electronically linked to participating merchants 21 for accepting a withdrawal 6 request from a user.
7 For non-financial transactions, the sub-ledger may monitor quantity 8 and serial numbers of assets lent or returned or tracking of the types of assets of 9 interest.
Returning to Fig. 2, when a user 10 requests a good or service 11 from a participating merchant 21, the merchant forwards a withdrawal request to 12 the server 20 including the amount of the transaction, an identification of the 13 merchant 21, the user's user-identifying ID number or full account number and 14 the user PIN. The server 20 determines if the merchant 21 is authorized to conduct the requested financial transaction, whether the user 10 is a valid user 16 of the client 22 and if the particular user 10 has the sub-ledger balance.
17 More particularly, at block 100 the server 20 uses the received 18 merchant ID and looks up a corresponding client ID in the database 27 (see 19 routing to Fig. 3 at 3). While typically an unauthorized merchant would not have the access to the server 20 at all, if the merchant 21 is found not to be 21 authorized, or perhaps is no longer authorized, then an error is generated at 201 22 and the merchant 21 receives back a declined error message at block 200.
23 At block 101 the server 20 then establishes a probationary user 24 account number from the received user-identifying number or user ID, a client ID

1 corresponding to the client 22 and padding the user-identifying number to a pre-2 determined number of digits. Using one of many possible algorithms, the user 3 ID is combined with the client ID and is padded to the full number of digits.
4 At block 102, the server compares the probationary user account number with user account numbers looked-up at the server to determine if the 6 probationary user account number is a valid user account number for a user 7 of the client 22. If the user account number is not found then the user 10 may 8 not be authorized, does not exist or perhaps is a user of another client and an 9 error is generated at block 202 and the merchant 21 receives back a declined error message at block 200.
11 If the user account number is found, it is a valid number and at 12 block 103 the server compares the received user PIN to the user PIN for the 13 user account number to validate the electronic transaction. At block 203, if the 14 PIN does not match then the error is noted and the merchant 21 receives back a declined error message at block 200.
16 At block 104, if the user PIN corresponds with the user account 17 number then the server 20 checks the user account number's sub-ledger 18 account for sufficient funds to meet the withdrawal request. If the withdrawal 19 amount exceeds the user's account balance, then at block 204 it is known there are insufficient funds and the merchant 21 receives back a declined error 21 message at block 200.
22 If the quantum or withdrawal amount does not exceed the user 23 account balance, then at block 105 the transaction is completed wherein the 24 sub-ledger is debited and periodically at some point, a settlement electronic 1 financial transaction is conducted between the at least one source bank account 2 25 and the merchant's bank account 26.
3 In the above embodiment, the user 10 can conduct the transaction 4 without necessarily possessing a physical card. The server 20 need only be able to ascertain the authority of the merchant 21 and the user 10 to conduct a 6 transaction. In one scenario, the server determines if the user ID and the 7 merchant ID are associated with a common client 22. In the preferred scenario 8 as shown in Figs. 2 and 3, the familiar user ID and the merchant ID are 9 submitted to the server 20 to establish the authorizations necessary to permit the transactions and to verify the presenting individual's right to debit the user's sub-11 ledger.
12 If authorized, the transaction is completed at block 105 and then 13 the merchant 21 is advised that the transaction was approved. Periodically, the 14 system conducts a settlement electronic financial transaction between the source bank account 25 and the bank account 26 of the authorized merchant 21.
16 The periodicity is generally dependent upon economies of substantially real time 17 or batch settlements. Typically settlement can occur at the end of each business 18 day.
19 Settlement comprises accessing the ACH System for transferring an amount, typically the transaction amount, to the merchant's account 21. The 21 user's account balance in the sub-ledger is debited. Further, any deposits to the 22 user's account are acknowledged and the ACH System debits the benefactor or 23 payor's account to the credit of the systems' source account and the user's 24 account balance in the sub-ledger is credited.

1 Options for assigning a familiar user ID include: pre-determination 2 and specification of the familiar user ID by the client 22 for their plurality of users 3 10, auto-generating familiar ID's by the server 20, and preferably selection of 4 user ID by the user 10 themselves, subject to a uniqueness confirmation. A
user's selection of a user ID would typically include their employee number, 6 student identification number or drivers license number.
7 As discussed above, the cashless transaction system is integrated 8 with the banking systems. The system functions as a virtual smart card. The 9 system enhances known prepaid cash or debit cards (such as prepaid phone cards) in that: there are no expiry dates or preset limits, there are no age 11 restrictions or credit application procedures; and maintenance of the account 12 balance is dynamic. This system and the banking system process all monetary 13 and non-monetary transactions either online or offline, at the point-of-sale (POS).
14 Users 10 can also deposit money into their user account at the POS, with telephone banking, at ATMs or over the Internet through most financial 16 institutions.
17 Through an interactive interface to the server 20, a user 10 can 18 register virtually any identifying user ID number they choose to obtain a user 19 account. As discussed, to use the user account for a transaction, a user 10 need only provide their user ID. The user 10 does not require the use of any 21 physical medium, however, optionally, the means for identifying the user 10 can 22 take on any physical form to communicate the familiar user ID or the whole of 23 the user account number including cards magstripes, barcodes, and biometric 24 means such as iris scanners, fingerprint and palm-metric readers.

1 To expand the range of authorized merchants 21, the system can 2 be integrated with third party Internet based shopping cart applications, 3 Windows~ based hand-held devices and Windows~ based POS software.
4 The interface to the server 20 is interactive, which allows users 10 to register their user accounts and to view of all of their monetary and non-6 monetary transactions in real time. In such cases, the user account number is 7 associated with additional fields including assets, such as school equipment and 8 books, and performance characteristics including attendance and grades.
9 Additional functionality of the system includes providing users and authorized third parties such as parents of student users with direct positive 11 confirmation of attendance, issued school assets and purchases. An asset 12 management and student tracking module can process non-financial 13 transactions such as quantifiable management control including for issues, 14 returns and losses of school text books, sports and music equipment, shop supplies, etc.. A student tracking module processes attendance information and 16 prints late slips online to provide direct and positive communication with parents 17 via email and an interactive intemet website.
18 For example, in this optional embodiment, a teacher's terminal for 19 accessing the server 20 would have an equivalent merchant ID and clearly represent the school client ID as well. A teacher can enter values for the student 21 under the student's user ID. The values which represent attendance missed, 22 book loans and the like. Each entry represents management of an asset which 23 is managed in a sub-ledger of the student in a manner similar to that of the 24 financial transactions. Each sub-ledger entry is associated with the full user account number in the system but is merely accessed using the user ID from a 2 terminal associated with the particular client 22.

Claims

THE EMBODIMENTS OF THE INVENTION FOR WHICH AN
EXCLUSIVE PROPERTY OR PRIVILEGE IS CLAIMED IS DEFINED AS
FOLLOWS:

1. A method for conducting electronic financial transactions comprising:
maintaining at least one source bank account which is electronically linked for accepting transaction requests, including one or both of electronic withdrawal and deposit requests, and one or more of deposit to and withdrawal from at least one merchant bank account;
maintaining a database system of one or more clients, each client having a unique client ID number, a plurality of users authorized to electronically access the at least one source bank account, each user having a unique user account number in the database, a user PIN and a user account balance, establishing a unique user account number in the database system for each user including a user-identifying number being unique amongst the plurality of users of the client, and padding to a greater and pre-determined number of digits so that the user account number is unique from all others in the database; and maintaining in the database system one or more authorized merchants that are authorized by each client to receive a withdrawal request from users of that client; and for each electronic transaction, receiving a transaction request from a merchant for a user including an amount, the user-identifying number and the user PIN and at least a merchant identifier;

establishing the client ID number associated with the identified merchant;
establishing a probationary user account number from the received user-identifying number, the client ID number and padding to the pre-determined number of digits, and comparing the probationary user account number to the user account numbers in the database to determine if the probationary user account number is a valid user account number and, if valid, comparing the received user PIN to the user PIN for the user account number to validate the transaction and, if validated, completing the electronic transaction for the transaction amount.

2. The method of claim 1 wherein the transaction request is a withdrawal request, and prior to conducting the electronic transactions, further comprising:
establishing that the quantum of the withdrawal request does not exceed the user account balance, and if it does not, then debiting the quantum from the user account balance for the user's user account number, and periodically conducting a settlement electronic financial transaction between the at least one source bank account for one or more users and the authorized merchant's merchant bank account.

3. The method of claim 1 wherein prior to conducting electronic financial transactions, further comprising specifying the user-identifying number by the client.

4. The method of claim 1 wherein prior to conducting electronic financial transactions, further comprising specifying the user-identifying number by the user.

5. The method of claim 1 further comprising identifying the client ID number using one or more digits within the user account number.

6. The method of claim 1 wherein the user account number includes the user-identifying number and the client ID number.

7. The method of claim 1 wherein the receiving of the withdrawal request further comprises an identification of the authorized merchant.

8. The method of claim 1 wherein the receiving of the withdrawal request further comprises identification of the client ID number.

9. The method of claim 1 wherein the receiving of the transaction request further comprises an indication of a merchant address and, prior to establishing a probationary user account number, further comprising looking up the client ID number corresponding to that address for.

10. The method of claim 9 wherein the address is an IP
address.

11. The method of claim 1 wherein the merchant is also the client.

12. The method of claim 1 further comprising managing each user account balance as a sub-ledger balance within the at least one source account.

13. The method of claim 1 further comprising prior to conducting financial transactions further comprising crediting the user's account through an electronic financial transaction to the credit of the at least one source bank account.

14. The method of claim 1 wherein the merchant is located at the client.

15. The method of claim 14 wherein the client is also the merchant.

16. The method of claim 1 wherein the users are students and the client is a school.

17. The method of claim 16 wherein the merchant is a service located in the school.

18. The method of claim 16 wherein the merchant is an independent entity discrete from the school.

19. The method of claim 16 wherein the school is also the merchant.

20. The method of claim 1 further comprising tracking of the attendance of the user at the client.

21. The method of claim 1 further comprising tracking of non-financial assets obtained and returned to the merchant.

22. A method for conducting electronic financial transactions comprising:
establishing a user account and a user account balance in one or more source accounts for each of a plurality of users associated with a client and establishing one or more merchants authorized by the client;
receiving a transaction request from one of the plurality of users at a server on a distributed network from an authorized merchant on the distributed network, said transaction request including a quantum, a user-identifying number and a user PIN;
establishing a probationary user account number from the received user-identifying number, a client ID corresponding to the client and padding the user-identifying number to a pre-determined number of digits, and comparing the probationary user account number to a user account number at the server to determine if the probationary user account number is a valid user account number for a user of the client, and if valid comparing the received user PIN to the user PIN for the user account number to validate the electronic transaction, and adjusting the user account balance by the quantum.

23. The method of claim 22 wherein the transaction request is a withdrawal request and wherein adjusting of the user account balance further comprises:
establishing that the quantum of the withdrawal request does not exceed the user account balance, and if it does not, then debiting the quantum from the user account balance for the user's user account number, and periodically conducting a settlement electronic financial transaction between the at least one source bank account and a merchant bank account for the authorized merchant.

24. A method for conducting asset management transactions comprising:
maintaining at least one user-asset account which is electronically linked for accepting a debit request from, and deposit request to, at least one asset-distributing entity account;
maintaining a database system of one or more clients, each client having unique client ID, a plurality of users authorized to electronically access the at least user-asset account, each user having a unique user account number in the database, a user PIN and a user account ledger, establishing a unique user account number in the database system for each user including a user-identifying number being unique amongst the plurality of users of the client, and pad with additional numbers to a greater and pre-determined number of digits so that the user account number is unique from all others in the database; and maintaining in the database system one or more authorized distributing entities that are authorized by the client to distribute assets to a user upon receipt of an asset debit request from that user; and for each electronic transaction, receiving an asset change request from a distributing entity for a user including a quantum, the user-identifying number and the user PIN and at least an distributing entity ID;
looking up the client ID in the database system for the client which authorized the distributing entity;
establishing a probationary user account number from the user-identifying number, the client ID and padding to the pre-determined number of digits, and comparing the probationary user account number to the user account numbers in the database to determine if the probationary user account number is a valid user account number and, if valid, comparing the PIN to the PIN for the valid user account number to validate the transaction and, if validated, adjusting the user account balance by the quantum.

25. A system for conducting electronic financial transactions comprising:
a server on a distributed network;
at least one source bank account accessible on the distributed network through an ACH system;
at least one database accessible by the server and having a user account number and a user account balance in the at least one or more source bank accounts for each of a plurality of users associated with a client of one or more clients, each user account number comprising a user-identifying number, a client ID and padding numbers to a pre-determined number of digits;
one or more merchants accessible on the distributed network and known by the server, each merchant being associated with and authorized by client, each merchant capable of forwarding a transaction request from one of the plurality of users for receipt at the server, said transaction request including a quantum, a user-identifying number and a user PIN;
one or more merchant bank accounts accessible on the distributed network through an ACH system;
a user account generator for generating a probationary user account number from the user-identifying number received from the merchant, a client ID obtained from the database which corresponds to the merchant and padding the user-identifying number to a pre-determined number of digits, and a validator for comparing the probationary user account number to one of the plurality of user account numbers at the server to determine if the probationary user account number is a valid user account number for a user of the client, and if valid comparing the received user PIN to the user PIN for the user account number to validate the electronic transaction; and a user account balance manager for adjusting the user account balance in accordance with the transaction request by the quantum.