WO2001003079A1

WO2001003079A1 - Pooled resource e-value multiple provider systems

Info

Publication number: WO2001003079A1
Application number: PCT/US2000/017960
Authority: WO
Inventors: Richard Leslie Bishop; Jay Raymond Slusher
Original assignee: Amdahl Corporation
Priority date: 1999-07-06
Filing date: 2000-06-29
Publication date: 2001-01-11
Also published as: AU5780200A

Abstract

An electronic commerce system formed of service group owners, such as banks, having ownership, respectively, of groups of e-value stores. A pooled resource server communicates with each of the groups of e-value stores and each of the service group owners so that each service group owner is not required to duplicate the facilities of the pooled resource server in order to operate an e-value electronic commerce system. The pooled resource server includes a storage unit for storing transaction information for each of said plurality of service group owners and includes a processor for controlling e-value transactions among the groups of e-value stores and the service group owners based upon said transaction information.

Description

TITLE

POOLED RESOURCE E-VALUE MULTIPLE PROVIDER SYSTEMS

INVENTORS Richard Leslie Bishop

Jay Raymond Slusher

BACKGROUND OF THE INVENTION

The present invention relates to the field of electronic commerce and particularly to methods and apparatus for storage and transfer of electronic funds and other value data.

Value data is stored, processed and transferred using data processing systems. To maintain the security of value data, data processing systems employ security controlled devices. By way of example, security controlled devices are used in data processing systems to create cryptographic systems, identification systems and electronic commerce (e-commerce) systems Security controlled devices, electronic devices having security features Portable security controlled devices are frequently implemented as smart cards or other small electronic devices The security of value data, including e-cash, that are stored on smart cards relies upon smart card designs and procedures intended to prevent unauthorized changes or transfers of that value data

In the field of electronic commerce, wire transfers are one electronic method for the transfer of value data where funds are transferred from one trusted party to another In a wire transfer, one party makes a debit book entry and the other party makes a credit book entry as a result of value data electronically sent from one party to another in accord with preestablished procedures agreed to by the parties The wire transfers are usually subject to clearing operations to verify that the debit and credit entries have been made correctly and to reconcile the accounts between the parties The security of the wire transfer of funds is higher if the value data transfer that implements the wire transfer is encrypted using electronic encryption- /decryption devices, codes or algorithms

In the field of electronic commerce, electronic cash (e-cash) is another electronic method for the transfer of value data that involves the transfer of funds from one party to another Electronic cash methods include two types of transfers, namely certificated value and net value transfers

For the certificated value type of electronic cash, an issuer generates electronic value or transaction records, generally cryptographically encoded and authenticated, that represent distinct amounts of value These electronic value or transaction records may be passed from one electronic cash device to another electronic cash device For example, the transfer of funds may occur from a smart card held by one party to an electronic cash device held by another party

In one form common to consumers, smart cards are portable cards similar in form and size to common credit or debit cards In an alternate miniature form, the size of smart cards is reduced to a small physical size, smaller than a common credit card, which perform the function of a larger, full-sized card Typically, for certificated value transactions, a smart card is issued by an issuer and dispensed to a first party (for example, a purchaser) where the card is either pre-loaded or subsequently loaded with stored electronic value or transaction records (certificates) E-value data marked as associated with the first electronic record, is passed by the first party to an electronic device of another party (for example, a merchant) and, eventually, value data is returned to the issuer by the other party for redemption in an amount equal to or not exceeding the electronic record (certificate) Usually, electronic cash devices used by merchants, banks and other financial institutions are under the administrative or technical control of an issuer For the net value type of electronic cash, the electronic value is represented by the net amount stored in an electronic device without need for further external accounting. Specifically, in the net value type of electronic cash, value transactions are accomplished by value data transfers between security controlled devices, where value data records for each transaction are not necessarily sent to the issuer for redemption. The net value type of electronic devices are called value stores and each is capable of storing a net amount of value that reflects the accumulated aggregate of value transfers from and to that value store.

Value stores can be implemented using smart cards that are similar to those used for the certificated value type of electronic cash except that the rules controlling the transfer of value are appropriate for the net value type of e-cash. In net value electronic funds systems, merchants, banks or other institutions are the issuers that issue value stores (usually in the form of smart cards) to customers.

Typically, in the e-cash application, institutions, at the request of an individual, transfer value to or from the individual's smart card. As a consequence of the transfer of value, compensating value flows between a selected account of the individual and the institution's own accounts. Typically, a transfer of value to an individual' s card is called a "load" operation and a transfer of value to the institution is called an "unload" operation. The electronic nature of the transfer mechanisms involving smart cards allow remote electronic transfers of value to or from individuals' cards. The ability to load value (withdraw money) or to unload value

(deposit money) without actually going to the premises of a financial institution is a primary motivation for smart card use.

New banking and other services that require security are enabled through the use of smart cards. Service institutions, which typically are banks or other service providers seek low entry cost methods of providing e-cash services using smart cards. These new services may require the modification of blocks of data and programs on the smart card, a process sometimes called "application load" or

"application unload."

Smart cards typically have an established "ownership" association with a service institution which usually is the issuer of the cards. The group of smart cards issued or owned by a particular institution (such as a bank) are known as the

"domestic" cards of that owner, and the institutions are known as "service group owners." The ownership relationship of a group of cards is established when the cards are issued, but in other cases the ownership relationship may be transferred at a later time. The transfer may be for the entire group of smart cards and all of the smart card applications that reside on the cards, or may be only for specific ones of the applications on the cards for a group of smart cards and for as few as only one of a group.

In some smart card uses, value data is transferred from smart card to smart card. Such transfers are mediated by an electronic terminal connecting the cards either directly or through a network. In other smart card uses, the value data is transferred to or from a smart card from a computing device connected to the cards either directly or through a network.

For card to card transfers, in some implementations, transfers of value are from a smart card retained by the institution to or from the customer's smart card. Financial institutions may retain pools of smart cards for use in remote value transfers with individuals and with other institutions. Smart cards retained for internal use in institutions are not required to be identical in form to those issued to customers. Frequently, however, in order to simplify security and processing, the retained and issued smart cards tend to be nearly identical, in which case, an institution's retained smart cards differ from customer issued smart cards only in programable details such as the limit on the amount of value that can be contained on the card. Smart cards typically contain only a processor, memory, and electronic interface logic and therefore smart card operations generally require that the associated smart card terminal perform customer interface and coprocessing. The connection between the smart card and the smart card terminal may be a physical connection or by remote sensing means such as proximity radio frequency or optical connection. Many smart card services require that a smart card terminal be connected to the computers of the smart card service provider. For various reasons, smart card terminal devices available to customers may not be directly connected to the owner ("domestic") service institution. Some terminals may be controlled by other ("foreign") service institutions. Some terminals may connect to one or more installations when required, for example, using the Internet or the public switched telephone system. When connected, they may connect to a domestic or foreign service institution. Also, services may be desired from multiple service institutions and service institutions may wish to share terminal communications and processing costs. Further, regulating and licensing bodies may require certain processing and configuration rules.

Terminal devices that support smart card operations may be public or private. Public terminal devices (PuTDs) may be integrated into conventional cash- dispensing automatic teller machines (ATMs), sometimes called automatic banking machines, (ABMs) or may be provided as cashless public terminal devices specifically for smart cards. Private terminal devices (PrTDs) may be used in the privacy of an individual's home, office, or other non-banking location. PuTDs and PrTDs may be part of a telephone that is equipped with a suitable card reader and electronics and which also performs voice and other telephone functions. PuTDs can be integrated into merchant point of sale (POS) devices for the use of merchants or individual customers of the merchants. PuTDs and PrTDs can be designed for load, unload, or other operations or may be limited to load operations (or to unload or other operations). Alternatively, a smart card telephone adapter may be provided without voice communication capability. Collectively, all of these devices used for smart card transactions are referred to as smart card terminal devices (TDs).

In order for financial institutions to service remote smart card customers, the institutions must provide communications ports for connection to remote terminal devices or, in some cases, the communications connection network itself. Additionally, computing systems of significant capability must be provided to support and control the transfer of value and the maintenance of the associated accounting records. The communications connections and processing resources for secure smart card transactions are significantly more complex and more processing intensive than the communications and processing required for non-smart card operations such as ATM and ABM cash withdrawal or check deposit operations. The secure value transfer between smart cards requires multiple exchanges of messages. Anonymous value transfer can further increase the complexity of the message exchange. First, for mutual authentication, exchanges of internal status must be made between the two cards. Then the exchange of value requires transfer message requests. Finally, the messages must be confirmed, typically using two phase data commit protocols. Messages may be lengthened and processing demands increased by cryptology used to authenticate each smart card to the other and guard against subversion of messages between the two.

Additionally, the internal operation of the customers' smart cards are complex and require management. Cards may have internal expiration dates, have exception-log registers that can fill, can become locked because of forgotten passwords or other problems, and be customizable. Depending on the policies of owning institutions, these conditions may be tested and may be handled in ways that depend on the situation. For example, each institution may have its own policies on posting of transactions that are failed or possibly failed transactions, may have different charge structures, and may have different reporting requirements.

Byway of comparison, in normal ATM processing, the transaction message protocols typically are simple demand-response, where an ATM sends a request to the institution and receives a reply, ending the transaction. For a simple withdrawal, the exchange may be as simple as a request to dispense a certain amount of currency on the basis that a specific ATM card has been presented and that the user has presented a specific PIN number (in normal practice, encrypted before transmission). The simple reply may be a "yes" or "no". This simple demand/response transaction protocol is in marked contrast to the multi-phase protocols demanded by smart card value transfers where a transaction may require passing ten or more messages between the institution's processing system and the smart card terminal device (TD) with its inserted customer smart card.

All of the complexity and variations possible with smart card systems complicate the interoperability of "domestic" and "foreign" systems. Nonetheless, the communications and processing systems of institutions supporting value transfers have a need to expand and extend their systems to accommodate the

"foreign" and "domestic" smart cards and their associated terminal devices.

Major difficulties arise in accommodating customers who wish to load value, unload value or avail themselves of other smart card services at "foreign" terminal devices that are not operated by the "domestic" institution that issued the customer's smart card. Many of these difficulties can be reduced if the institutions could provide these services using transactions that operate in much the same manner as used in conventional ATM transactions. With a conventional ATM transaction, these "foreign" transactions are accommodated by agreements between the "domestic" and "foreign" institutions. A message is sent on an inter-institution network to the domestic institution by the foreign institution that receives a "foreign" request for currency, and the response by the "domestic" institution to the requesting device depends by the response from the "foreign" institution. The processing between institutions is not complex and can be merely a simple extension of demand/response protocol, typically used between the ATM and the bank.

However, for e-cash and other smart card services, referral by a "domestic" institution back to the "foreign" institution is not always technically or administratively desirable. If all service request messages from a "foreign" smart card on a "domestic" terminal device are sent by the "domestic" service group owner back to the "foreign" service group owner, complete refer-back protocols to handle smart card transactions must be provided on the inter-institution networks. Such complete refer-back protocols significantly increase the required bandwidth on the inter-institution networks and cause a delay that substantially increases the time to accomplish the requested service. Such complete refer-back protocols are usually unacceptably slow and compromise private institution policies. In many cases, the network investment necessary to support complete refer-back protocols between "domestic" and "foreign" service group owners cannot be deployed in a timely manner and on financial considerations would not be commercially acceptable.

In light of the problems of the above background, there is a need for improved methods and apparatus for storage, transfer and other processing of value data in a multi-service group owner environment.

SUMMARY OF THE INVENTION

The present invention is an electronic commerce system formed of service group owners, such as banks, having ownership, respectively, of groups of e-value stores. A pooled resource server communicates with each of the groups of e-value stores and each of the service group owners so that each service group owner is not required to duplicate the facilities of the pooled resource server in order to operate an e-value electronic commerce system. The pooled resource server includes a storage unit for storing transaction information for each of said plurality of service group owners and includes a processor for controlling e-value transactions among the groups of e-value stores and the service group owners based upon said transaction information.

In an embodiment, the pooled resource processor includes a pooled resource manager for storing and managing e-value amounts and includes a pooled service controller for controlling e-value transfers between the resource manager and the e-value stores based upon transfer rules stored by the pooled resource server. The resource manager stores owner rules for each of the service group owners whereby transactions for any particular one of the service group owners are controlled by owner rules unique to that particular one of the service group owners.

In a network, e-value terminal devices are used for communicating with the e-value stores under control of the pooled resource server through one or more terminal networks. One or more owner networks connect between the service group owners and the pooled resource server for communication with the service group owners.

In one typical embodiment, a service group owner includes an authorization interface, such as an ATM interface for ATM terminals, for authorizing electronic commerce transactions.

In an embodiment, the processor unit determines the authorization of transactions for e-value stores based upon information obtained on a real time basis from the service group owners. Typically, the transaction information is under the control of the service group owners where e-value groups include smart cards and e-value transactions are used to load applications and data into the smart cards. Typically, smart cards store security information for aiding in the secure implementation of the transactions. The pooled resource server operates by analysis of data from smart cards and from internal data files in order to process smart card transactions on behalf of the service group owner managed by the pooled resource server making direct interactions between the service group owner and e-value terminal devices unnecessary for e-value transfers at the terminal devices.

The pooled resource server operates to commingle resources for different service group owners and stores records to assure an accounting audit trail for each of the service group owners. The pooled resource server provides, for clearing and audit purposes, logs and postings separable for each service group owner.

Particular embodiments include e-cash services as well as other smart card based services such as the accumulation and redemption of loyalty points, or the management of smart cards themselves including the actual loading of applications and data into smart cards. The service group owners may provide to the pooled resource server a float of resources that are used on behalf of the service group owners by the pooled resource server.

The pooled resource server when it commingles resources for different service group owners, maintains accounting entries to assure that funds are not disbursed in excess of the funds provided by the service group owners, or by agreement available for use in behalf of the institution.

By dealing with network attached terminal devices, the pooled resource server bypasses the need for expanded data processing at each of the service group owners for the processing of each e-value transfer. The pooled resource server maintains smart card policy in rules for each of the service group owners, in confidence from the other institutions, so that the performance of smart card management functions for each service group owner are maintained confidential from the other service group owners

The forgoing and other objects, features and advantages and embodiments of the invention will be apparent from the following detailed description in conjunction with the drawings

BRIEF DESCRIPTION OF THE DRAWINGS

FIG 1 depicts the connection topology of pooled resource server for an e-value system integrated with a conventional e-cash system

FIG 2 depicts an inter-bank e-value server with pooled resources FIG 3 depicts networked bank e-cash systems

FIG 4 depicts the system operation of the FIG 2 system FIG 5 depicts the system operation of the FIG 3 system

DETAILED DESCRIPTION

Commerce System— FIG 1 In FIG 1, an e-value system 4 existing over the A stages 1 A, 2A, 3A/B and

4A is integrated with a conventional e-cash system 5 existing over the B stages IB, 3A/B and 4B where the 3A/B stage is shared between the systems 4 and 5 Message connections are shown in FIG 1 between the elements of the e-value system 4 and of the e-cash system 5 In FIG 1 , the e-value system 4 includes a plurality of smart card groups 10 including groups 10-1, , 10-G The smart card groups 10 connect to the terminal device groups 20 including groups 20- 1 , , 20-G The terminal device groups 20- 1, , 20-G connect to a pooled resource server 30, through network 70 The pooled resource server 30 connects to the originator system 60 through network 92 and to the service group owners 40 including the owners 40- 1 , , 40-G through network 80

In FIG 1 in the cash system 5, the service group owners 40-1, , 48-G connect, respectively, to the ATM/ ABM groups 50 including the groups 50-1, , 50-G The service group owners 40-1, , 40-G connect to the central system 65

In FIG 1 , the smart card groups 10-1, , 10-G, the terminal device groups

20, the pooled resource server 30 and the originator system 60 are all part the e- value system 4 In FIG 1, the conventional cash system 5 includes ATM groups

50, the service group owners 40 and the central system 65 The ATM Groups 50 connect to Service Group owners 40 through network 71, and to the Central

System through network 91 The service group owners 40 are included both in the e-value system 4 and in the cash system 5 Individual service group owners 40 may participate in the e-value system 4, or the cash system 5, or both

In FIG 1, the service group owners are businesses such as banks, card companies and others that have the ability to control transactions involving e-value stores, ATM cards and other similar electronic commerce devices The control of such transactions usually includes the authority to issue ATM or e-cash cards, assign and change electronic keys or secuπty codes, and otherwise manage access to and operation of electronic commerce devices The e-value of system 4 receives and dispenses e-value to and from smart cards owners The service group owners 40-1, , 40-G have an ownership relation to the smart card groups 10-1, , 10-G, respectively the smart cards in smart card group 10-1 are owned by service group owner 10-1, the smart cards in the smart card group 10-G are owned by service group owner 10-G Owners 40-1, , 40-G have an administrative relationship to the terminal device groups 20- 1 , ,

20-G, respectively, in the sense that terminals within a terminal device group 20 have an administrative and control relationship to the corresponding service group owner 40 the terminal device group 20-1 is under administrative control of service group owner 20-1, the terminal device group 20-G is under administrative control of the service group owner 20-G

The cash system 5 functions in a conventional manner for dispensing of currency In FIG 1, the owners 40-1, , 40-G have an administrative relation to the ATM Groups 50-1, , 50-G, respectively, in the sense that ATMs in an ATM Group have an administrative and control relationship to the corresponding owner, the ATM group 50- 1 includes ATMs that have an administration relationship to the service group owner 40-1, the ATM group 50-G includes ATMs that have an administrative relationship to the service group owner 40-G Each of the ATMs from the ATM/ ABM groups 50 dispenses and receives currency in a conventional manner

Networks 70, 71, 80, 91 and 92 each may be one or more possibly distinct logical networks, or may be a direct physical or dedicated logical connection e-ValueSvstem- FIG 2

In FIG 2, further details of the e-value system 4 of FIG 1 are shown and include the stages 1A, 2 A, 3 A and 4A

In the FIG 2 the smart card group 10- 1 includes the smart cards 11-1, , 11-

S, Similarly, the smart card group 10-G includes the smart cards 12-1, , 12-S_G The smart cards 11 in the smart card group 10- 1 connect to terminal devices 20 that include devices 21-1, , 21-Dj Similarly the smart cards 12 in the smart card group 10-G connect to the terminal devices 20-G including terminal devices 22-1,

, 22-D₂ The connection of any particular smart card 11 or 12 to a particular terminal device 21 or 22 may be long lasting, or may be made only for the duration of one or more related transactions

In FIG 2, the terminal devices 20- 1 , , 20-G all connect through a network (NET) 70 to the pooled resource server 30 NET 70 may be implemented as a direct physical or dedicated logical connection, or it may be one or more possibly physically distinct logical networks. The pooled resource server 30 includes a resource manager 31, a processor 34 that is formed of a service control unit 32 and a data store 33. The resource manager 31 functions to control e-value resources, manage the transfer of e-value, and provide physical and logical security for value data.

In operation of the FIG. 2 system, examples of e-cash flows are shown by the triangle (TRI_) designated arrows. The flow of the e-cash examples is tracked by accounting records shown by pentagon (PEN_) designated arrows. The data exchanges between reconciliation, clearing and settlement processes is shown by hexagon (HEX_) designated arrows.

E-value transfers to and from the resource manager 31 and the originator 60 are depicted by the TRI- 1. Transfers to and from the resource manager 31 and the smart cards 10 are depicted by TRI_2. The transfers to and from depicted by TRI_1 and TRI_2 are effected by electronic messages transferred through the physical connections of the e-value system. In FIG. 2, only transfers to a typical one of the smart cards 11-1 is shown, but similar transfers may occur between the resource manager 31 and the other smart cards of FIG. 2.

The resource manager 31 operates to control e-value transfers to or from the smart cards connected through each of the terminal devices 21 including the terminal devices 20-1, ..., 20-G. The various terminal devices 21-1, ..., 21-D1 and 22-1, ..., 22-D2 may be owned or associated with different service group owners, but nonetheless, the resources to service these terminals are pooled and handled in common by the resource manager 31. The resource manager 31 may manage individual value stores contained in the pooled resource server 30 by moving value from one value store to another for effective distribution of value between the individual value stores, for the efficient acquisition or selling of value with the originator system 60, for retiring of failed or prospectively failing value stores, or for other measures providing for efficient and economic operation of the pooled resource server 30. The service control unit 32 operates to control and execute the processes and manage logical connections for carrying out the various transfers in connection with the system of FIG. 2. Together, the service control unit 32 and pooled resource server 30 function as a processor 34 for controlling transactions with the groups of e-value stores 10 and with the service group owners 40 based upon transaction information.

Because the resources are pooled by the resource manager 31, different accounting for the various different service group owners 40 are reported and logged in the data store 33. This data is segregated for reporting purposes so that inter-institution confidentiality may be maintained by separating the data associated with one service group owner from the data associated with another service group owner. In FIG. 2, the service control unit 32 connects through networks (NET)80-

1, ..., 80-G to the service group owners 40-1, ..., 40-G, and through the network (NET) 92 to the Originator system 60, which includes an e-value originator 61 and its corresponding data store 62. Networks 80-1, ..., 80-G, and 92 may be implemented as direct physical or dedicated logical connections, or as one or more possibly physically distinct logical networks. The service group owners 40-1, ...,

40-G correspond to the smart card groups 10-1, ..., 10-G. The service group owners 40-1, ..., 40-G in turn connect to data stores 41-1, ..., 41-G, respectively.

In FIG. 2, an e-value transfer between the originator system 60 and the pooled resource server 30 occurs with the TRI 1 transfer. That TRI_1 transfer is accompanied by data records transfer PEN_1A for posting and later audit and reconciliation to the data store 62 in stage 4A. Also, the transfer TRI_1 is accompanied by a posting, audit, and reconcilation records PEN_1B from the service control unit 32 to the data store 33 in stage 2 A Accounting processes in the pooled resource server 30 and the origination system 60 procedures adjust the currency and e-cash positions using the records PEN_2A and PEN_2B posted in data stores 33 and 62, respectively Reconcilliation and audit processes in the pooled resource server 30 and the origination system 60 for compensating value due for e-cash flow between the pooled resource server 30 and the origination system 60, using the records contained data store 33 in the stage 2 A and the data store 62 in the stage 4 A, as shown by HEX 1

In FIG 2, a typical e-value transfer from the pooled resource server 30 to a smart card 11-1 occurs with the transfer TRI_2 In the typical case, this transfer is authorized by a demand/response exchange originated by the pooled resource server 30 that owns the smart card group 10-1 that contains the smart card 11-1, in this typical case, to the service group owner 40-G This exchange is very similar to the exchange that occurs between a service group owner 40 and an ATM The transfer TRI 2 is accompanied by posting, audit, and reconciliation data record transfer PEN 2A in the pooled resource server 30 from the service control unit 32 to the data store 33 The transfer TRI 2 is also accompanied by posting, audit, and reconcilation data records transfer PEN_2B from the service group owner 41 -G to the data store 42-G Accounting processes in the pooled resource server 30 and the service group owner 42-G adjust the currency and e-cash positions using the records posted in PEN_2A and PEN_1A to the data stores 33 and 42-G, respectively Reconciliation and audit processes in the pooled resource server 30 and the service group owner 40-G on compensating value due for e-cash flow between the pooled resource server 30 and the service group owner 40, use the records contained in the data store 33 in stage 2 A and the data store 42-G in stage

3 A, as shown by HEX_2

Cash System — FIG 3 In FIG. 3, a typical ATM cash system 5 of FIG. 1, is shown and includes the stages IB, 3B,/3B_y and 4B. In FIG. 3, the ATM groups 50, including the groups 50-1, ..., 50-G connect through networks (NET) 71-1, ..., 71-G to corresponding service group owners 40 including the owners 40-1, ..., 40-G. The service group owner 40- 1 is typical and includes the bank operations 41-1 and the bank data store

42-1.

In FIG. 3, the service group owners 40-1, ..., 40-G connect through a network (NET) 91 to the central system 65 which includes the central bank operations 65-1 and the central bank store 65-2. In operation of the FIG. 3 system, currency flows examples are shown by the triangle (TRI_) designated arrows.

Currency movement is tracked by accounting records shown by pentagon (PEN_) designated arrows. The data exchanges between reconciliation, clearing and settlement processes is shown by hexagon (HEX_J designated arrows. Currency via TRI_1 flows from the central system 65 to the bank operations in the service group owner 40- 1 , via TRI 2 from the bank operations 40- 1 to the ATM/ ABM 51 -

1 and via TRI_3 is dispensed as currency to a customer.

In FIG. 3, the typical currency flow from the central system 65 to a service group owner with the TRI_1 flow, for example, to service group owner 40-1 from the central system 65. The TRI_1 cash flow is accompanied by a data record PEN_1A from the bank operations 41-1 to the data store 42-1. Similarly, the transfer is accompanied by a record transfer PEN_1B from the central bank operations 65-1 to the data store 65-2 in the stage 4B. Reconciliation and audit processes for compensating value in the service group owner 40-1 and the central system 65 flow between the two using records contained in data stores 42- 1 in stage 3Bx and 65-2 in stage 4B as shown by HEX 1. The currency flow transfer TRI 1 permits a typical cash flow transfer TRI_2 from the bank operations 41-1 to an ATM 50, such as ATM 51-1. The currency transfer TRI_2 gives rise to a data record PEN 2_B from the bank operation 41-1 to the data store 42-1. Currency counting operations at the ATM 51-1 and at bank operations 41-1 give rise to accounting records in the data store 42-1 that are indicated by PEN_2A and PEN 2C, respectively. Posting and reconciliation processes HEX_2 in the service group owner 40-1 use date stored in the data store 42-1 to reconcile the physical cash balances and the corresponding account balances adjustments that result from the currency transfers between the stage 3B_X and stage IB. A dispensement of cash to a customer is designated by the currency flow TRI 3. There are two cases for the currency flow TRI_3. In the first case of currency flow TRI_3, if the ATM transaction is on an account held in the service group owner 40-1, then the currency flow TRI_3 is accompanied by a data record transfer from the bank operations 41-1 to the data store 42- 1 and the record is used by service group owner 40- 1 to adjust the account balances of the account holder and of relevant internal bank accounts. In the second case of currency flow TRI 3, if the requested ATM transaction is on an account held by another service group owner 41-G, then typically the dispense currency operation requires the service group owner 41-1 to send an authorization request to service group owner 41-G and to receive an authorization response in response from the service group owner 41-G. The request and authorization response are sent over network 91. In this second case, the currency flow TRI_3 is accompanied by a data record transfer from the bank operations 41-1 to the data store 42-1 in the form of the record PEN_3A, and the bank operations 41-G transfers customer account specific records and the record PEN_3B to the data store 42-G with the record PEN_3B. The customer specific records are used by service group owner 40-G to adjust the account balances of the account holder and of relevant internal bank accounts. Interbank accounts are reconciled by reconciliation and audit processes for compensating value in the service group owners 40-1 and 40-G, using data stored in data stores 42-1 and 42- G respectively as shown by HEX_3 e- Value Sequencing — FIG 4

In FIG 4, details of a typical operation of the e-value system 4 of FIG 1 and FIG 2 are shown The TRI_, PENT_, and HEX_ symbols of FIG 4 directly correspond to the TRI_, PENT_, and HEX_ symbols of FIG 2 In FIG 4, the

VALUE DISTRIBUTION & ACCOUNTING segment operates over stages 2A and 4A to support original acquisition and redemption (ACQUIRE/REDEEM) of e-cash or similar resources, operates over stage 2 A and 3 A to support management of smart cards (MANAGE_SC_ GROUPS) under the control of service group owners, operates in stage 2A to manage the allocation of its own resources

(MANAGE VALUE), and provides reconciliation data (RECONCILE) with the

INTERBANK RECONCILIATION segment and operates with the stage 1 A and

2A CUSTOMER TRANSACTION segment to pay and receive e-cash or similar value/dispense to customer smart cards (DISPENSE)

For original acquisition and redemption (ACQUIRE/REDEEM) of e-cash by the pooled resource server 30 (TRI 1), messages are exchanged between the ACQUIRE/REDEEM/DISPENSE/

MANAGE_VALUE/MANAGE_SC_GROUPS process of the stage 2A pooled resource server 30 and the ORIGIN ATE/DISTROY/RECONCILE_VALUE process of the stage 4A originator 60 Posting, reconciliation, and audit records TRI l are posted, PEN 1B and PEN 1 A, associated with by the pooled resource server 30 (PEN_1B) and the originator 60 (PEN_1 A), respectively Accounts are reconciled between the pooled resource server 30 and the originator 60 (HEX 1 A) For managing smart card groups (MANAGE SC GROUPS), the

MANAGE SC GROUPS process of stage 3 A exchanges messages with the ACQUIRE/REDEEM/DI S PEN SE/REC ONC ILE/ MANAGE_VALUE/MANAGE_SC_GROUPS process of stage 2A. The cooperation of these processes allow a SERVICE GROUP OWNER 40 to create, modify, or delete rules contained in data store 33 used by the POOLED RESOURCE SERVER 30 in the processing of smart cards contained in smart card groups 10 owned by the SERVICE GROUP OWNER 40. These rules may be modified in real time, at scheduled or ad-hoc intervals of time, or may be static for long periods of time, however these rules must be consistent with the regulations of government and other regulatory authorities. For the purpose of managing value (MANAGE VALUE) within the pooled resource server 30, the ACQLTRE- /DISPENSE/RECONCILE/MANAGE_VALUE/MANAGE_SC_GROUPS process of stage 2 A moves e-value between logical and physical resources. The movement may distribute e-value to resources so as to minimize the total amount of value in the pooled resource server 30 while still giving adequate service levels, and to gracefully retire and replace value stores that are reaching life limits. The MANAGE VALUE process may also enforce business or contractual rules between the service group owners 40 and the operator of the pooled resource server 30 that regulate cash float, transaction rate limits, or other constraints.

The EOD RECKONING process of stage 2 provides reconciliation (PEN 2C) records based on enumeration of resources held by the resource manager at the end of an accounting period.

The ACQUIRE/REDEEM/DISPENSE/MANAGE_VALUE/MANAGE SC GROUPS process of stage 2A supports the CUSTOMER TRANSACTION segment deposit or withdrawal operations by dispensing or accepting e-value (TRI_2) or other value from the resource manager 31. In the CUSTOMER TRANSACTION segment of FIG. 4, operations at terminal devices 20 of FIG. 2 occur in the stage 1A. To initiate a transaction, a CUSTOMER_CARD REQUEST process initiates a VALID ATE CARD process from the terminal device 21 to the VALID ATE CARD process in the server control unit 32 . The VALID ATE CARD process in the pooled resource server

30 may communicate with the VALID ATE CARD process in the terminal device

20 to cryptographically challenge the smart card 10 and to extract card specific information from the smart card 10. The VALID ATE CARD process in the POOLED RESOURCE SERVER 30 reads data store 33 to make an association with a specific service group owner 40 that owns the specific customer card. The association is based on information extracted from the card by the terminal device

21 and based on rules provided by service group owners 40. Further processing by the pooled resource server depends on the processing and analysis of card data, the specific customer request, and rules supplied by the service group owner 40 that owns the card. These rules may specify immediate rejection of the request, immediate acceptance of the request, or, as shown in FIG. 4, involving the SEND AUTH REQUEST process in stage 2A which involves the READ CUST DB process of stage 3 A. In this case, READ CUST DB process flows to the SEND AUTH RESULT which determines, by access to data files internal to service group owner 40, if the customer card request is authorized. The customer request may be for an e-cash deposit ("card unload"), for withdrawal ("card load"), for card maintenance activities such as clearing of internal exception ("card clear") conditions or setting of internal card data, or for the maintenance of applications ("application load", "application unload", or "application maintenance") that may be resident or may be requested to be transferred to the card. The SEND AUTH RESULT process sends a yes/no authorization result to the REQ_ACCEPTED? process of the stage 2 A POOLED RESOURCE SERVER 30. If the authorization is not accepted (a "NO" result), then the REQ ACCEPTED? process involves the REJECT REQUEST process in the terminal device 20. If the authorization is accepted (a "YES" result), then the DO OPERATIONS process is initiated in the pooled resource server 30 which operates in conjunction with stage 1 A process DO OPERATIONS in the terminal device 20. Depending on the request, completion of the requested operation (TRI 2) may require one or multiple messages to be transmitted between stage 1 A and stage 2A. As a result of the value transfer TRI 2, the DO_OPERATIONS task of the POOLED RESOURCE SERVER 30 creates posting records containing transaction details (PEN 2A), and the SEND AUTH RESULT process creates posting records containing transaction details (PEN_2B).

The INTERBANK RECONCILIATION segment of FIG. 4 operates over stages 2A and 3 A to reconcile the internal accounts of the POOLED RESOURCE SERVER 30 and to support accounting of compensation value between the POOLED RESOURCE SERVER 30 and the SERVER GROUP OWNER 40.

Reconciliation of the internal accounts of the POOLED RESOURCE SERVER 30 is accomplished by the stage 2ARECONCILE_ACCOUNTS process based on data stored in data store 33 which includes previous account balances, itemization of current period transactions (PEN_2A), and actual current resources as obtained from the EOD_RECKONINGprocess(PEN_2C). Reconciliation for compensating value (HEX2) occurs between the RECONCILE_ ACCOUNTS process of the stage 2A and the RECONCILE INTERBANK ACCOUNTS of stage 3 A. The RECONCILE ACCOUNTS process provides smart card specific transaction detail to each of the SERVICE GROUP OWNERS 40 for their transactions only, maintaining confidentiality on smart card transactions performed on behalf of other

S E R V I C E G R O U P O W N E R S 4 0 . T h e

RECONCELE NTERBANK ACCOUNTS process receives, for reconciliation with the information from the RECONCILE_ACCOUNTS process (PEN_2 A), the transaction detail from its own accounting process (PEN_2B) for transactions authorized by the SERVICE GROUP OWNER 40 during the CUSTOMER TRANSACTION SEGMENT The transaction detail information is also used by the SERVICE GROUP OWNER 40 for internal reconciliation of its own customer accounts Cash System Sequencing — FIG 5

In FIG 5, transactions in accordance with the cash system 5 of FIG 1 and FIG 3 are shown including the stages IB, 3B , 3B_y and 4B The TRI_, PENT_, and HEX_ symbols of FIG 5 directly correspond to the TRI_, PEN_, and HEX_ symbols of FIG 3

In FIG 5, the currency distribution segment has transactions occurring between the ATM stage IB, the ACQUIRING BANK stage 3B_X and the CENTRAL BANK stage 4B The BUY/SELL/DISTRIBUTE CURRENCY process in the stage 3B_X acquiring bank communicates with the

BUY/SELL CURRENCY process of the stage 4B CENTRAL AUTHORITY to arrange distribution of currency as working funds for the ACQUIRING BANK (TRI_1) As a result of this distribution, the BUY/SELL_CURRENCY of stage 4B process and the BUY/SELL/DISTRIBUTE_ CURRENCY process generate transaction records posted to data stores 65-2 and 42- 1 , respectively (PEN_1B and

PEN 2B) These transactions are reconciled (HEX_ 1 ) by communications between the SETTLE ACCOUNTS processes of the stage 3B ACQUIRINGBANK and the stage 4B CENTRAL AUTHORITY

The ACQUIRΓNGB ANK periodically services ATMs in its ATM group 50- 1 by moving working funds to the ATM (TRI 2) This movement causes the creation of transaction records (PEN_2B) for later intra-bank reconciliation That intra-bank reconciliation and audit requires a count of the actual currency in the ATM (PEN_2A) which is done by the COUNT_CURRENCY process.

In FIG. 5, customer transactions segment occur across the stages IB, 3B_X and 3B_y. Processing is initiated in response to a customer ATM card request to the CUSTOMER REQUEST process in stage IB at an ATM/ABM 50. The

CUSTOMER REQUEST process sends a message to the ACQUIRINGBANK in stage 3B where the ON_SELF? test process determines whether or not the customer request is for one of the bank's own customers (domestic) or not (foreign). If the result of the test is YES, flow is to the READ_ACQUIRE_BANK_DB process. The READ_ACQUIRING_B ANK DB process, based on data contained in data store 42-1, determines a yes/no result which flow to the DISPENSE_CASH? process. If the result of the ON SELF? test is NO, then the SEND_AUTH_REQ process sends an authorization request to the ISSUING BANK in stage 3B_y. In stage 3B_y, the ISSUING BANK initiates the READ ISSUING BANK DB process to determine whether or not the card request is authorized or not. If the request is authorized, the SEND AUTH RESULT process posts transaction records to the data store 42-G which are used to balance interbank accounts. These records are also used to adjust the interval accounts of the ISSUING BANK to reflect adjusted balances to an account of the customer requesting the ATM transaction. The

READ_ISSUING_BANK_DB request flows to the SEND AUTH RESULT process which, based on information obtained by reading data store 42-G, sends a YES/NO response message to the acquiring bank in the stage 3B_X. The response message flows to the DISPENSE CASH? process. If the result is YES, then the DISPENSE_CURRENCY process is initiated at the ATM. If the input to the

DISPENSE C ASH? process is NO, the DISPENSE C ASH? process sends a reject message to the stage IB ATM which initiates a REJECT_REQUEST process that ends the customer ATM card request. If the input to the DISPENSE CASH? process is YES, the DISPENSE CASH? process sends a proceed message to the stage IB ATM which initiates a DISPENSE CURRENCY process which causes previous loaded currency in the ATM to be delivered to the requestor (TRI_3). As a result of a proceed message, the DISPENSE CASH? process posts transaction records to data store 42-1. These records are used to balance intra-bank accounts (PEN_2C). Additionally, if the YES input to the DISPENSE_CASH? process originated in the SEND_AUTH_RESULT of stage 3B_y, then the records are used for settling inter-bank accounts (PEN_3A). In FIG. 5, the customer transaction clearing segment includes the

SETTLE NTRABANK ACCOUNTS, the SETTLE NTERBANK ACCOUNTS in stage 3B_X and the SETTLEJNTERBANK ACCOUNTS in the stage 3B_y.

Intrabank accounts are settled (HEX_2) using prior account balances and records generated by the DISPENSE_C ASH? process (PEN_2C) that in aggregate reflect the ATM currency distributed, records generated by the

BUY/SELL/DISTRIBUTE CURRENCY process (PEN 2B) that reflect the currency bought or sold from the CENTRAL AUTHORITY, and records generated by the counting of currency in the ATMs (PEN 2A).

Interbank accounts are settled (HEX_3) between the SETTLE_INTERB ANK_ACCOUNTS process of stages 3B_X and 3B_y, depending on the records produced by the DISPENSE CASH process (PEN 3A) which reflect the amount of currency disbursed by the ACQUIRING BANK on behalf of the ISSUING BANK, and by the SEND AUTH RESULT process (PEN 3B) which reflects the amount authorized to be disbursed by the ISSUING BANK. Frequently, this interbank clearing process is accomplished by a third party on behalf of the two banks. While the invention has been particularly shown and described with reference to preferred embodiments thereof it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the invention.

Claims

1.(Original). An electronic commerce system, for use with a plurality of service group owners having ownership, respectively, of a plurality of groups of e- value stores where the e-value stores and the service group owners have network connections, comprising: a pooled resource server, having network connections for communication with the e-value stores and the service group owners, including, storage means for storing transaction information for each of said plurality of service group owners, processor means for controlling transactions with the groups of e- value stores and with the service group owners based upon said transaction information.

2. (Original). The system of Claim 1 wherein the said transaction information includes rules for controlling the transactions and includes records providing an audit trail for said transactions.

3. (Original). The system of Claim 1 wherein the e-value stores include smart cards storing card data and wherein said processor means processes said card data and said transaction information for transactions that include e-value transfers without need for interactions between the service group owners and the e-value stores during said e-value transfers.

4. (Original). The system of Claim 3 wherein said transaction information is under the control of the service group owners.

5. (Original). The system of Claim 1 wherein said e-value transactions include at least one of e-cash services and loyalty points services.

6. (Original). The system of Claim 1 wherein said e-value groups include smart cards and said e-value transactions include loading and/or unloading of applications and data into and from said smart cards.

7. (Original). The system of Claim 1 further including an originator system and wherein said pooled resource server includes smart cards loaded and/or unloaded by transactions with said originates system.

8. (Original). The system of Claim 7 wherein said smart cards store security information for aiding in the secure implementation of said transactions.

9. (Original). The system of Claim 1 wherein said service group owners are banks.

10. (Original). The system of Claim 1 wherein said pooled resource server commingles resources for different service group owners and stores accounting records to assure accounting among the service group owners while maintaining confidentiality of transaction information for each service group owner.

11. (Original). The system of Claim 1 wherein said processor means determines the authorization of transactions for e-value stores.

12. (Original). The system of Claim 11 wherein said processor means determines the authorization of transactions for e-value stores based upon information stored in said pooled resource server.

13. (Original). The system of Claim 11 wherein said processor means determines the authorization of transactions for e-value stores by querying a service group owner to obtain authorization.

14. (Original). The system of Claim 11 wherein said processor means determines the authorization of transactions for e-value stores based upon authorization information stored in said storage means where the authorization information is updated by said service group owners.

15. (Original). The system of Claim 11 wherein said processor means determines the authorization of transactions for e-value stores based upon information periodically updated from said service group owners on a non-real time basis.

16. (Original). The system of Claim 1 wherein said transaction information includes e-value transfer amounts, transfer records recording e-value transfer amounts and reconciliation records for reconciling e-value transfer amounts.

17. (Original). The system of Claim 16 wherein said reconciliation records reconciling e-value transfer amounts between the pooled resource server and the service group owners.

18. (Original). The system of Claim 16 wherein said reconciliation records reconciling management information about the groups of e-value stores in the pooled resource server and management information about the groups of e-value stores in the service group owners.

19. (Original) . The system of Claim 1 wherein further including an originator system connected to transfer e-value amounts between said pooled resource server and said originator system and wherein said transaction information is updated as a function of said e-value transfer amounts between said originator system and said pooled resource server.

20.(Original). The system of Claim 19 wherein said transaction information includes e-value transfer amounts, transfer records recording e-value transfer amounts and reconciliation records for reconciling e-value transfer amounts between said originator system and said pooled resource server.

21. (Original). The system of Claim 19 wherein said e-value transfer amounts are transferred from said originator system to said pooled resource server when needed to increase a balance of e-value in said pooled resource server and are transferred from pooled resource server to said originator system when needed to decrease the balance of e-value in said pooled resource server.

22. (Original). The system of Claim 1 wherein said processor means includes a resource manager for securely managing e-value amounts and service control means for controlling transfers among the service group owners and the e-value groups.

23 (Original) The system of Claim 22 wherein said service control means controls the downloading of information from the service group owners to the pooled resource server whereby the rules unique to different ones of the service group owners are loaded into the pooled resource server

24 (Original) The system of Claim 23 wherein said programs unique to a particular one of the service group owners loaded into the pooled resource server function to render virtual services to the e-value groups associated with the particular one of the service group owners without need for network connections between the service group owners and the e-value stores other than network connections administered by the pooled resource server

25 (Original) An electronic commerce system, for use with a plurality of service group owners having ownership, respectively, of a plurality of groups of e- value stores where the e-value stores and the service group owners have network connections, comprising a plurality of e-value terminal devices for communicating with said e-value stores, a pooled resource server, having network connections for communication with the e-value stores and the service group owners, including, storage means for storing transaction information for each of said plurality of service group owners where said transaction information includes rules for controlling transactions and includes records providing an audit trail for said transactions, processor means for controlling e-value transactions among the groups of e-value stores and the service group owners based upon said transaction information, terminal network means connected between said pooled resource server and said plurality of e-value terminal devices for transfers between said pooled resource server and said e-value stores through said e-value terminal devices under control of said pooled resource server, service group owners network means connected between said service group owners for communicating with said pooled resource server under control of said rules.

26. (Original). The system of Claim 25 wherein said resource manager stores owner rules for each of said service group owners whereby transactions for a particular one of the service group owners are controlled by owner rules unique to said particular one of the service group owners.

27. (Original). The system of Claim 25 wherein said processor means determines the authorization of transactions for e-value stores based upon information obtained on a real time basis from said service group owners.

28. (Original). The system of Claim 27 wherein the e-value stores include smart cards storing card data and wherein said processor means processes said card data and said transaction information for transactions that include e-value transfers.

29. (Original). The system of Claim 28 wherein said transaction information is under the control of the service group owners.

30. (Original). The system of Claim 25 wherein said e-value transactions include e-cash services.

31. (Original). The system of Claim 25 further including an originator system and wherein said pooled resource server includes smart cards loaded and/or unloaded by transactions with said originates system.

32. (Original). The system of Claim 25 wherein said pooled resource server includes smart cards and said e-value transactions include loading of applications and data into said smart cards.

33. (Original). The system of Claim 32 wherein said smart cards store security information for aiding in the secure implementation of said transactions.

34. (Original). The system of Claim 25 wherein said service group owners are banks.

35. (Original). The system of Claim 25 wherein said pooled resource server commingles resources for different service group owners and stores accounting records to assure an accounting audit trail for each of the service group owners while maintaining confidentiality of the transaction information for each service group owner.

36. (Original). In an electronic commerce system having a plurality of service group owners, where at least one particular service group owner includes an authorization interface for authorizing electronic commerce transactions, the improvement comprising, a group of e-value stores for said particular service group owner, a plurality of e-value terminal devices for communicating with said e-value stores, a pooled resource server, for communication with said e-value stores through said terminal devices and for communicating with said particular service group owner over said authorization interface, including, storage means for storing transaction information for at least said particular service group owner where said transaction information includes rules for controlling e-value transactions and includes records for said e-value transactions, processor means for controlling e-value transactions for the group of e-value stores and the particular service group owner based upon said transaction information, terminal network means connected between said pooled resource server and said plurality of e-value terminal devices for transfers between said pooled resource server and said e-value stores through said e-value terminal devices under control of said pooled resource server, service group owner network means connected between said particular service group owner for communicating with said pooled resource server under control of said rules.

37. (Original). In an electronic commerce system having a plurality of service group owners, where at least one particular service group owner includes an authorization interface for authorizing electronic commerce transactions, the improvement comprising, a group of e-value stores for said particular service group owner, a pooled resource server, for communication with said e-value stores and for communicating with said particular service group owner over said authorization interface, including, storage means for storing transaction information for at least said particular service group owner where said transaction information includes rules for controlling e-value transactions and includes records for said e-value transactions, processor means for controlling e-value transactions for the group of e-value stores and the particular service group owner based upon said transaction information.

38. (Original) . The system of Claim 37 wherein said authorization interface is for an ATM network.

39. (Original). The system of Claim 37 wherein said resource manager stores owner rules for each of said service group owners whereby transactions for a particular one of the service group owners are controlled by owner rules unique to said particular one of the service group owners.

40. (Original). The system of Claim 37 wherein said processor means determines the authorization of transactions for e-value stores based upon information obtained on a real time basis from said service group owners.

41. (Original). The system of Claim 40 wherein the e-value stores include smart cards storing card data and wherein said processor means processes said card data and said transaction information for transactions that include e-value transfers.

42. (Original). The system of Claim 41 wherein said transaction information is under the control of the service group owners.

43. (Original). The system of Claim 37 wherein said e-value transactions include e-cash services.

44. (Original). The system of Claim 37 wherein said e-value groups include smart cards and said e-value transactions include loading of applications and data into said smart cards.

45. (Original). The system of Claim 37 wherein said pooled resource server includes smart cards and said e-value transactions include loading of applications and data into said smart cards.

46. (Original). The system of Claim 45 wherein said smart cards store security information for aiding in the secure implementation of said transactions.

47. (Original). The system of Claim 37 wherein said service group owners are banks.

48. (Original). The system of Claim 37 wherein said pooled resource server commingles resources for different service group owners and stores accounting records to assure an accounting audit trail for each of the service group owners while maintaining confidentiality of the transaction information for each service group owner.

49. (Original). An electronic commerce system having a plurality of service group owners, where at least one particular service group owner includes an authorization interface for authorizing electronic commerce transactions, comprising, a group of e-value stores for said particular service group owner, a pooled resource server, for communication with said e-value stores and for communicating with said particular service group owner over said authorization interface, including, storage means for storing transaction information for at least said particular service group owner where said transaction information includes rules for controlling e-value transactions and includes records for said e-value transactions, processor means for controlling e-value transactions for the group of e-value stores and the particular service group owner based upon said transaction information; one or more groups of ATM terminals connected to said service group owners and operating over said authorization interface.