Electronic-monetary system
Abstract
An improved monetary system using electronic media to exchange economic value securely and reliably. The invention provides a complete monetary system having electronic money that is interchangeable with conventional paper money comprising (1) issuing banks or financial institutions that are coupled to a money generator device for generating and issuing to subscribing customers electronic currency backed by demand deposits electronic credit authorizations; (2) correspondent banks that accept and distribute the electronic money; (3) a plurality of transaction devices that are used by subscribers for storing electronic money, for performing money transactions with the on-line systems of the participating banks or for exchanging electronic money with other like transaction devices; (4) automated teller devices, associated with the issuing and correspondent banks, for process handling and interfacing the transaction devices to the issuing and correspondent banks, and for interfacing between the issuing and correspondent banks themselves; and (5) a clearing bank for balancing the electronic money accounts of the different issuing banks (6).
Term
Term ended
Projected expiry passed 13 November 2012, 13.9 years ago.
- Priority
- Filed
- Published
- Projected expiry
- Today
26 claims: 7 independent, 19 dependent
- 1A method for a subscriber to use a transaction module (4) in order to perform a withdrawal from said subscriber's bank account at an issuing bank (1) having a teller module (5), a money generator module (6), and a computer controlled accounting system, said method characterized by the steps of:(a) said subscriber selecting, by way of said transaction module (4), said bank account from which to make said withdrawal, and a withdrawal amount;(b) said transaction module (4) establishing a first cryptographically secure session with said teller module (5);(c) said transaction module (4) sending a withdrawal request to said teller module (5), via said first cryptographically secure session, wherein said withdrawal request includes said withdrawal amount, and bank account information which corresponds to said bank account;(d) checking said bank account information to verify its validity;(e) checking said bank account for sufficient funds;(f) said teller module (5) establishing a second cryptographically secure session with said money generator module (6);(g) said teller module (5) sending a create money request to said money generator module (6), via said second cryptographically secure session, wherein said create money request includes a requested note value;(h) crediting a money issued account in said accounting system by said requested note value;(i) debiting said bank account in said accounting system by said withdrawal amount;(j) said money generator module (6) generating a first electronic representation of money (11) in said requested note value;(k) transferring said first electronic representation of money (11) to said teller module (5), via said second cryptographically secure session;and (l) transferring said first electronic representation of money (11) from said teller module (5) to said transaction module (4), via said first cryptographically secure session.
- 7A method for a subscriber to use a transaction module (4) to withdraw an electronic representation of money (11) from a correspondent bank (2), said method characterized by the steps of:(a) said subscriber selecting, by way of said transaction module (4), a bank account from which to make a withdrawal, and a withdrawal amount;(b) establishing a first cryptographically secure session between said transaction module (4) and a first teller module associated with said correspondent bank (2);(c) said transaction module sending a first withdrawal request to said first teller module, via said first cryptographically secure session, wherein said withdrawal request includes said withdrawal amount and bank account information corresponding to said bank account;(d) checking said bank account information to verify its validity;(e) checking said bank account for sufficient funds;(f) establishing a second cryptographically secure session between said first teller module and a second teller module associated with said issuing bank (1);(g) debiting said subscriber's bank account by said withdrawal amount in a first computer controlled accounting system associated with said correspondent bank;(h) crediting a deposited at issuing bank account in said first accounting system by said withdrawal amount;(i) said first teller module sending a second withdrawal request to said second teller module, via said second cryptographically secure session, wherein said second withdrawal request includes said withdrawal amount;(j) establishing a third cryptographically secure session between said second teller module and a money generator module (6);(k) said second teller module sending a create money request to said money generator module (6), via said third cryptographically secure session, wherein said create money request includes said withdrawal amount;(l) said money generator module (6) generating a new electronic representation of money (11) of said withdrawal amount;(m) transferring said new electronic representation of money to said second teller module, via said third cryptographically secure session;(n) crediting a money issued account in a second computer controlled accounting system associated with said issuing bank by said withdrawal amount;(o) debiting a correspondent bank money account in said second accounting system by said withdrawal amount;(p) transferring said new electronic representation of money from said second teller module to said first teller module, via said second cryptographically secure session;and (q) transferring said new electronic representation of money from said first teller module to said transaction module, via said first cryptographically secure session.
- 10A method for a subscriber to use a transaction module (4) to perform a deposit to said subscriber's bank account at an issuing bank (1) having a teller module (5), a money generator module (6), and a computer controlled accounting system, said method characterized by the steps of:(a) said subscriber selecting, by way of said transaction module (4), a deposit amount and said bank account in which to make said deposit;(b) checking if said transaction module (4) contains sufficient funds;(c) said transaction module (4) establishing a first cryptographically secure session with said teller module (5);(d) said transaction module (4) sending a deposit request to said teller module (5), via said first cryptographically secure session, wherein said deposit request includes said deposit amount and bank account information corresponding to said bank account;(e) checking said bank account information to verify its validity;(f) said transaction module (4) transferring a first electronic representation of money to said teller module (5), via said first cryptographically secure session;and (g) crediting said bank account in said accounting system by said deposit amount.
- 14A method for a subscriber to use a transaction module (4) to deposit electronic representations of money (11) at a correspondent bank (2), said method characterized by the steps of:(a) said subscriber selecting, by way of said transaction module (4), a deposit amount and a bank account in which to make a deposit;(b) checking if said transaction module (4) contains sufficient funds;(c) establishing a first cryptographically secure session between said transaction module (4) and a first teller module associated with said correspondent bank (2);(d) said transaction module (4) sending a first deposit request to said first teller module, via said first cryptographically secure session, wherein said deposit request includes said first deposit amount and bank account information corresponding to said bank account;(e) checking said bank account information to verify its validity;(f) said transaction module transferring said electronic representations of money to said first teller module, via said first cryptographically secure session;(g) said first teller module sending a first deposit acknowledgment to said transaction module, via said first cryptographically secure session;(h) crediting said subscriber's bank account in a first computer controlled accounting system associated with said correspondent bank by said deposit amount;(i) establishing a second cryptographically secure session between said first teller module and a second teller module;(j) said first teller module sending a second deposit request to said second teller module, via said second cryptographically secure session, wherein said second deposit request includes said deposit amount;(k) debiting a deposited at issuing bank account in said first accounting system by said deposit amount;(l) transferring said electronic representations of money from said first teller module to said second teller module, via said second cryptographically secure session;(m) crediting a correspondent bank money account in a second computer controlled accounting system associated with an issuing bank by said deposit amount;and (n) said second teller module sending a second deposit acknowledgment to said first teller module, via said second cryptographically secure session.
- 17A method for updating time limited electronic representations of money stored in a transaction module (4) by interaction with a teller module (5) during a withdrawal transaction, characterized by the steps of:establishing a connection between said transaction module (4) and said teller module (5) for performing a withdrawal transaction, wherein said transaction module stores a plurality of electronic representations of money (11) each associated with a time limit;said transaction module (4) transferring its stored electronic representations of money (11) to said teller module whether or not said electronic representations of money (11) have expired;said money generator module (6) generating a new electronic representation of money having a total monetary value equal to a withdrawal amount plus a total value of all said electronic representations of money transferred from said transaction module, where said new electronic representation of money has an updated time limit;and said teller module (5) transferring said new electronic representation of money to said transaction module (4).
- 18A method for updating time limited electronic representations of money (11) stored in a transaction module (4) by interaction with a teller module (5) during a deposit transaction, characterized by the steps of:establishing a connection between said transaction module (4) and said teller module (5) for performing a deposit transaction, wherein said transaction module (4) stores a plurality of electronic representations of money (11) each associated with a time limit;said transaction module (4) transferring its stored electronic representations of money (11) to said teller module (5) whether or not said electronic representations of money (11) have expired;said money generator module (6) generating a new electronic representation of money having a total monetary value equal to a total value of all said electronic representations of money transferred from said transaction module minus a deposit amount, where said new electronic representation of money has an updated time limit;and said teller module (5) transferring said new electronic representation of money to said transaction module (4).
- 20An electronic monetary system for withdrawing electronic representations of money (11), characterized by:a transaction module (4), a first teller module, and a second teller module each having cryptographic means for establishing a session, a transaction log, and abort means for reversing the module state in the event of transaction failure, where transaction failure may be triggered by a time-out protocol;wherein a first session is established between said transaction module (4) and said first teller module, and a second session is established between said first teller module and said second teller module;wherein during a withdrawal transaction, an electronic representation of money (11) is transferred from said second teller module to said first teller module via said second session, and then said electronic representation of money is transferred from said first teller module to said transaction module (4) via said first session;wherein after said transaction module (4) receives said electronic representation of money (11), said first teller module and transaction module finally update their transaction logs to finalize said first session;and wherein after said first session is finalized said second teller module and said first teller module finally update their transaction logs to finalize said second session.
Independent claims8
428 paragraphs, as filed
Background of the Invention
0001The present invention relates to an electronic monetary system for implementing electronic money payments as an alternative medium of economic exchange to cash, checks, credit and debit cards, and electronic fund transfer. The Electronic-Monetary System is a hybrid of currency, check, card payment systems and electronic funds transfer systems, possessing many of the benefits of these systems with few of their limitations. The system utilizes electronic representations of money, which are designed to be universally accepted and exchanged as economic value by subscribers of the monetary system.
0002Today, approximately 350 billion coin and currency transactions occur between individuals and institutions every year. The extensive use of coin and currency transactions has limited the automation of individual transactions such as purchases, fares and bank account deposits and withdrawals. Individual cash transactions are burdened by the need of having the correct amount or providing change therefor. Furthermore, the handling and managing of paper cash and coins is inconvenient, costly and time consuming for both individuals and financial institutions alike.
0003Although checks may be written for any specific amount up to the amount available in the account, checks have very limited transferability and must be supplied from a physical inventory. Paper-based checking systems do not offer sufficient relief from the limitations of cash transactions, sharing many of the inconveniences of handling currency while adding the inherent delays associated with processing check. To this end, economic exchange has striven for greater convenience at a lower cost, while also seeking improved security.
0004Automation has achieved some of these qualities for large transactions through computerized electronic funds transfer ("EFT") systems. Electronic funds transfer is essentially a process of value exchange achieved through the banking system's centralized computer transactions. EFT services are a transfer of payments utilizing electronic "checks", which are used primarily by large commercial organizations.
0005The Automated Clearing House (ACH) and point of sale (POS) systems are examples of electronic funds transfer systems that have become used by retail and commercial organizations on a substantial basis in recent years. However, the payments made through these types of EFT systems are limited in that they cannot be performed outside of the banking system. Moreover, ACH transactions usually cannot be performed during off business hours.
0006Home banking bill payment services are examples of an electronic funds transfer system used by individuals to make payments. Currently, home banking initiatives have found few customers. Of the banks that have offered services for payments, account transfers and information over the telephone lines using personal computers, less than one percent of the bank's customers are using the service. One reason that home banking has not been a successful product is that the customer cannot deposit and withdraw money as needed in this type of system.
0007Current EFT systems, credit cards, or debit cards, which are used with an on-line system to transfer money between accounts, such as between the account of a merchant and that of a customer, cannot satisfy the need for an automated transaction system that provides for the transfer of universally accepted economic value outside of the banking system.
0008To implement an automated, yet more convenient transaction system that does require the banking system to intermediate the transfer, and that can dispense some form of economic value, there has been a trend towards off-line electronic funds transfer. For example, numerous ideas have been proposed for some form of "electronic money" that can be used in cashless payment transactions as alternatives to the traditional currency and check types of payment systems, see U.S. Patent No. 4,977,595, entitled "METHOD AND APPARATUS FOR IMPLEMENTING ELECTRONIC CASH", and U.S. Patent No. 4,305,059, entitled "MODULAR FUNDS TRANSFER SYSTEM".
0009The more well-known techniques include magnetic stripe cards purchased for a given amount and from which a prepaid value can be deducted for specific purposes. Upon exhaustion of the economic value, the cards are thrown away. Other examples include memory cards or so-called smart cards, which are capable of repetitively storing information representing value that is likewise deducted for specific purposes.
0010However, these proposed systems suffer from a failure to recognize fully the significance of bank deposits as money, and their necessity to back any form of universally accepted monetary representations that may be issued. In the systems disclosed thus far, representations of economic value, whether electronic or paper, are issued without the backing of equal valued liabilities as the counterpart to their assets.
0011None of the paperless payment systems that have been proposed so far are comprehensive enough so as to implement a multipurpose, electronic monetary system that includes not only the automated devices that allow subscribers to transfer electronic funds or money between them without any intermediating system, but that also encompasses and includes an entire banking system for generating the value represented by the electronic money and for clearing and settling the electronic money accounts of the banks and financial institutions involved to maintain a monetary balance within the system.
0012Thus, specifically, there is a need for a system that allows common payor to payee transactions without the intermediation of the banking system, and that gives control of the payment process to the individual. Furthermore, a need exists for providing a system of economic exchange that can be used by large organizations for commercial payments of any size, that does not have the limitations of the current EFT systems.
Statement of Invention
0013According to a first aspect of this invention, there is provided a method for a subscriber to use a transaction module in order to perform a withdrawal from said subscriber's bank account at an issuing bank having a teller module, a money generator module and a computer-controlled accounting system, as claimed in claim 1 herein.
0014According to a second aspect of this invention, there is provided a method for a subscriber to use a transaction module to withdraw an electronic representation of money from a correspondent bank, as claimed in claim 7 herein.
0015According to a third aspect of this invention, there is provided a method for a subscriber to use a transaction module to perform a deposit to said subscriber's bank account at an issuing bank having a teller module, a money generator module and a computer-controlled accounting system, as claimed in claim 10 herein.
0016According to a fourth aspect of this invention, there is provided a method for a subscriber to use a transaction module to deposit electronic representations of money at a correspondent bank, as claimed in claim 14 herein.
0017According to a fifth aspect of this invention, there is provided a method for updating time limited electronic representations of money stored in a transaction module by interaction with a teller module during a withdrawal transaction, as claimed in claim 17 herein.
0018According to a sixth aspect of this invention, there is provided a method for updating time limited electronic representations of money stored in a transaction module by interaction with a teller module during a deposit transaction, as claimed in claim 18 herein.
0019According to a seventh aspect of this invention, there is provided an electronic monetary system for withdrawing electronic representations of money, as claimed in claim 20 herein.
Brief Description of the Drawings
0020Other objects and advantages of the present invention will become more apparent by the following description with reference to the accompanying drawings, in which: <ul id="ul0001" list-style="none" compact="compact"><li>Figure 1 is a diagram illustrating general aspects of an electronic monetary system.</li><li>Figure 2 is a schematic diagram of the operative arrangement of the components of an electronic monetary system, helpful in understanding the invention.</li><li>Figure 3 is a perspective diagram of several embodiments of external systems that may house a money module, helpful in understanding invention.</li><li>Figure 4 is a block form diagram of a transaction money module, helpful in understanding the invention.</li><li>Figure 5 is a block form diagram of a teller money module, helpful in understanding the invention.</li><li>Figure 6 is a block form diagram of a money generator module, helpful in understanding the invention.</li><li>Figure 7 is a block diagram of the network arrangement, helpful in understanding the invention.</li><li>Figure 8 is a block diagram of a network server, helpful in understanding the invention.</li><li>Figure 9 is a flow diagram of a security server, helpful in understanding the invention.</li><li>Figure 10 is a block form diagram of a security server, helpful in understanding the invention.</li><li>Figures 11-24 are flow diagrams of accounting examples, helpful in understanding the invention.</li><li>Figure 25 is a flow diagram of a transaction reconciliation system, helpful in understanding the invention.</li><li>Figure 26 is a flow diagram of a clearing system, helpful in understanding the invention.</li><li>Figure 27 is a flow diagram of a money issued reconciliation system, helpful in understanding the invention.</li><li>Figures 28-50A are flow charts of transaction examples, helpful in understanding the invention.</li></ul>
Disclosure of the Preferred Embodiment of the Invention
0021The present invention contemplates an improved monetary system using electronic media to securely and reliably exchange economic value. The system can be implemented by integrating novel data processing systems with other procedures which can be implemented with the current worldwide banking systems.
0022Throughout this description, "electronic money" may also be referred to by the abbreviation "E-M." Additionally, the term "bank" is used hereinafter to indicate any banking, financial institution or the like which is a participant of the present invention.
0023Referring now to the drawings, wherein like numerals refer to like components, there is disclosed in Figure 1, in block form, broad aspects of the preferred embodiment. In Fig. 1, the general relationship among the features of the system is shown. The system includes Issuing Banks <b>1</b> each having a Teller money module <b>5</b> and a Money Generator module <b>6</b>; Correspondent Banks <b>2</b> each having a Teller money module <b>5</b>; an electronic money Clearing Bank <b>3</b>; a Certification Agency <b>28</b> and a plurality of Transaction money modules <b>4</b> owned by subscribers of the system. Though money generator module <b>6</b> and teller module <b>5</b> are preferably embodied separately, the functions of these module may be embodied in a unitary device processor control.
0024Electronic notes <b>11</b>, the media for transferring electronic money, are generated by the Money Generator module 6 for an Issuing Bank <b>1</b>. Theses notes 11 are then transferred by a Teller money module <b>5</b> to a subscriber utilizing a Transaction money module <b>4</b>. Electronic notes authorizations For security reasons, all electronic notes <b>11</b> will expire after a preset time period. Once expired, the notes <b>11</b> must be redeemed at a participating bank for updated ones before they can be transferred.
0025An Issuing Bank <b>1</b> generates and distributes the electronic notes <b>11</b>, and is liable for their redemption. An Issuing Bank <b>1</b> performs deposits, withdrawals, payments to loans and inquiries for other money modules.
0026A Correspondent Bank <b>2</b> is a participating bank which distributes electronic money through accounts it maintains at Issuing Banks <b>1</b>, but does not generate any electronic money, and is not liable for its redemption. Because it cannot generate any electronic money, the Correspondent Bank <b>2</b> in the preferred embodiment must make real-time requests of electronic money from an account it maintains at an Issuing Bank <b>1</b> whenever a subscriber wishes to withdraw electronic money at a Correspondent Bank <b>2</b>.
0027Conversely, a Correspondent Bank <b>2</b> deposits all electronic money deposited by subscribers, to the accounts the Correspondent Bank <b>2</b> holds at Issuing Banks <b>1</b>. These accounts will be described hereinafter. A Correspondent Bank <b>2</b>, like an Issuing Bank <b>1</b>, will perform deposits withdrawals, payments to loans and bank inquiries.
0028Notably, an Issuing Bank <b>1</b> may also be a Correspondent Bank <b>2</b> for the monetary units that it does not generate. For example, an Issuing Bank <b>1</b> for electronic dollar notes <b>11</b> may be a Correspondent Bank <b>2</b> for electronic notes <b>11</b> of yen, marks, issued by other banks etc.
0029It is also important to note that the system of the invention can function without correspondent Banks <b>2</b>. For example, a subscriber can eliminate the use of a Correspondent Bank <b>2</b> by communicating directly with his/her Issuing Bank <b>1</b> when making a deposit, withdrawal, etc. Correspondent Banks <b>2</b> are included in the preferred embodiment for the practical purpose of expanding distribution of the system while reducing the risks that are inherent in any banking system, such as the risks caused by the collapse of a bank issuing money.
0030The Clearing Bank <b>3</b> is utilized when more than one bank is issuing electronic money. According to the invention, it is anticipated that more than one bank will be issuing electronic money. Thus, the Clearing Bank <b>3</b> is provided to clear the electronic money deposited and to balance accounts it maintains for the Issuing Banks <b>1</b>. The Clearing Bank <b>3</b> maintains demand accounts for each Issuing Bank <b>1</b> in the system.
0031The Certification Agency <b>28</b>, is the centerpiece of the system security. It provides a process that "certifies" the validity of a money module for a certain period of time by issuing a certificate to each money module. A money module must have a valid certificate in order to be able to transact with other money modules 4, 5, 6.
0032Before the certificate expires, it must be updated so that a subscriber can continue to use his/her transaction money module <b>4</b>. This process makes users of the system establish periodic contact with the Certification Agency <b>28</b>.
0033Periodic contact allows for faster response when tampering with the money modules of the system is detected. To this end, the Certification Agency <b>28</b> also provides a list of offending or compromised money modules to other money modules so that transactions with the bad units may be blocked.
0034The components shown in Figure 1 are best understood by referring to the system's operative arrangement illustrated in Figure 2. As illustrated in Figure 2, the preferred embodiment provides for supplements to the current banking systems that include the following additional components: a plurality of the Transaction money modules <b>4</b>, the Teller money modules <b>5</b>, and the Money Generator modules <b>6</b>, for creating, transferring and storing the electronic notes <b>11</b> (money); a Clearing System <b>13</b> to balance the accounts of banks issuing currency and credit; a security system <b>21</b> to maintain the integrity of the electronic notes <b>11</b>; the current banking systems <b>20</b>; a network <b>25</b> (exemplified by the lines interconnecting modules and systems) to mediate transactions between money modules <b>4</b>,<b>5</b>,<b>6</b>, the participating banks <b>1</b>,<b>2</b>,<b>3</b> of system <b>20</b> and the security system <b>21</b>; a Transaction Reconciliation system <b>22</b> to detect money module malfunctions and insider tampering of the system; a Money Issued Reconciliation System <b>23</b> to detect counterfeiting and reuse of electronic money; and a Money Position System <b>24</b> to keep track of the electronic money in circulation.
0035Playing a major role in the preferred embodiment are three classes of "money modules" for creating, storing, and transferring the electronic objects that represent economic value. These include the Transaction money modules <b>4</b>, the Teller money modules <b>5</b>, and the Money Generator modules <b>6</b>. It is contemplated that these money modules <b>4</b>,<b>5</b>,<b>6</b> will be a combination of tamper-proof hardware and application software that are meant to be components of a larger processing environment.
0036Referring to the top right-hand side of Figure 2, a Transaction money module <b>4</b> containing electronic notes <b>11</b> stored therein (not shown) may be used to exchange foreign currency or make a payment with another Transaction money module <b>4</b>, using a secure, encrypted protocol either by a telephonic link, or a proximate communication link. Because it is contemplated that an electronic note <b>11</b> will be fungible, i.e., it can be broken into any desired amount, the amount transacted between the Transaction money modules <b>4</b> may be of any amount up to the amount stored in the payor's Transaction money module <b>4</b>.
0037A payee's Transaction money module <b>4</b> that has received the electronic note <b>11</b> as a payment may, in turn, be used to transfer all or any amount of the electronic money contained therein to another subscriber's Transaction money module <b>4</b>. Alternatively, the payee may deposit the electronic money into his/her bank account.
0038The value of the electronic money stored in the Transaction money module <b>4</b> may also be redeemed at any participating bank (e.g., Correspondent Bank <b>2</b> or Issuing Bank <b>1</b>) for paper money by transferring any amount of the electronic money to a bank's Teller money module <b>5</b>, whereby a teller or an Automated Teller Machine (ATM) will return an equal amount of paper money. Naturally, it is anticipated that paper money may also be exchanged for equal valued electronic money.
0039As will be appreciated, the Transaction money module <b>4</b> may be configured to make deposits, withdrawals, loan payments, inquiries and exchanges of currencies of electronic notes <b>11</b> directly through a Teller money module <b>5</b> at an Issuing <b>1</b> or Correspondent Bank <b>2</b> or remotely through a telephonic connection to an Issuing <b>1</b> or Correspondent Bank <b>2</b> Teller money module <b>5</b> (thereby providing, among other things, the transactions not available in current home banking systems). Upon a request to transact with a bank, the Teller money module <b>5</b> mediates the transactions for the subscriber's bank account as well as the banking system's electronic money accounts.
0040It should be noted that a subscriber will not be required to maintain a bank account in order to own and use a Transaction money module <b>4</b>. For instance, a subscriber may obtain a stand-alone computing device that contains a Transaction money module <b>4</b> and use the device only in off-line peer-to-peer transactions with other devices containing a Transaction money module <b>4</b>, such as a merchant's point-of-sale terminal. Of course, the merchant may then transfer the electronic money to another commercial organization to meet its obligations, or it may deposit the electronic money at its own bank.
0041In the preferred embodiment, electronic money deposited at any Issuing Bank <b>1</b> other than the original Issuing Bank <b>1</b> itself will subsequently be settled for value with the original Issuing Bank <b>1</b> through the central clearing and settling process performed by the Clearing System <b>13</b>. It is anticipated that the clearing and settling processes will be managed by the Clearing Bank <b>3</b> (Figure 1). Each Issuing Bank <b>1</b> Teller money module <b>5</b> sends all the electronic notes <b>11</b> deposited at its bank but issued from other Issuing Banks <b>1</b> to the Clearing Bank <b>3</b> in order to settle for the value posted to their customers' accounts.
0042When a withdrawal, an exchange for foreign currencies, an exchange of paper cash for electronic money, or an updating of the electronic money occurs, the Money Generator module <b>6</b> Figure 2, creates and digitally signs electronic objects having economic value - either currency or credit notes <b>11</b> (Figure 1) - that are to be sent to the Transaction money modules <b>4</b> through the participating bank's Teller money modules <b>5</b> in the form of a packet of electronic notes <b>11</b>. As mentioned above, the electronic currency notes <b>11</b> are the equivalent of bank notes that are backed by deposits, and can be traded between Transaction money modules <b>4</b>.
0043During the withdrawal transaction, the Teller money module <b>5</b> and the Transaction money module <b>4</b> may establish a communications link using an encrypted protocol to securely transfer the notes <b>11</b> from the Teller money module <b>5</b> to the Transaction money module <b>4</b>.
0044Records of the notes <b>11</b> generated and conveyed by the Money Generator module <b>6</b> are sent to the local bank's Transaction Reconciliation System <b>22</b> and an Issuing Bank's <b>1</b> Money Issued Reconciliation System <b>23</b> for maintaining statistical and housekeeping functions. Records of the electronic notes <b>11</b> cleared and settled at the Clearing Bank <b>3</b> are also provided to the Money Issued Reconciliation System <b>23</b> . From these compilations, a financial position of the system can be produced by the Money Position System <b>24</b>.
0045Discrepancies and malfunctions are reported to the Security System <b>21</b> which downloads the lists of problem money modules to all money modules in the system when they are connected to the Network <b>25</b>. By carrying this list, a Transaction money module <b>4</b> will be inhibited from transacting with other suspect Transaction money modules <b>4</b>.
0046Having thus provided an overview of the preferred embodiment, there will now follow a more detailed description of the individual elements and the transactions between them.
Money modules
0047Figure 3 provides several embodiments of external systems or devices for housing money modules.
0048In the preferred embodiment, the external system or device will typically contain data display means, data input means, data processing means, memory storage means, direct connection or contactless bidirectional communications means, and the money module packaged in a tamper - proof housing, all interfaced by suitable means for information transfer, such as are well known in the art.
0049As will be understood, a money module may be embodied as a modular component of any larger processing environment while still performing the same functions. For example, Transaction money modules <b>4</b> may work as coprocessors embedded in personal portable computer devices like the Hewlett-Packard 95LX, or as co-processors in mainframe computers, workstations, point-of-sale terminals or telephone devices (fixed or portable) connected to a network.
0050A Teller money module <b>5</b> may be embodied as a co-processor in the bank's financial computer systems. The Money Generator module <b>6</b> could be a separate processing unit networked to the bank, a co- processor in a general unit networked to the bank, a co-processor in a general purpose computer, or it may be combined with an Issuing Bank's <b>1</b> Teller money module <b>5</b> in a larger processor as illustrated by the unitary device 1001 of Figure 1--.
0051Because it is anticipated that a money module will be implemented in a separate processing device, it is assumed that corresponding interface circuitry would be provided in the host processing device to provide communication between the processing device and the money module.
0052Notably, all classes of money modules contemplated by the invention may be implemented programmatically or by direct electrical connection through customized integrated circuits, or a combination of both, using any of the methods known in the industry for providing the functions described below without departing from the teachings of the invention. Those skilled in the art will appreciate that from the disclosure of the invention provided herein, commercial semiconductor integrated circuit technology would suggest numerous alternatives for actual implementation of the inventive functions of the money module that would still be within the scope of the invention.
Transaction Money Module
0053In one embodiment, the Transaction money module <b>4</b> may be imbedded in any computer of any size or use, like those serving as general purpose computers or work-stations, to provide functions not limited to E-M transaction use. This latter application will allow for such uses as real-time, off-line payments between personal computing devices, or on-line payments for network services such as information retrieval, telephone calls, or for purchasing airline tickets, theater tickets, etc.
0054In another embodiment, the Transaction money module <b>4</b> may be imbedded in an individual hand-held integrated circuit unit, such as a personalized hand-held computer that may be readily carried by an individual as though it were a wallet. As an illustration, the device of the preferred embodiment may include a keyboard, a pen or stylus, a touch screen or voice recognition circuitry as a data input means, an alphanumeric LCD dot matrix display as a display means, an infrared optical transceiver as a contactless bidirectional communications means, and an RJ-11 telephone jack coupled to modem circuitry as a telephonic communications means. Additionally, the device may also include various electronic processing and storage means for providing calculator capabilities, for storage and processing data of the owner, etc.
0055It is important to note that the particular design of the external device is not critical to the invention, and other technologies suitable for accomplishing the foregoing functions may also be used. For example, an LED instead of an LCD display panel may be used; radio, infrared, inductive or capacitive communications methods may be used instead of direct connection, optical communications methods may be used; etc.
0056In general, it is anticipated that any Transaction money module <b>4</b> owned by a subscriber will be embodied in a self-contained, tamper-resistant unit that contains components which are difficult to access, and thus prevent any person from improperly examining, counterfeiting or modifying any of its contents or arrangements. For example, integrated semiconductor circuits, whose contents are difficult to examine, encased in a tamper-resistant package such as that formed by an epoxy or plastic lamination may provide a high degree of physical security while providing the necessary storage, computation, timing, and other data processing functions.
0057However, the invention is not limited to any particular tamper-resistance means, inasmuch as there are a number of methods known in the industry for providing such security. Such tamper-resistance will also prevent the owner, who can control only some of the internal operations of the Transaction money modules <b>4</b>, from certain accesses to thereby provide security from abuse to other relevant institutions and individuals.
0058Each Transaction money module <b>4</b> will have a way of ensuring its own association with a particular subscriber, so that its use by other individuals may be limited. In addition to the use of Personalized Identification Number (PIN) methods that are well known in the art, the Transaction money module <b>4</b> may also include means such as a fingerprint reader, voiceprint analyzer, written signature analyzer, or other so-called biometrics means, to determine the physical identity of an authorized subscriber.
0059Additionally, the Transaction money module <b>4</b> may utilize personalized interactive proofs using questions that only a true owner would be able to correctly answer, such as the owner's mother's maiden name, his/her favorite color, etc. Any such techniques may provide additional security for organizations, and may also be to the advantage of the authorized user since such security can protect the subscriber's data from inspection and use by someone else coming into possession of the Transaction money module <b>4</b>.
0060Because the Transaction money module <b>4</b> can take on a variety of physical representations, it will be described by the functions performed in addition to the pertinent physical characteristics of a preferred embodiment.
0061Referring now to Fig. 4, a Transaction money module <b>4</b> is shown diagrammatically in block form. Specifically, a Transaction money module <b>4</b> has (1) an external interface <b>30</b> that interfaces the Transaction money module <b>4</b> to the module's data processing means, the input/output means (human interface) and the communications circuitry of the external device; (2) a session manager <b>31</b> to control and commit (i.e., finalize) or abort a transaction session; (3) a transactor <b>32</b> to manage application functions; and (4) a money holder <b>38</b> to contain and manage the electronic representations of money.
0062According to the invention, the following application functions may be implemented in the preferred embodiment of the present invention:
0063The <u>To Subscriber</u> application <b>33</b> performs the function of comparing the owner identification characteristics, such as a user's personal identification number (PIN) and biometrics characteristic (e.g., fingerprint, voiceprint, etc.), that are stored in the memory of the Transaction money module <b>4</b>, to those of the individual who is attempting to gain access to the Transaction money module <b>4</b>. After the proper ownership is verified, the Transaction money module <b>4</b> may be activated, and the user is allowed certain accesses to the Transaction money module's <b>4</b> stored contents. Messages to the subscriber, and subscriber inquiries as to the information contained within the Transaction money module <b>4</b> are also handled by this application function.
0064The <u>To Teller</u> application <b>34</b> interfaces the Transaction money module <b>4</b> to the Teller money modules <b>5</b> for initiating and performing deposit, withdrawal, loan payment transactions, and bank inquiries with such Teller money modules <b>5</b>.
0065The <u>Pay/Exchange</u> application <b>35</b> supervises the sending and receiving of electronic notes <b>11</b> between Transaction money modules <b>4</b>, managing the process in which the electronic notes <b>11</b> are properly "packaged" as to amount, digital signatures, etc. This application provides that the electronic notes <b>11</b> are transferred in a recognized, valid format. Notably, this is the application that allows a money module to perform payments and foreign exchanges. Without this application in the preferred embodiment, a Transaction money module <b>4</b> cannot make a payment to another Transaction money module <b>4</b>.
0066The <u>Tran Log Mgr.</u> application <b>36</b> provides the management and overseeing of a log that records completed transactions undertaken by the money module. For each completed transfer of electronic money, an illustrative Tran Log records: <ul id="ul0002" list-style="none" compact="compact"><li>(1) the type of transfer (i.e., payment, deposit, foreign exchange, etc.),</li><li>(2) the date of transfer,</li><li>(3) the amount of transfer,</li><li>(4) the Issuing Bank <b>1</b> identifier</li><li>(5) the note identifier,</li><li>(6) the monetary unit,</li><li>(7) the identifier of the other money module involved in the transaction, and for deposits, withdrawals and loan payments:</li><li>(8) the bank account number,</li><li>(9) the bank identifier, and</li><li>(10) the amount of the transaction.</li></ul>
0067In the preferred embodiment, every money module will have an identifier. A money module identifier may be thought of as the "serial number" of the money module and is never changed.
0068It is anticipated that a subscriber may have access to several of the fields of data stored in the Tran Log application, such as histories of the amount, date, and type of transfer. Information as to the expiration date of a certificate may also be accessed by the subscriber so that he/she will be informed as to the need to update or revalidate the money module's certificate.
0069The <u>Maintain Security</u> application <b>37</b> manages a list of money module identifiers that are known to have been generally compromised. In particular, this is a list that is distributed to each money module when it communicates with the Network <b>25</b>, and is a list of money modules that have passed an invalid or counterfeit electronic note <b>11</b> or have performed acts deemed detrimental to the system.
0070When establishing a session between money modules, each money module checks its list of bad money modules to see if the other is an offending money module. If the other money module's identifier appears on the list, the communication is broken off.
0071This application also provides the process for obtaining the certificate unique to the money module, for synchronizing the internal clock, and for managing the creation of new cryptography keys.
0072The <u>Note Directory</u><b>39</b> application performs the function of keeping track of the location, identification and value of each of the electronic notes <b>11</b> stored within the money module. A note <b>11</b>, whether it is an electronic currency note or an electronic credit note, is the basic unit of electronic money. It is the electronic object representing the economic value, the electronic bits that contain the amount, expiration date, note identifier etc. (described in detail below) that gets digitally signed (described below) and encrypted when being transferred. Both electronic currency notes <b>11</b> and electronic credit notes <b>11</b> may be located by the Note Directory <b>39</b>.
0073The Note Directory application <b>39</b> updates the current amounts of electronic notes <b>11</b> (both currency and credit), after every transfer. A date-of-expiration, a note identification number and an Issuing Bank identifier is also recorded with the location of each note <b>11</b>.
0074In summary, the Note Directory <b>39</b> keeps track of the note identification number, the Issuing Bank <b>1</b> identifier, the date-of-expiration of the note <b>11</b>, the location of the note <b>11</b> as stored in the Transaction money module <b>4</b>, and the current amounts of the value of each of the notes <b>11</b> stored. These records are maintained for both electronic currency and electronic credit. For a credit note <b>11</b>, the account number of the credit line is also maintained.
0075The <u>Notes</u> application <b>40</b> manages the storage of the representations of the electronic notes <b>11</b> themselves, both currency and credit notes <b>11</b>. This application also generates the transfers when notes <b>11</b> are to be conveyed.
0076The <u>Packet Manager</u> application <b>41</b> manages the construction and formatting of a packet of electronic notes <b>11</b> that are to be transferred to another money module. For example, the Packet Manager <b>41</b> will utilize an algorithm so that the least number of electronic notes <b>11</b> are used to fulfill the requested amount of transfer, with the earliest dated electronic notes <b>11</b> being used first. Alternatively, when a packet of notes <b>11</b> is transferred to the receiving money module, the Packet Manager <b>41</b> application "disassembles" the packet, verifying the date and separating the data fields that represent the different electronic notes <b>11</b>.
0077The formatted packet gets several data fields appended to it when electronic notes <b>11</b> are "assembled." An identifier data field provides the indicia that identifies it as a packet. Additionally, data fields for the total value of the notes <b>11</b>, the number of notes <b>11</b>, and the individual locations of the notes <b>11</b> are provided.
0078The <u>Verifier</u> application <b>42</b> verifies that a received packet contains valid electronic notes <b>11</b> before a receiving money module accepts them. The Verifier <b>42</b> also checks that the total amount received is equal to the sum of the electronic notes <b>11</b> that are to be transferred. If the total amount and the individual electronic notes <b>11</b> are valid, an acknowledgment is returned to allow for completion of the transfer. Otherwise, an "invalid" message is sent, and the transfer may be aborted.
0079<u>Services</u> applications that are provided fall under two categories: <u>Clock/Timer</u><b>43</b> and <u>Cryptography</u>. The <u>Clock/Timer</u><b>43</b> provides output pulses for controlling a transaction timeout, such as the time between the sending of a message and the return of a corresponding message.
0080As will be appreciated, when two money modules are communicating, they may be monitoring a time-out protocol. For example, after a first money module has sent a message to a second money module, the Session Manager <b>31</b> of the first money module ("A") may set a timer for a reply if the Transactor <b>32</b> indicates that a reply is required. The Session Manager <b>31</b> may also number the message sent. This number would appear in the reply message from the Session Manager <b>31</b> of the second money module ("B").
0081If the timer expires before the message has been received, then Session Manager A <b>31</b> will query Session Manager B <b>31</b> to determine if the transaction is still running in B. If B does not reply then Session Manager A <b>31</b> will abort the transaction. If a reply is received that the transaction is proceeding, then the timer will be reset to a new time. If A queries B a predetermined number of times without receiving a reply to the original message, then A may abort the transaction.
0082Separately, this application also maintains the current date and time, both for user display and for verifying that an electronic note <b>11</b> to be received is not an expired one, along with other general clock functions that are commonly used in the industry.
0083The <u>Cryptography</u> application contains a Public Key <b>44</b> operation, a Symmetric Key <b>45</b> operation, and a Random Number Generator <b>46</b>. While the tamper-resistance of the Transaction money module <b>4</b> and its components makes it difficult for a person to modify the structure of the device or its contents, known cryptographic techniques are also employed to provide secure communications and payment transfers between money modules.
0084<u>Public key cryptography</u><b>44</b>, as is well known in the art, may be employed by this application to provide public key digital signatures, which are called "digital signatures" or simply "signatures" for brevity. The data in electronic notes <b>11</b>, may be represented by a digital number. The electronic notes <b>11</b>, are signed by digital signatures formed from this number. A digital signature can then be checked as corresponding to a particular message by anyone knowing the corresponding public key, which in the preferred embodiment would be all other money modules.
0085This application provides each money module with the ability to check the digital signature for authenticity. A money module receiving the digitally signed electronic note <b>11</b> can in turn sign and transfer it to others, who could also check, sign and distribute it.
0086Because of the "one way" nature and computational complexity of public-key digital signatures, it is thought to be infeasible to decipher and duplicate them within a feasible period of time, making such a security system resistant to forgery.
0087Lastly, this application also creates new public and private keys when needed.
0088<u>Symmetric Key cryptography</u><b>45</b> provides private key algorithms that are well known in the art, for individual session security and privacy between money modules. In the preferred embodiment, this application provides encryption/decryption means in order to secure information being exchanged between two money modules.
0089Any well known symmetric key cryptography technique, such as the National Data Encryption Standard (DES) system or other cryptography techniques, may be provided in this application. For example, due to the increasing interest in providing cryptographically secured communications, manufacturers are providing various semiconductor integrated circuit devices which perform the encryption and decryption of data. Cylink corporation's CIDEC data encryption devices are examples of commercially available encryption/decryption circuitry that would be suitable in the present invention for this application. Due to the federally mandated use of the DES algorithm, devices such as these are widely utilized to implement that algorithm.
0090It is important to note that the details of the particular cryptographic methodology utilized by the money modules are not critical and are not limited to a particular cryptographic technique.
0091The <u>Random Number Generator</u><b>46</b> generates random like numbers for creating new public/private keys for the Public Key application <b>44</b> and new private keys for the Symmetric Key <b>45</b> application. This application is utilized to vary in an unpredictable way the generation of temporary session keys.
0092Circuitry for providing such random number generation capability are well known in the art. For instance, a circuit utilizing a "noisy" diode may provide random values, as is well known in the industry. Random numbers may also be provided by a pseudorandom number generator circuit which implements a mathematical algorithm, such as the power-residue algorithm, that generates apparently random values from a "seed" number. The use of clocks or counters provides another often used source of random data. As will be understood, the Random Number Generator <b>46</b> may use techniques that are well known to a person of ordinary skill in the art to generate the temporary numbers, and thus need not be further described.
0093It should be further understood that the foregoing functions disclosed herein may be performed by known programming techniques and/or dedicated hardware and in some cases may be combination of both or shared resources from each. As may be appreciated by a person skilled in the art, many changes in form and detail can be made in dependance on specific application requirements without departing from the essential features of the money modules.
Teller money module
0094The banking systems <b>20</b> of both the Issuing Banks <b>1</b> and the Correspondent Banks <b>2</b> interface to the system of the invention through a Teller money module <b>5</b>. The Teller money module <b>5</b> may be imbedded in any general purpose computer or workstation. The particular design of the Teller money module <b>5</b>, like the Transaction money module <b>4</b>, may be implemented in readily known programming techniques or dedicated computer hardware, or a combination of both. As will be appreciated by a person skilled in the art, various designs of the Teller money module <b>5</b> may be employed to implement the functions described herein.
0095The details of one embodiment of the Teller money module <b>5</b> is shown in block form in Figure 5. The Teller money module <b>5</b> contains many of the same components and application functions of the Transaction money module <b>4</b> described above. Therefore, the identical components will only be repeated briefly here, while the distinguishing components will be fully described. It should be noted that the Teller money module <b>5</b>, like other money modules of the system, is also contained within a tamper-proof enclosure of the type common in the industry, so as to ensure the necessary security involved.
0096The Teller money module <b>5</b> contains an External Interface <b>30</b>, a Session Manager <b>31</b>, a Transactor <b>32</b> and a Money Holder <b>38</b> that perform similar functions to the corresponding components in the Transaction money module <b>4</b> described above.
0097Briefly, the External Interface <b>30</b> interfaces the Teller money module <b>5</b> to other processing and communications means within the Teller money module <b>5</b> host processor; the Session Manager <b>31</b> acts to control and commit (i.e., finalize) or abort a transaction session between the Teller money module <b>5</b> and another money module; the Money Holder <b>38</b> manages the storing and retrieval of electronic money; and the Transactor <b>32</b> manages the application functions of a To Teller <b>34</b>, the Tran Log Mgr. <b>36</b>, the Maintain Security <b>37</b>, the To Bank <b>47</b>, a To Money Generator <b>48</b>, and the To Transaction <b>49</b>.
0098The following list describes in brief, the applications contained in the Teller money module <b>5</b> that are functionally identical to the applications found in the Transaction money module <b>4</b>: <ul id="ul0003" list-style="dash" compact="compact"><li>To Teller <b>34</b>: Interfaces deposit and withdrawal functions to another Teller money module <b>5</b> .</li><li>Tran Log Mgr. <b>36</b>: Transaction log manager for recording transaction details.</li><li>Maintain Security <b>37</b>: Manages the list of compromised money modules, applies for certificates, synchronizes the clocks, and manages the creation of new digital keys.</li><li>Note Directory <b>39</b>: Keeps track of the location, value and identification of notes <b>11</b> by monetary unit. Summary totals are also maintained.</li><li>Notes <b>40</b>: Manages storage for the electronic notes <b>11</b> of exchange, and creates the transfers for the notes <b>11</b>.</li><li>Packet Manager <b>41</b>: Manages the assembly and dissembly of a packet to be transferred to a different money module.</li><li>Verifier <b>42</b>: Verifies that a received packet contains valid electronic notes <b>11</b>.</li><li>Clock/Timer <b>43</b>: Controls transaction timeout, expiration of the validity of the electronic notes <b>11</b>, expiration of the certificate, and general clock functions.</li><li>Cryptography <ul id="ul0004" list-style="none" compact="compact"><li>(i) Public key <b>44</b>: used for signatures to sign and validate notes <b>11</b> and to set up a secure transaction session.</li><li>(ii) Symmetric key <b>45</b>: Controls the security of a transaction session.</li><li>(iii) Random number generator <b>46</b>: Generates random like numbers for new cryptographic keys.</li></ul></li></ul>
0099Some of the distinguishing applications are the <u>To Bank</u><b>47</b> and <u>To Transaction</u><b>49</b> applications. The <u>To Bank</u> application <b>47</b> provides the interfacing means whereby the Teller money module <b>5</b> can perform exchanges of data for inquiries and account postings with the on-line systems of a bank. This application is also utilized for crosschecking the customer's account number with the accounts and type of transaction being requested.
0100The <u>To Transaction</u> application <b>49</b> performs deposits, withdrawals and payments to loans. This application operates whenever a Teller money module <b>5</b> is transacting with a subscriber's Transaction money module <b>4</b>.
0101As mentioned above, a Teller money module <b>5</b> may be associated with an Issuing Bank <b>1</b> or a Correspondent Bank <b>2</b>. When Teller money module <b>5</b> is associated with a Correspondent Bank <b>2</b>, it is utilized for intermediating deposits, withdrawals, and payments to loan accounts between a Transaction money module <b>4</b>, the Correspondent Bank's <b>2</b> on-line systems, and an Teller money module <b>5</b> at an Issuing Bank <b>1</b>.
0102When operating in an Issuing Bank <b>1</b> mode, the Teller money module <b>5</b> is used for intermediating deposits, withdrawals, and payments to loan accounts between other money modules and the Issuing Bank's <b>1</b> on-line systems. Additionally, when the Teller money module <b>5</b> is performing in an Issuing Bank <b>1</b> mode, a <u>To Money Generator</u> application <b>48</b> may be employed when requesting new notes <b>11</b>.
0103Basically, the To Money Generator application <b>48</b> performs banking functions dealing with requests for electronic notes <b>11</b>. It interfaces an Issuing Bank's <b>1</b> Teller money module <b>5</b> to a Money Generator Module <b>6</b>.
0104All of the other elements performed in an Issuing Bank's <b>1</b> Teller money module <b>5</b> are essentially identical to the similarly named components and application functions described above.
Money Generator Module
0105Figure 6 is a block diagram illustrating the application functions of a Money Generator module <b>6</b>. Money Generator modules <b>6</b> provide the mechanism that Issuing Banks <b>1</b> utilize to issue electronic money. A Money Generator module <b>6</b> is also encased in a tamper-resistant package for the same security reasons stated above for other money modules.
0106A Money Generator module <b>6</b> generates the electronic money (in the form of electronic notes <b>11</b>, to be described in further detail below), and distributes them to other money modules through the Teller money module <b>5</b> of an Issuing Bank <b>1</b>. The Money Generator module <b>6</b> includes a unique application not present in other money modules for responding to requests for electronic money. This is the <u>Money Creator</u> application <b>50</b>.
0107The <u>Money Creator</u> application <b>50</b> creates and formats the electronic objects representing value - either currency backed by demand deposits, or credit authorizations - and digitally signs these "electronic notes <b>11</b>" using public key cryptography in conjunction with its secret key, so that it may be sent to an Issuing Bank's Teller money module <b>5</b>.
0108Notably, in a Money Generator module <b>6</b> the <u>To Bank</u> application <b>47</b> notifies the bank systems of any irregularities, off-loads transaction records in the Tran Log to the Transaction Reconciliation System <b>22</b> and transfers electronic notes <b>11</b> to the Money Issued Reconciliation System <b>23</b>. All of the other applications of the Money Generator module <b>6</b> are identical to the similarly named applications of the money modules described above.
The Network
0109According to one embodiment of the invention, the individual components of the present invention may communicate over a Network <b>25</b>, as shown in Figure 7. The Network <b>25</b> will link together the Issuing Banks <b>1</b>, Correspondent Banks <b>2</b>, the Clearing Bank <b>3</b> and the Certification Agency <b>8</b>.
0110Transaction money modules <b>4</b> may be coupled to the Network <b>25</b> over the telephone exchange or via special terminal facilities at bank locations (e.g., additional contactless or cable connections at an ATM booth). A communication layer will carry transaction requests (e.g., deposits, withdrawals), packets of notes <b>11</b> and new certificates securely across the Network <b>25</b>. In the preferred embodiment, the Network <b>25</b> will also provide directories of financial services, and update the money module clocks and the bad money module list of all money modules.
0111As will be understood, the Network <b>25</b> may use well known data link or communications systems and techniques that utilize, for example, telephone lines, fiber-optic land lines, and satellites, and that include connective, timing and control software and circuitry for allowing access and transmitting digital information. The Network <b>25</b> may use commercially available protocols and operating techniques such as those set forth by the International Standards Organization ("ISO") for Open Systems Interconnect network standards. It is important to note that the particular design of the Network <b>25</b> is not critical and suitable technologies for accomplishing the foregoing data communications functions may be used.
0112Each entity (Banks <b>1</b> and <b>2</b>, Certifying Agency <b>28</b>, or Clearing Bank <b>3</b>) is also assumed to have an individual local network <b>16</b>, <b>17</b>, <b>18</b> and a gateway to the larger system Network <b>25</b>. The larger Network <b>25</b> will provide directory services for the routing of messages to connect to the appropriate local network <b>16</b>, <b>17</b>, <b>18</b>. The local network <b>16</b>, <b>17</b>, <b>18</b> has the responsibility of routing messages to the correct money module or Security Server <b>27</b>. A Security Server <b>27</b> is associated with each participating bank and the Certification Agency <b>28</b>, and is used for implementing the security of the system.
0113Figure 7 illustrates the preferred embodiment of the Network <b>25</b> generally, indicating that money modules of any participating bank may be intercoupled to the money modules of other banks and financial institutions, or another subscriber's Transaction money module <b>4</b> via a communications link directly connected into switching and processing centers and alternatively connected to a local network <b>16</b>, <b>17</b>, <b>18</b> at each entity.
0114A money module need only identify the local network <b>16</b>, <b>17</b>, <b>18</b> destination (typically a bank subnetwork) for the transmission of most messages. The local network <b>16</b>, <b>17, 18</b> will route the message to an appropriate money module for establishing a session. Once a session is established, the Network <b>25</b> directs all messages between the two money modules. The Network <b>25</b> also controls messages between money modules and Security Servers <b>27</b>.
0115Transaction money modules <b>4</b> may communicate over the Network <b>25</b> for deposits, withdrawals, payments to loan accounts, updates or inquiries. The Teller <b>5</b> and Money Generator modules <b>6</b> will sign on the Network <b>25</b> periodically to update security information. The sign-on will be initiated by the money module Session Manager <b>31</b>, or by the bank Security Server <b>27</b> if recertification is required or if there are changes to the bad money module list.
0116A bank services directory may be available to the money modules primarily for updating the electronic notes <b>11</b> and performing foreign exchange. A list of participating banks for either service will be available from the Network <b>25</b>.
0117In the preferred embodiment, the Network <b>25</b> will provide time services to the individual components of the present invention. Transaction <b>4</b>, Teller <b>5</b> and Money Generator modules <b>6</b> and Security Server <b>27</b> clocks may be updated from a Network Server <b>26</b> in the Network <b>25</b> every time that the respective money module accesses the Network <b>25</b>.
0118Network Servers <b>26</b> may provide the money module services described below, and gateway services to the local networks <b>16</b>, <b>17</b>, <b>18</b>. The application functions of the preferred embodiment of the Network Server <b>26</b> are shown in the block diagram of Figure 8. The following application functions are contemplated for the Network Server <b>26</b>: <ul id="ul0005" list-style="none" compact="compact"><li>(1) External Interface <b>56</b> - a communications layer which interfaces to the Network <b>25</b>; and</li><li>(2) Communication Session Manager <b>57</b> - manages a communication session between money modules, and between a money module and the Security Server <b>27</b>.</li></ul>
0119Application Services are provided by: <ul id="ul0006" list-style="none" compact="compact"><li>(3) Manage Network Sign-on <b>58</b> - controls the money module Network sign-on process;</li><li>(4) Synchronized Time/Date <b>59</b> - keeps money module Clock/Timer <b>43</b> services synchronized to a system time;</li><li>(5) Route Message <b>60</b> - directory services for routing messages, controlling message routing during sign-on and during a money module session; and</li><li>(6) Direct to Bank Services <b>61</b> - provides information on services provided by participating banks.</li></ul>
0120As will be appreciated by one skilled in the art, switching and processing centers that are known in the industry may be used to enable the networking cooperation between a financial institution and any other that is coupled to the same centers.
Electronic notes
0121we turn now to a further description of the elements of the electronic notes <b>11</b> themselves.
0122An electronic currency note <b>11</b> representing value is essentially an electronic object created from a transaction request (deposit or withdrawal) which is backed by demand deposits at an Issuing Bank <b>1</b>. At various times and in various points of the system, the notes may appear in electrical or magnetic forms or as electromagnetic radiation. These notes <b>11</b> may be transferred over several transactions just like paper money, with the additional property of fungibility that allows the electronic notes <b>11</b> to be commuted and transferred in amounts less than or equal to the value of the note <b>11</b>.
0123Notes <b>11</b> may be split by appending a transfer record to the note <b>11</b> and signing the note <b>11</b> using the private cryptographic key of the money module transferring the note <b>11</b>. Electronic credit notes <b>11</b>, however, can only be transferred once in the preferred embodiment, because it is anticipated that its receiver must deposit the credit note <b>11</b> so that the loan may be realized.
0124Credit notes <b>11</b>, unlike currency notes <b>11</b> are drawn on a subscriber's loan account. Each credit note <b>11</b> carries the account number it is drawn on. The account may be a revolving credit or credit line on which the note <b>11</b> is drawn, operating much in the same way that a check or a credit card account works in today's banking industry. Credit notes <b>11</b> can represent a part of or all of the credit line of the account.
0125In the preferred embodiment, the credit notes <b>11</b> can only be transferred to another Transaction money module <b>4</b> by the owner of the account, and the receiver of a credit note <b>11</b> can only deposit it into his or her account as currency. From there, the credit note <b>11</b> is cleared with the currency at the Clearing Bank <b>3</b>. The subscriber's bank recognizes the loan upon receipt of the cleared credit note <b>11</b>.
0126When credit notes <b>11</b> are withdrawn, they do not trigger any accounting transactions in the preferred embodiment. Current credit line processing may need to be modified to keep track of the amount of the credit line in the subscriber's Transaction money module <b>4</b>. Whenever the subscriber communicates with the Issuing Bank <b>1</b> maintaining the credit line, the amount of the credit line in the Transaction money module <b>4</b> is removed and replaced based on any adjustments to the credit line in the banking system <b>20</b>. Total credit notes <b>11</b> plus outstanding loans must be less than or equal to the total amount of the credit line.
0127Electronic notes <b>11</b> are comprised of three collections of data fields, namely a Body group, a Transfer group, and a Signatures and Certificate group. The Body group of data fields includes the following information: <ul id="ul0007" list-style="none" compact="compact"><li>(1) the type of electronic note <b>11</b>, i.e., whether it is a currency note <b>11</b> or a credit note <b>11</b>;</li><li>(2) the Issuing Bank's <b>1</b> identifier;</li><li>(3) the monetary unit identifier;</li><li>(4) a Note identifier;</li><li>(5) its date-of-issue;</li><li>(6) its date-of-expiration;</li><li>(7) the subscriber's account number (used only for credit notes <b>11</b>);</li><li>(8) the amount or value of the note <b>11</b>; and</li><li>(9) the Money Generator module <b>6</b> identifier.</li></ul>
0128The Transfer group of data fields includes: <ul id="ul0008" list-style="none" compact="compact"><li>(1) a total of the number of times that the electronic note <b>11</b> was transferred; (provided for currency notes <b>11</b> only)</li><li>(2) a list of transfer records that indicate the date-of-transfer, the amount transferred and the identification number of the receiver.</li></ul>
0129The Signature and Certificates group of data fields includes: <ul id="ul0009" list-style="none" compact="compact"><li>(1) the digital signature of the Money Generator module <b>6</b>;</li><li>(2) the Money Generator module <b>6</b> certificate;</li><li>(3) a list of payors which contains each payor's signature and certificate.</li></ul>
0130The body, transfer records, the signatures and the certificate of the chain of the transferred payments constitute the electronic note <b>11</b> sent. The remaining amount of the note <b>11</b> is recorded in the Note Directory <b>39</b> of the money module in which it is stored.
0131It is important to note that the authenticity of an electronic note <b>11</b> is determined by the validity of the digital signature of the Money Generator module <b>6</b>, and the validity of the signatures of past payors (if present). Any inconsistencies in this information will cause the transfer of any electronic notes <b>11</b> to be aborted.
0132It is also important to note that as a security measure, notes <b>11</b> will be valid for a limited time, up to its expiration date. An expired note <b>11</b> cannot be transferred, it must be updated by transacting with a participating bank. To this end, whenever a Transaction money module <b>4</b> performs any transaction with a Teller money module <b>5</b>, all of the electronic notes <b>11</b> stored in a Transaction money module <b>4</b> will be transferred to the Teller money module 5 so that notes 11 may be replaced with updated ones before they expire. This security procedure also helps to keep offending notes 11 from being circulated broadly.
0133As will be understood, every time that a note 11 is transferred to another money module, a transfer record indicating to whom it is transferred is appended. thus, the recipient of an electronic note 11 will also receive a record of all the past holders of the note 11.
0134For example, $50 electronic note 11 may be generated, and withdrawn by a Transaction money module 4. Assuming it is transferred to other money modules in $10, $10, and $30 denominations, the recipient money modules will receive the note 11 with the transfer record identifying the first transaction money module 4. When a recipient of the $10 note 11 transfers $5 of it to a third party, the third party receives the note 11 along with the record indicating the previous two holders. Assuming this $5 note 11 is then deposited, a record of it will be matched with other segments of the original $50 note 11 that find their way back into the banking system by the clearing and reconciliation processes of the present embodiment.
0135Only the receiver of the transferred note 11 can either deposit the note 11 or use it in payment. the Verifier 42 application of a money module is used to check the signature of each transfer, to determine if the note 11 is valid and to verify the identifier in the last transfer as the current holder of the note 11. This thwarts the new holder of a note 11 from trying to use a value greater than that which was transferred. It also inhibits copying notes 11 for use in another money module since the identifiers will not match.
0136As can be appreciated, a subscriber may be able to access certain information about the electronic notes <b>11</b> stored within the Transaction money module <b>4</b>.
0137In particular, the subscriber may be able to select information on the total amount of the electronic notes <b>11</b> stored, the monetary unit of the notes <b>11</b>, the type of electronic notes <b>11</b>, i.e., currency or credit, and the denomination of each note <b>11</b>.
System Security
0138The security of the system is maintained by the participating banks and the Certification Agency <b>28</b>, which creates and distributes money module certificates. A certificate of a money module is actually a money module's identifier, its public key, a digital signature of a money module's identifier and public key certificatory key (described below), and the version of the certificatory key. The certificate is unique in that it is associated with only one particular money module.
0139The Certification Agency <b>28</b> provides a secure means for money modules to validate each other prior to transacting, first by controlling the money module certificate process and second, by distributing a list of bad money module identifiers.
0140In the preferred embodiment, the money module certificate will be initially loaded into the money module by the Certification Agency <b>28</b>. The Certification Agency <b>28</b> generates the certificate for each money module using a certificatory key (a private key of the Certificate Agency <b>28</b>). It may be changed periodically and distributed under version control processes that are commonly used in the industry. As will be appreciated, every money module will store several versions of the certificatory key in order to verify certificates created by an older key. Because it is anticipated that certificates will expire over time, it is expected that only a few versions need be kept.
0141A certificate will only be valid for a limited period of time after its creation. Upon expiration of the certificate, the money module will not be allowed to transact with other money modules. Any money modules discovered to have been tampered with will be limited in the amount of damage that they can do to the system since their certificate will not be updated.
0142To block offending modules from transacting it is also desirable to have legitimate money modules receive the latest list of offending money modules soon after the list is updated. Naturally, this requires that Transaction money modules <b>4</b> access the Certification Agency <b>28</b> on a periodic basis to obtain the latest list. Placing a time limit on the Transaction money module's <b>4</b> ability to transact (in addition to the time limit placed on electronic notes <b>11</b>) will force subscribers to access the Certification Agency <b>28</b> through the Network <b>25</b> on a periodic basis to receive the latest bad money module list along with a new certificate. Advantageously, the period of the certificate validity can be closely monitored and adjusted according to security needs.
0143The Certification Agency <b>28</b> distributes its updated certificatory key and money module certificates on-line through the Security Server <b>27</b> (see Figure 9). An important component of the system's security is provided by Security Servers <b>27</b> at the participating banks and Security Servers <b>27</b> at the Certification Agency <b>28</b>.
0144Referring now to Figure 10, a block diagram of a preferred embodiment of the Security Server <b>27</b> is shown. It is contemplated that the Security Server <b>27</b> at the Certification Agency <b>28</b> or on a bank's local network <b>18</b> will contain the following application functions: <ul id="ul0010" list-style="none" compact="compact"><li>(1) External Interface <b>54</b> - a communications layer for connecting to a bank's local network <b>18</b> or the Certification Agency's local network <b>17</b>;</li><li>(2) Session Manager <b>55</b> - controls the security aspects of a transaction session;</li><li>(3) Create Certificate <b>50</b> - certifies a certificate for any of the money modules;</li><li>(4) Create Account Profile <b>51</b> - certifies and signs a bank account profile (described in detail hereinafter) that allows a Transaction money module <b>4</b> to access the subscriber's different bank accounts;</li><li>(5) Distribute Certification Keys <b>52</b> -distributes the Certification Agency's <b>28</b> list of valid public keys to the money modules;</li><li>(6) Bad Money Module Control <b>53</b> - controls and distributes the list of bad money modules; and</li><li>(7) Services - identical to the cryptographic functions <b>44</b>, <b>45</b>, <b>46</b> in the money modules described above</li></ul>
0145Since certificates will expire over time, money modules will be required to apply for new certificates periodically. In order to receive a new certificate, the money module creates a new public key and private key. The new public key, the money module identifier and the old certificate are presented to the Certification Agency <b>28</b> after being digitally signed using the old private key.
0146The Certification Agency <b>28</b> checks the signature and if it is valid, signs the new public key and identifier and sends the certificate to the money module with a future expiration date. The Certification Agency's <b>28</b> Security Server <b>27</b> also distributes a list of bad money modules via the Network <b>25</b>. Initially, each participating bank's Security Server <b>27</b> reports the identifiers of money modules which hold notes <b>11</b> invalidly or that are counterfeit. Those identifiers are passed through the Security Servers <b>27</b> and are compiled by the Certification Agency <b>28</b>.
0147All such identifiers are distributed to the Teller and Money Generator modules <b>5</b>, <b>6</b> respectively. A money module will not transact with another money module found on the list of bad money modules. Optionally, only those money modules which have demonstrated a flagrant breach of security will be distributed to Transaction money modules <b>4</b>.
0148If a Transaction money module <b>4</b> is lost or stolen, the subscriber would report it to his/her bank or to the Certification Agency <b>28</b> so that the money module identifier may be placed on the bad money module list to inhibit any further transactions.
0149While the security of the system is provided by being able to block a money module from transacting, system security is also maintained by providing the expiration date on the electronic notes <b>11</b> in addition to the money module certificates.
0150As mentioned previously, a note <b>11</b> will be valid only for a limited tine period after it is generated. Its date-of-expiration is a security parameter which may also be monitored and varied as needed. The period of validity of a note <b>11</b> can be varied by the value of the note <b>11</b>. Preferably, a large note <b>11</b> will expire in a shorter time period than a smaller one. For example, a $1,000,000 note may be set to expire five days after the date of its creation since it would provide a significant incentive to counterfeit, while a $50 note <b>11</b> may be set to expire after a month from the date of its creation.
0151A Transaction money module <b>4</b> will not accept expired notes <b>11</b>, but can deposit or exchange the notes <b>11</b> it may contain for new notes <b>11</b>. The expiration dates are checked by the Verifier <b>42</b> and Clock/Timer <b>43</b> applications in a money module before any electronic note <b>11</b> is transferred. Separately, it is also anticipated that if the money module loses power then it will not be able to pay or exchange notes <b>11</b> after power has been regained until it has communicated again with the Network <b>25</b> and had its security parameters updated.
0152As stated above, a subscriber will typically obtain a Transaction money module <b>4</b> already loaded with a certificate. Securing the Transaction money module <b>4</b> itself to a subscriber may be accomplished by assigning it a unique PIN, biometrics or other personal secret characteristics.
0153Before any personalization of the money module <b>4</b> may proceed, the Transaction money module <b>4</b> checks if there is a bank account already stored in the To Teller <b>34</b> application or if the Notes <b>40</b> application contains any electronic notes <b>11</b>. In either of these cases, the Transaction money module <b>4</b> will inhibit the subscriber from securing the module with new secret information.
0154If the Transaction money module <b>4</b> has no account numbers or no stored notes <b>11</b>, then the subscriber can secure it by either entering a PIN, which is reverified by the Transaction money module <b>4</b>, or by executing a process in which the Transaction money module <b>4</b> learns the subscriber's biometrics. Once the personalization has been completed, subscriber access to the Transaction money module <b>4</b> requires the successful completion of a sign-on in which the secret information is presented to the Transaction money module <b>4</b>. If the subscriber can sign on to the Transaction money module <b>4</b>, then he/she will be permitted to change PIN's or reintroduce biometrics.
0155In the situation where a subscriber has forgotten his/her PIN or had an incident which has affected his/her biometric reading, then the subscriber may take his/her Transaction money module <b>4</b> to a participating bank. A special transaction may be executed which deposits any electronic notes <b>11</b> in a holding account and destroys the stored bank account numbers. The subscriber can now enter new secret sign-on numbers and characteristics. Any electronic notes <b>11</b> that were removed are returned to the Transaction money module <b>4</b> and the bank account numbers may then be recreated (see Bank Access below).
0156It should be noted that it is not a requirement for a subscriber to identify himself to the system when he takes possession of a Transaction money module <b>4</b>. Though the identity of the money module is contained in every transaction, the holder of a Transaction money module <b>4</b> can be kept secret. If the relationship is revealed then one could trace all of the transactions of a subscriber for the period that the relationship can be corroborated. The only time a subscriber must reveal his identity is if he/she links the money module to a bank account or wishes to redeem money lost.
0157If the subscriber chooses to use the Transaction money module <b>4</b> only for payments and foreign exchange then he/she can keep the relationship secret. As may be appreciated, the subscriber may also acquire a plurality of Transaction money modules <b>4</b> and, for example, link one to bank accounts and maintain the others for anonymous payments. The other Transaction money modules <b>4</b> may be loaded with notes <b>11</b> by exchanges with other money modules or by exchanging for cash notes <b>11</b>.
Replacement of Money Module Value
0158If a Transaction money module <b>4</b> malfunctions or is lost or stolen, it may be possible for the subscriber to recoup the value that was stored in the money module at the time of the incident. This would necessitate that the subscriber relinquish the option of anonymity for that money module, since upon making a claim for the lost money, he/she would have to verify that he/she is the owner of the Transaction money module <b>4</b>.
0159To provide for the replacement of electronic notes <b>11</b>, the subscriber may first link his/her Transaction money module <b>4</b> to a bank account or register ownership of the Transaction money module <b>4</b> with the Certification Agency <b>28</b>. After every transaction involving the transfer of electronic notes <b>11</b>, the subscriber could save the Tran Log, which identifies the counterparty money module identifier and the note identifier, to inexpensive, non-volatile storage which is removable from the host computing environment. This log may be presented by the subscriber when making a claim to replace value. The log may then be compared to reconciliation files to determine the true value of the lost electronic money.
0160An alternative to this procedure would be to refresh the money in the Transaction money module <b>4</b> frequently. This would mean that the notes <b>11</b> in the Transaction money module <b>4</b> would be represented by transaction records at the Issuing Banks <b>1</b>. The existence of the notes <b>11</b> could be verified by scanning these files.
0161A third alternative would allow the system to capture a money module's Tran Log when money is refreshed. These records would be copied and routed to Issuing Banks <b>1</b> for storage on their transaction histories. The existence of the notes <b>11</b> could then be verified as in the previous alternative.
Bank Access
0162According to one aspect of the invention, a customer's Transaction money module <b>4</b> may access his/her accounts for deposits, withdrawals, transfers, etc., at any bank participating in the system and in particular any bank holding an account with the subscriber. For instance, a typical subscriber may have a savings account and a checking account at one of the participating banks, while maintaining a so-called money market account at a separate financial institution, and perhaps a credit-line account at a third participating bank. It is anticipated that a subscriber's Transaction money module <b>4</b> will access his/her accounts for deposits, withdrawals, loan payments and inquiries at any bank or financial institution which can be accessed through the Network <b>25</b>.
0163If a subscriber has multiple accounts, the subscriber's account relationships with a bank will be stored in an account profile in the To Teller <b>34</b> application of the Transaction money module <b>4</b>. The multiple accounts can be linked together by the personal account number ("PAN") associated with the individual subscriber.
0164The account profile may be created either in person, under the control of a bank subscriber service representative at a branch, or over the telephone utilizing a special dialogue. For example, the subscriber may identify himself by his PAN and PIN. He may then enter each account number he wishes to access from his Transaction money module <b>4</b>. The account numbers may be verified in the bank's account reference files. A cross-reference of accounts to Transaction money modules <b>4</b> may be maintained by each bank if they so choose.
0165The composition of an exemplary account profile may be: <ul id="ul0011" list-style="none" compact="compact"><li>(1) Bank Identifier -- one for each bank;</li><li>(2) Account Numbers;</li><li>(3) Account Types -- e.g., checking, savings, credit; and</li><li>(4) Security Server's <b>27</b> signature on the list of accounts.</li></ul>
0166It will be understood that the list of account numbers will be digitally signed by the bank Security Server <b>27</b>. As a further security measure the account profile may be re-signed with an updated public key on a periodic basis. The fundamental access security is provided by the digital signature of the bank's Security Server <b>27</b>.
Banking System (Accounting Architecture)
0167It is a notable feature of the preferred embodiment, that the method of the system can parallel the existing and varying types of accounting methods that exist today. The system of the preferred embodiment follows the various types of accounting methods practiced presently in various banks. However, it is important to note that unlike the present banking system, in the preferred embodiment of the invention, economic value is created on demand. Thus, there is no inventory of cash or checks involved; electronic currency from demand deposits and electronic credit are created on a real-time basis. This elimination of a paper inventory by using an electronic media of exchange requires certain supplements to the commonly practiced accounting techniques to provide the real-time accounting needed.
0168Accordingly, the embodiment of the present invention provides an accounting structure to supplement those used in the present banking systems <b>20</b>. The improved accounting arrangement may be utilized to monitor the electronic money and each bank's obligation when a financial transaction between a Transaction money module <b>4</b> and a Teller money module <b>5</b> occurs, or when a Clearing Bank <b>3</b> performs any clearing processes.
0169When electronic notes <b>11</b> are transferred to or from a Teller money module <b>5</b>, in most cases accounting transactions affecting the records of the banking system <b>20</b> are created. Conversely, transfers between Transaction money modules <b>4</b> do not involve any formal accounting procedures -- they involve only the transfer of electronic notes <b>11</b>.
0170In the system being described, it is anticipated that the following arrangements of accounts are to be utilized for each type of bank, categorized under each monetary unit:
0171At an Issuing Bank <b>1</b>- <ul id="ul0012" list-style="none" compact="compact"><li>(1) Money Issued Account: A liability account which reflects the money issued but not cleared.</li><li>(2) Money Due Account: An asset account reflecting the money deposited to the bank's accounts.</li><li>(3) Deposited at Clearing Bank Account: An asset account reflecting the balance of a clearing account at a Clearing Bank <b>3</b>.</li><li>(4) Correspondent Bank Money Account: A liability account owned by a Correspondent Bank <b>2</b> which is drawn upon by the Correspondent Bank <b>2</b> to dispense electronic money.</li><li>(5) Money In Transit Account: A zero-balance liability account owned by each bank, which is used to temporarily maintain electronic money during a financial transaction.</li><li>(6) Foreign Exchange Account: A zero-balance liability account owned by each bank, which is used to handle multiple currency exchanges.</li></ul>
0172At a Correspondent Bank <b>2</b> - <ul id="ul0013" list-style="none" compact="compact"><li>(1) Deposited at Issuing Bank Account: An asset account reflecting the balance of the Correspondent Bank <b>2</b> account at the Issuing Bank <b>1</b>.</li><li>(2) Money Due Account: An asset account reflecting the money deposited to the bank's accounts.</li><li>(3) Foreign Exchange Account: A zero-balance liability account owned by each bank, which is used to handle multiple currency exchanges.</li><li>(4) Money In Transit Account: A zero-balance liability account owned by each bank, which is used to temporarily maintain electronic money during a financial transaction.</li></ul>
0173At the Clearing Bank <b>3</b>: <ul id="ul0014" list-style="none" compact="compact"><li>(1) Issuing Bank Clearing Account: A liability account to net the amount of money cleared for an Issuing Bank <b>1</b>.</li></ul>
0174The accounts, with their corresponding symbols, are summarized below: <tables id="tabl0001" num="0001"><table frame="all"><tgroup cols="5" colsep="1" rowsep="0"><colspec colnum="1" colname="col1" colwidth="31.50mm" /><colspec colnum="2" colname="col2" colwidth="31.50mm" /><colspec colnum="3" colname="col3" colwidth="31.50mm" /><colspec colnum="4" colname="col4" colwidth="31.50mm" /><colspec colnum="5" colname="col5" colwidth="31.50mm" /><thead valign="top"><row rowsep="1"><entry namest="col1" nameend="col1" align="left">Type of Bank</entry><entry namest="col2" nameend="col2" align="center">Account Name</entry><entry namest="col3" nameend="col3" align="center">Type</entry><entry namest="col4" nameend="col4" align="center">Owner</entry><entry namest="col5" nameend="col5" align="center">Symbol</entry></row></thead><tbody valign="top"><row><entry namest="col1" nameend="col1" morerows="5" align="left">Issuing</entry><entry namest="col2" nameend="col2" align="left">Money Issued</entry><entry namest="col3" nameend="col3" align="left">Liability</entry><entry namest="col4" nameend="col4" align="left">Issuing</entry><entry namest="col5" nameend="col5" align="left">MI</entry></row><row><entry namest="col2" nameend="col2" align="left">Money Due</entry><entry namest="col3" nameend="col3" align="left">Asset</entry><entry namest="col4" nameend="col4" align="left">Issuing</entry><entry namest="col5" nameend="col5" align="left">MD</entry></row><row><entry namest="col2" nameend="col2" align="left">Deposited at Clearing Bank</entry><entry namest="col3" nameend="col3" align="left">Asset</entry><entry namest="col4" nameend="col4" align="left">Issuing</entry><entry namest="col5" nameend="col5" align="left">DC</entry></row><row><entry namest="col2" nameend="col2" align="left">Correspondent Bank Money</entry><entry namest="col3" nameend="col3" align="left">Liability</entry><entry namest="col4" nameend="col4" align="left">Correspondent</entry><entry namest="col5" nameend="col5" align="left">CM</entry></row><row><entry namest="col2" nameend="col2" align="left">Money In Transit</entry><entry namest="col3" nameend="col3" align="left">Liability</entry><entry namest="col4" nameend="col4" align="left">Issuing</entry><entry namest="col5" nameend="col5" align="left">IT</entry></row><row><entry namest="col2" nameend="col2" align="left">Foreign Exchange</entry><entry namest="col3" nameend="col3" align="left">Liability</entry><entry namest="col4" nameend="col4" align="left">Issuing</entry><entry namest="col5" nameend="col5" align="left">FX</entry></row><row><entry namest="col1" nameend="col1" morerows="3" align="left">Correspondent</entry><entry namest="col2" nameend="col2" align="left">Deposited at Issuing Bank</entry><entry namest="col3" nameend="col3" align="left">Asset</entry><entry namest="col4" nameend="col4" align="left">Correspondent</entry><entry namest="col5" nameend="col5" align="left">DI</entry></row><row><entry namest="col2" nameend="col2" align="left">Money Due</entry><entry namest="col3" nameend="col3" align="left">Asset</entry><entry namest="col4" nameend="col4" align="left">Correspondent</entry><entry namest="col5" nameend="col5" align="left">MD</entry></row><row><entry namest="col2" nameend="col2" align="left">Money In Transit</entry><entry namest="col3" nameend="col3" align="left">Liability</entry><entry namest="col4" nameend="col4" align="left">Correspondent</entry><entry namest="col5" nameend="col5" align="left">IT</entry></row><row><entry namest="col2" nameend="col2" align="left">Foreign Exchange</entry><entry namest="col3" nameend="col3" align="left">Liability</entry><entry namest="col4" nameend="col4" align="left">Correspondent</entry><entry namest="col5" nameend="col5" align="left">FX</entry></row><row rowsep="1"><entry namest="col1" nameend="col1" align="left">Clearing</entry><entry namest="col2" nameend="col2" align="left">Clearing Account</entry><entry namest="col3" nameend="col3" align="left">Liability</entry><entry namest="col4" nameend="col4" align="left">Issuing</entry><entry namest="col5" nameend="col5" align="left">CA</entry></row></tbody></tgroup></table></tables>
0175Transaction processing, for a transaction such as a request for a withdrawal from savings, selects accounting processes so that the appropriate accounts may be credited and debited accordingly. It is anticipated that the accounting processes will be using software programs and methods that are well known in the art and presently available; inasmuch as any of the programs and methods currently practiced and known for providing the foregoing accounting procedures would be suitable for use in the invention. To better understand the accounting processes of the invention, several examples of typical transactions and their associated accounting steps will be described.
0176Accordingly, Figures 11-24 illustrate the accounting transactions for deposits, withdrawals, foreign exchanges, receipt of cleared money, electronic money/cash exchanges, and note <b>11</b> updates. Figures 11-14 and 19-22 also illustrate the accounting flows when a Transaction money module 4 contains notes <b>11</b> that are not involved in the particular transaction that is occurring. The notes <b>11</b> that are not part of the transaction are replaced with updated notes as discussed in the security procedures described above. For example, when a subscriber deposits less electronic money than is stored in his/her Transaction Money Module <b>4</b>, leaving a balance, the electronic notes <b>11</b> representing the balance are then replaced with electronic notes <b>11</b> containing the most up-to-date certificates. This latter case is indicated in the parenthetical on Figures 20-23 and 28-31.
0177In an example of the accounting arrangements according to the invention (illustrated by Figure 11), if a subscriber were to deposit $50.00 out of $100.00 of electronic money contained in his/her Transaction money module <b>4</b> at a Correspondent Bank's Teller money module <b>5</b> (Step 1), the entire $100 of electronic money would be extracted of which $50.00 would first be credited to his/her customer account (herein denoted by "A"), the remaining $50.00 would be credited to the Correspondent Bank's In-Transit account, and $100 would be debited to the Money Due account at the Correspondent Bank <b>2</b>. See "IT" and "MD" in Figure 11.
0178After the $100 of electronic notes <b>11</b> is removed, the notes <b>11</b> are deposited from the Correspondent Teller money module <b>5</b> to the Teller money module <b>5</b> of an Issuing Bank <b>1</b> (Step 2). In accomplishing this transfer, the Money Due account at the Correspondent Bank <b>2</b> is credited $100 while its Deposited at Issuing Bank account is debited by $100; the Issuing Bank <b>1</b> credits its Correspondent Bank Money account by $100 and debits its Money Due account by $100.
0179In Step 3, the updated notes <b>11</b> are requested. Thus, the Correspondent Bank <b>2</b> requests from the Issuing Bank <b>1</b> the withdrawal of $50 of electronic money containing the most recent certificates from its Money Generator module <b>6</b>. To support this request, $50 is credited to the Deposited at Issuing Bank account and $50 is debited from its Money In Transit account. The Issuing Bank <b>1</b> then debits $50 from its Correspondent Bank Money account and credits $50 to its Money Issued account.
0180To complete the transaction, the $50 is then transferred from the Money Generator module <b>6</b> to the Correspondent Bank's <b>2</b> Teller money module <b>5</b> through the Issuing Bank's <b>1</b> Teller money module <b>5</b>, and finally to the Transaction money module <b>4</b> (Steps 4-6). The net result of all of these transactions is that $50 remains deposited in the subscriber's account and $50 of newly issued electronic notes <b>11</b> are now stored in the Transaction money module <b>4</b> of the subscriber.
0181Alternatively, if a subscriber begins with $50 in his/her Transaction money module <b>4</b> and deposits all of it, the customer account would be credited $50 and the Money Due account would be debited by $50 (Step 1 of Figure 11; parenthetical entries).
0182When there are only $50 of electronic notes <b>11</b> that are removed, the Correspondent Bank <b>2</b> credits the Money Due account $50 and the Deposited at Issuing Bank account is debited $50 (Step 2, parenthetical entries). This money is then deposited at the Issuing Bank <b>1</b> for later clearing, wherein the Correspondent Bank Money account is credited by $50 and the Money Due account is debited by $50. Because no updated electronic notes <b>11</b> need be returned in this situation, the deposit and its corresponding accounting is completed at Step 2.
0183The accounting processes of an electronic money deposit at an Issuing Bank <b>1</b> instead of a Correspondent Bank involve fewer operational steps, which are illustrated in Figure 12. Using the same dollar amounts as in the previous exemplary transaction, when $50 of $100 in electronic money stored in the Transaction money module <b>4</b> are deposited directly to an Issuing Teller money module (Step 1), $50 would be credited to the customers account (A). Fifty dollars would simultaneously be credited to the Money In Transit account, and $100 would be debited to the Money Due account at the Issuing Bank <b>1</b>.
0184Since the entire $100 stored in the Transaction money module <b>4</b> is removed and transferred to the Issuing Bank's Teller money module <b>5</b>, it is necessary to return $50 of updated notes to the Transaction money module <b>4</b>. Accordingly, as shown in Step 2 the Teller money module <b>5</b> requests $50 from its Money Generator module <b>6</b>, debiting its Money In Transit account by $50 and crediting its Money Issued account by $50.
0185In response, $50 is created by the Money Generator module <b>6</b> and transferred to the Teller money module <b>5</b>, which in turn transfers this electronic money to the Transaction money module <b>4</b> (Step 3-4).
0186When only $50 is stored in the Transaction money module <b>4</b> and all of it is deposited, the customer's account (A) is credited $50, the Money Due account is credited $50, and that is the end of it. See parenthetical entries in Step 2 in Figure 12.
0187In the case of a withdrawal from a Correspondent Bank (see Figure 13), a withdrawal request of $100 by a subscriber using a Transaction money module <b>4</b> at a Correspondent Bank <b>2</b> will cause the subscriber's account (A) to be debited by $100 and the Correspondent Bank's <b>2</b> Money In Transit account to be credited by $100 (Step 1). The request for the $100 withdrawal is forwarded to the Issuing Bank <b>1</b> from the Correspondent Bank <b>2</b>, and the Correspondent Bank's Deposited at Issuing Bank account is credited by $100 while its Money In Transit account is debited by $100 (Step 3).
0188Next, the request for $100 is forwarded by the Issuing Bank's <b>1</b> Teller money module <b>5</b> to the Money Generator module <b>6</b>. Accordingly, the Correspondent Bank Money account gets a $100 debit while the Money Issued account gets a $100 credit (Step 4).
0189The Money Generator module <b>6</b> then creates the $100 of electronic notes <b>11</b>, and transfers it to the Transaction money module <b>4</b> via the Issuing Bank's <b>1</b> Teller money module <b>5</b> and the Correspondent Bank's <b>2</b> Teller money module <b>5</b> (Steps 5-6).
0190When, e.g., the subscriber makes the $100 withdrawal request with a Transaction Money Module <b>4</b> that contains $50 of electronic notes <b>11</b>, the notes <b>11</b> are removed and now the Money Due account is debited $50, the subscriber's account is still debited $100, and the Money In Transit account is credited $150 (parenthetical entries, Step 1).
0191The $50 is then deposited to an Issuing Bank <b>1</b>, causing the Money Due account to be credited $50 and the Deposited at Issuing Bank account to be debited by $50. At the Issuing Bank <b>1</b>, the Correspondent Bank Money account is credited $50 while the Money Due account is debited $50 (Step 2, parenthetical entries).
0192Because $50 of notes <b>11</b> have been removed, the withdrawal request in Step 3 must be for $150. This request causes the Deposited at Issuing Bank account to be credited by $150 and the Money In Transit account to be debited by $150 (Step 3 parenthetical entries).
0193At the Issuing Bank, $150 is requested from the Money Generator Module <b>6</b> and the Correspondent Bank Money account gets a $150 debit while the Money Issued account gets a $150 credit (Step 4 parenthetical entries). As above, the money generated by the Money Generator Module <b>6</b> ($150) gets conveyed to the Transaction money module <b>4</b> via the Issuing Bank <b>1</b> and Correspondent Bank <b>2</b> Teller money modules <b>5</b> (Steps 5-6, parenthetical entries).
0194A withdrawal from an Issuing Bank <b>1</b> involves fewer accounting procedures. Referring now to Figure 14, a withdrawal request by a Transaction money module <b>4</b> from an Issuing Bank <b>1</b>, Step 1 will cause the Issuing Bank <b>1</b> Teller money module <b>5</b> to debit the subscriber's account (A) by $100 and credit its Money Issued account by $100 (Step 1-2).
0195A request for an updated $100 is then made by the Issuing Bank's <b>1</b> Teller money module <b>5</b> to the Money Generator module <b>6</b>, which upon its creation will return $100 to the Issuing Bank's Teller money module <b>5</b> (Step 3). In completing the transaction, the Issuing Bank's <b>1</b> Teller money module <b>5</b> simply transfers this $100 containing the most recent certificate to the Transaction money module <b>4</b> (Step 4).
0196Alternatively, when the Transaction money module contains $50 at the time of the $100 withdrawal, (parenthetical entries) the $50 will be removed, the Issuing Bank's Money In Transit account will be credited $50 and the Money Due account will be debited $50 (Step 1).
0197The Issuing Bank <b>1</b> must now request $150 from the Money Generator module <b>6</b>. Naturally, the customer's account is debited $100. The Money Issued account is credited by $150 when the new notes <b>11</b> are created, and the Money In Transit account is debited $50 (Step 2). From there, $150 is returned to the Transaction money module <b>4</b> via the Issuing Bank's <b>1</b> Teller money module <b>5</b> (Steps 3-4).
0198Figure 15 illustrates the case of a foreign exchange with an Issuing Bank <b>1</b>. In this example, a subscriber wishes to exchange $100 of electronic money stored in his/her Transaction money module <b>4</b> for £60 of British currency. The deposit at the Issuing Bank's <b>1</b> Teller money module <b>5</b> will cause the Issuing Bank's <b>1</b> Foreign Exchange account to be credited by £60, while its Money Due account would be debited by $100 (Step 1). Here, the $100 is transferred from the Transaction money module <b>4</b> to the Teller money module <b>5</b>, which then requests that an electronic note <b>11</b> representing £60 be created by the Money Generator module <b>6</b> (Step 2).
0199At the Issuing Bank <b>1</b>, the foreign exchange account is now debited by £60 while the Money Issued account is credited by £60. The £60 electronic note <b>11</b> created by the Money Generator module <b>6</b> is transferred to the Teller money module <b>5</b>, which now stores both the $100 and the £60 (Step 3). The £60 is then transferred from the Teller money module <b>5</b> to the Transaction money module <b>4</b> resulting in a net balance of £60 in the Transaction money module <b>4</b> and $100 remaining in the Teller money module <b>5</b>, completing the transfer (Step 4).
0200The accounting procedures for a foreign exchange of $100 for £60 at a Correspondent Bank <b>2</b> are shown in Fig. 16. The Transaction money module <b>4</b>, in this example, requests that its $100 be used to "purchase" £60 from the Correspondent Bank's Teller money module <b>5</b>, which causes the Correspondent Bank's Foreign Exchange account to be credited by £60 while its Money Due account is debited by $100 (Step 1). The $100 stored in the Transaction money module <b>4</b> is transferred to the Correspondent Bank's <b>2</b> Teller money module <b>5</b>, which sends a request to the Issuing Bank's <b>1</b> Teller money module <b>5</b> to withdraw £60, and debits its Foreign Exchange account by £60 and credits its Deposited at Issuing Bank account by £60 (Step 2).
0201The corresponding account transaction at the Issuing Bank <b>1</b> debits the Correspondent Bank Money account by £60 and credits the Money Issued account by £60 (Step 3). The Issuing Bank's Teller money module <b>5</b> then requests that the Money Generator module <b>6</b> create £60 and transfer it to the Issuing Bank's Teller money module <b>5</b>, which in turn transfers it to the Correspondent Bank's <b>2</b> Teller money module <b>5</b> (Steps 4-5). From there, the £60 note <b>11</b> is transferred to the Transaction money module <b>4</b>, leaving it with a balance of £60 while the Correspondent Bank's <b>2</b> Teller money module <b>5</b> finishes with a balance of $100 (Step 6).
0202The accounting transactions for a withdrawal or deposit of credit notes <b>11</b> also involve several accounting operations, as shown in Figure 17. When a subscriber wishes to withdraw money from his/her credit line (Step 1), the proper credit note <b>11</b> is simply transferred from the Money Generator module <b>6</b> to the Transaction money module <b>4</b>, reducing the customer's available credit line by an equal amount to the amount transferred (Steps 2-4).
0203Alternatively, when credit notes <b>11</b> are deposited by a subscriber's Transaction money module <b>4</b>, the subscriber's account is increased by the amount deposited, and the Money Due account is debited by an equal amount (Step 1).
0204The accounting operations involving the Issuing Bank's <b>1</b> receipt of cleared electronic money will now be described. Referring to Figure 18, in this example $100 of electronic money and $100 of credit notes <b>11</b> have been cleared by the Clearing Bank <b>3</b> to settle the balances among several Issuing Banks <b>1</b>. The $100 of electronic money and the $100 of credit notes are transferred to the proper Issuing Bank <b>1</b> (Step 1). Additionally, $50 of electronic notes <b>11</b> that it has issued are also deposited at the Issuing Bank <b>1</b>. Consequently, the Issuing Bank <b>1</b> will debit the subscriber's account A by $100, debit the Issuing Bank's Money Issued account by $150, credit the Money Due Account by $50 and credit the Issuing Bank's Deposited at Clearing Bank account by $200 to complete the transaction.
0205Turning now to Fig. 19, an accounting example of an exchange of cash for electronic notes <b>11</b> at an Issuing Bank <b>1</b> is shown. In this example, the subscriber wishes to exchange $50 of cash for $50 of electronic notes <b>11</b> to add to the $100 of electronic notes <b>11</b> already stored in his/her Transaction money module <b>4</b>.
0206In the first transaction, the $50 of cash is deposited at the Issuing Bank <b>1</b> which causes the Money In Transit account to be credited by $50, while the cash account is debited by $50 (Step 1).
0207Next, the $100 of electronic notes <b>11</b> in the Transaction money module <b>4</b> is removed, resulting in the Money In Transit account being credited by $100, while the Money Due account is debited by $100 (Step 2).
0208The Teller money module <b>5</b> will now request $150 of electronic notes <b>11</b> from the Money Generator module <b>6</b> to return $150 of electronic notes <b>11</b> to the subscriber (Step 3). Accordingly, the Money In Transit account is debited by $150 while the Money Issued account is credited by $150.
0209The newly generated $150 of electronic notes <b>11</b> is then transferred from the Money Generator module <b>6</b> to the Teller money module <b>5</b>, who in turn transfers the $150 to the subscriber's Transaction money module <b>4</b> (Step 4-5). The completed transaction leaves the subscriber with $150 of electronic notes <b>11</b> and the Issuing Bank's Cash account containing a $50 balance.
0210Also shown parenthetically in Fig. 19 is the case when the subscriber exchanges $50 of cash for electronic notes <b>11</b> when there is a zero balance in his/her Transaction money module <b>4</b>. In Step 1, the $50 of cash is deposited at the Issuing Bank <b>1</b> which causes the Money In Transit account to be credited by $50, while the cash account is debited by $50. Since no notes <b>11</b> are removed, no accounting is performed in Step 2.
0211In Step 3, only $50 is requested from the Money Generator module <b>6</b>, and the Money In Transit account is debited by $50 while the Money Issued account is credited by $50. The same transfer between money modules occurs as in Steps 4-5 of Fig. 19 described above, using only the $50 that was requested. This would leave the subscriber with $50 of electronic notes <b>11</b> in lieu of his original $50 of paper money.
0212In Fig. 20, an exchange of cash for electronic notes <b>11</b> at a Correspondent Bank <b>2</b> is shown. This example uses the same parameters as in Figure 19, namely, the subscriber has $50 of cash and $100 of electronic notes <b>11</b> in his Transaction money module <b>4</b>.
0213When the $50 in cash is deposited to the Correspondent Bank <b>2</b>, its Money In Transit account is credited $50 while its Cash account is debited $50 (Step 1). The $100 of electronic notes <b>11</b> is then transferred from the Transaction money module <b>4</b> to the Correspondent Bank <b>2</b> which credits its Money In Transit account by $100 and debits its Money Due account by $100 (Step 2).
0214From there, the $100 of electronic notes <b>11</b> is deposited at the Issuing Bank <b>1</b>, wherein its Money Due account is debited by $100 while its Correspondent Bank Money account is credited by $100 (Step 3). At the Correspondent Bank <b>2</b>, the Deposited at Issuing Bank account is debited by $100 while the Money Due account is credited by $100.
0215A withdrawal request is then made by the Correspondent Bank <b>2</b> for $150 from the Issuing Bank <b>1</b> (Step 4). This request results in the Correspondent Bank <b>2</b> debiting its Money In Transit account by $150 and crediting its Deposited at Issuing Bank account by $150.
0216Correspondingly, the Issuing Bank <b>1</b> Teller money module <b>5</b> requests $150 of notes <b>11</b> from the Money Generator Module <b>6</b>, debits its Correspondent Bank Money account by $150 and credits its Money Issued account by $150 (Step 5).
0217Finally, the $150 of electronic notes <b>11</b> is transferred from the Money Generator module <b>6</b> to the Issuing Bank's <b>1</b> Teller money module <b>5</b> which transfers it to the Transaction money module <b>4</b> after passing through the Correspondent Bank's <b>2</b> Teller money module <b>5</b> (Steps 6-8).
0218Alternatively, a subscriber having only $50 of cash and no notes <b>11</b> in his/her Transaction money module <b>4</b> is also shown in Fig. 20. As in the first case, the $50 in cash is deposited to the Correspondent Bank <b>2</b>, its Money In Transit account is credited $50 while its Cash account is debited $50 (Step 1).
0219A $50 withdrawal request is then made to the Issuing Bank <b>1</b>, and the Money In Transit account is debited by $50 while the Deposited at Issuing Bank account is credited $50 (Step 4, parenthetical entry). Thereafter, $50 is requested from the Money Generator Module <b>6</b>, the Correspondent Bank Money account is debited $50 and the money issued account is credited $50 in Step 5 (parenthetical entry). Here, $50 in electronic notes <b>11</b> are transferred through the same money module path as Steps 6-8 above, to reach the Transaction money module <b>4</b>.
0220Figure 21 illustrates the exchange of electronic notes <b>11</b> for cash at an Issuing Bank <b>1</b>. Here the subscriber has $100 of electronic notes <b>11</b> stored in his/her Transaction money module <b>4</b> and wishes to exchange $50 of the electronic notes <b>11</b> for $50 of paper cash.
0221After the Transaction money module <b>4</b> establishes the communications with the Issuing Bank's <b>1</b> Teller money module <b>5</b>, all $100 of the electronic notes <b>11</b> is removed from the Transaction money module <b>4</b> (Step 1). This causes the Money In Transit account to be credited by $100 and the Money Due account (at the Issuing Bank <b>1</b>) to be debited by $100.
0222The Teller money module <b>5</b> then requests $50 of updated electronic notes <b>11</b> from the Money Generator module <b>6</b>, and this transaction requires the Money In Transit account to be debited by $50 and the Money Issued account to be credited by $50 (Step 2). The newly generated $50 of electronic notes <b>11</b> is then transferred to the Transaction money module <b>4</b> through the Teller money module <b>5</b>. The $50 of paper cash is then transferred to the subscriber through a Teller or ATM (Steps 3-5).
0223Also shown in this figure (parenthetically) is the subscriber making the same exchange for cash when only $50 is stored in his/her Transaction Money Module <b>4</b>. At the Issuing Bank, $50 of electronic notes <b>11</b> is removed for which the Money In Transit account is credited $50 and the Money Due account is debited $50. Fifty dollars of paper cash is then returned to the subscriber since he/she only deposited $50 of electronic notes <b>11</b> (Step 5).
0224Completing this transaction, in both cases the Money In Transit account is debited by $50 while the cash account at the Issuing Bank <b>1</b> is credited by $50. The net result is that the subscriber ends up with $50 of paper cash and, in the former case only, $50 of updated electronic notes <b>11</b> in his/her Transaction money module <b>4</b>.
0225The exchange of electronic notes <b>11</b> for paper cash at a Correspondent Bank <b>2</b> is illustrated in Figure 22. As in the example illustrated in Figure 21, although the subscriber is only exchanging $50 of electronic notes <b>11</b>, all $100 of electronic notes <b>11</b> are transferred from the subscriber's Transaction money module <b>4</b> (Step 1).
0226After the notes <b>11</b> are transferred, the Correspondent Bank's <b>2</b> Teller money module <b>5</b> credits its Money In Transit account by $100 and debits its Money Due account by $100. This $100 of electronic notes <b>11</b> is now deposited at an Issuing Bank <b>1</b>, causing the Correspondent Bank <b>2</b> to credit its Money Due account by $100 while debiting its Deposited at Issuing Bank account by $100 (Step 2).
0227At the Issuing Bank <b>1</b>, $100 is credited to the Correspondent Bank Money account while $100 is debited to the Money Due account. The Correspondent Bank <b>2</b> now makes a request to withdraw $50 of electronic notes <b>11</b> from the Issuing Bank <b>1</b> (Step 3). Consequently, the Deposited at Issuing Bank account is credited by $50 while the Money In Transit account at the Correspondent Bank <b>2</b> is debited by $50.
0228Now, the Issuing Bank's <b>1</b> Teller money module <b>5</b> request $50 from the Money Generator module <b>6</b> and debits its Correspondent Bank Money account by $50 while crediting its Money Issued account by $50 (Step 4). The $50 of updated electronic notes <b>11</b> is transferred from the Money Generator module <b>6</b> through Issuing Bank <b>1</b> Teller money module <b>5</b> and the Correspondent Bank <b>2</b> Teller money module <b>5</b>, back to the Transaction money module <b>4</b> in Steps 5-7.
0229Also illustrated is this same example with only $50 stored in the Transaction money module <b>4</b>, which is deposited at a Correspondent Bank <b>2</b>, to be exchanged for paper money. For this deposit, the Money In Transit account is credited $50, and the Money Due account is debited $50 (Step 1). The $50 is then deposited by the Correspondent Bank <b>2</b> to its account at the Issuing Bank <b>1</b>. At the Correspondent Bank <b>2</b>, the Money Due account receives a $50 credit, while the Deposited at Issuing Bank account receives a $50 debit. On the Issuing Bank <b>1</b> side, it credits the Correspondent Bank Money account by $50 and debits the Money Due account by $50 after receiving the $50 deposit (Step 2).
0230In both illustrations, fifty dollars of paper cash is then transferred from the Correspondent Bank <b>2</b> to the subscriber, while the Correspondent Bank <b>2</b> debits its Money In Transit account by $50 and credits its cash account by $50 (Step 8). The subscriber is now left with $50 of paper cash and, in the first illustration, $50 of electronic notes <b>11</b> stored in his/her Transaction money module <b>4</b>.
0231In Figure 23, the accounting process for clearing the electronic money issued by different Issuing Banks is shown. This illustration uses an example in which $100 of electronic notes <b>11</b> issued by Bank B has been deposited at Issuing Bank A, and $150 of electronic notes <b>11</b> issued by Bank A have been deposited at Issuing Bank B.
0232In Step 1, Issuing Bank A transfers the $100 issued by Bank B to the Clearing Bank <b>3</b>. It then credits its Money Due account and $100 and debits its Deposited at Clearing Bank account by the same amount. In Step 2, Issuing Bank B deposits the $150 of Issuing Bank A's money at the Clearing Bank 3. Its Money Due account is credited by $150, while its Deposited at Clearing Bank account is debited $150.
0233In sum, $50 is due to Bank B. Accordingly, $50 gets debited to the Clearing account of Bank A, while $50 gets credited to the Clearing account of Bank B (Step 3).
0234In Figure 24, the accounting transactions corresponding to updating electronic notes <b>11</b> is shown. Here, $100 of electronic notes <b>11</b> are stored in a Transaction money module <b>4</b> and are transferred to an Issuing Bank <b>1</b>, where $100 is credited to the Money In Transit account and $100 is debited to the Money Due account (Step 1).
0235One hundred dollars of electronic notes <b>11</b> are requested from the Money Generator module <b>6</b> causing the Money In Transit account to be debited by $100 while the Money Issued account is credited by $100 (Step 2). With this accomplished, the $100 of electronic notes <b>11</b> is transferred from the Money Generator module <b>6</b> to the Issuing Bank's <b>1</b> Teller money module <b>5</b>, which in turn transfers the money to the subscriber's Transaction money module <b>4</b> (Steps 3-4).
Reconciliation and Clearing Systems
0236Referring to Figure 25, the Transaction Reconciliation System <b>22</b> is shown. It will be understood that the Teller money modules <b>5</b>, the Money Generator modules <b>6</b> and the banking system <b>20</b> may periodically pass transaction records to a Transaction Reconciliation System <b>22</b> maintained at each participating bank. These transactions will be analyzed and matched to determine if there is any faulty process occurring in the system <b>20</b> of the invention.
0237The Transaction Reconciliation System <b>22</b>, which may be embodied in any appropriately sized and suitably programmed general purpose computer but is not so limited, will ensure that all Teller money module <b>5</b> transactions with a financial impact, e.g., deposits, and withdrawals and payments, match the appropriate accounting transactions. Any mismatches could indicate incomplete transactions or possible fraudulent actions.
0238Transactions reflecting the money issued by the Money Generator modules <b>6</b> also should correspond to Teller money module <b>5</b> transactions and have the appropriate accounting transactions recorded. Any mismatched data may indicate incomplete processing or a security breach. Unmatched accounting transactions may be caused by incomplete transactions or an attempt to tamper with the records of the banking system <b>20</b>.
0239In the preferred embodiment, these unmatched transactions may then be transferred to an investigation system <b>12</b> where the causes of the problems may be determined. On-line dialogues may be provided to allow investigators to review the mismatches against transaction records and to determine appropriate actions to correct the situation. Investigators may then take corrective actions by adjusting accounts, deactivating faulty Teller money modules <b>5</b> and Money Generator modules <b>6</b>, and notifying subscribers of the actions.
0240Attention is now directed to Figure 26, which illustrates the clearing process for handling deposit transactions. Correspondent Banks are not involved in this process because subscriber deposits are deposited to their accounts at Issuing Banks <b>1</b> on a real-time basis. At Issuing Banks ,deposits are aggregated by the Clearing System <b>13</b> to consolidate all deposited electronic money (including the deposits from Correspondent Banks) for transmission to the Clearing Bank <b>3</b>.
0241The Clearing Bank <b>3</b> may be implemented in any computer processing facility capable of accommodating the large number of transactions and corresponding amounts of data which the system will typically handle. A high volume mainframe computer, a suitably sized minicomputer system, a number of networked work stations having the necessary data processing capabilities or combination of the foregoing may also be used. As will be appreciated by a person skilled in the art, the particular design of the Clearing Bank <b>3</b> hardware system is not critical to the invention.
0242It is anticipated that Issuing Banks <b>1</b> may clear money in one of several procedures. In one of these procedures, electronic money may be deposited on-line from the Issuing Bank <b>1</b> to the Clearing Bank <b>3</b>. This could be done on-line in a real-time mode when transactions are actually occurring. Alternatively, an Issuing Bank <b>1</b> may record the details of transactions being performed during the course of the day for later batch processing. Interbank processing could occur several times a day.
0243As shown in Figure 26, an Issuing Bank <b>1</b> may periodically transfer its electronic money to a deposit consolidation file (consolidate deposits) which may be processed and transmitted to the Clearing Bank <b>3</b>. Transaction records from this file are also conveyed to the bank's Transaction Reconciliation system <b>22</b> for statistical and housekeeping functions.
0244At the Clearing Bank <b>3</b>, the deposit consolidation files are processed creating a single debit and credit by the monetary unit for each Issuing Bank's <b>1</b> demand account. Of course, the appropriate accounting transactions for these demand accounts are posted during the clearing processes. Any accounts which are overdrawn will be settled via the usual interbank settlement processes that are commonly used in the industry.
0245The processed electronic money that is cleared is sent back to the Money Issued Reconciliation System <b>23</b> of each of the banks that issued it in order to be reconciled and checked for tampering and duplication.
0246Additional statistical and housekeeping functions are implemented in the Money Issued Reconciliation System <b>23</b>, as shown in Figure 27. Issuing Bank's <b>1</b> provide their own Money Issued Reconciliation System <b>23</b>, typically embodied in a general purpose computer but not so limited, for matching the electronic money issued to the electronic money cleared at the Clearing Bank <b>3</b>.
0247As indicated in Figure 27, the electronic money issued and electronic money deposited at Issuing Banks <b>1</b>, and money cleared transactions received from clearing bank <b>3</b> are conveyed to the Money Issued Reconciliation system <b>23</b>. The Money Issued Reconciliation system <b>23</b> generates accounting transactions for the money cleared, and updates a master file of all the bank's money issued. Additionally, the Money Issued Reconciliation system <b>23</b> passes to an investigation subsystem <b>13</b> money which has cleared but which was not issued or was possibly transferred more than once.
0248Any unmatched cases may indicate a potential breach of security. Investigators may then determine whether Money Generator modules <b>6</b> are not working properly or money modules are being tampered with. Money module identifiers of faulty or abused money modules are passed to each bank's Security Servers <b>27</b> for distribution to the other money modules on the bank's local network <b>18</b>. The identifiers are also sent to the Certification Agency <b>28</b> for appropriate distribution throughout the Network <b>25</b>.
0249Separately, the Money Issued master file is accessed by the Money Position system <b>24</b> which creates a file to be transmitted to the Clearing Bank <b>3</b> to create a consolidated money position. It is contemplated that all Issuing Banks <b>1</b> will provide a report reflecting their position at the end of a specified period, typically at the end of every day. The Money Position System <b>24</b> may consolidate these reports to reflect the amount of money issued by the Issuing Banks <b>1</b> for each monetary unit. The reports will reflect the outstanding position of each Issuing Bank <b>1</b> in order to assess the risk of interbank settlement problems.
Operational Sequences
0250Although some aspects of the preferred embodiment may be described in terms of detailed schematic diagrams, the transaction functions are best illustrated by use of process flowcharts. Thus, to facilitate understanding of the operation of the money modules, several examples of transactions are set forth in the flowcharts of Figures 28-50A. Referring to these figures, a detailed description of the system processes and the associated application functions that incorporate the principles of the preferred embodiment of the present invention will now be described.
0251Throughout the descriptions of the flowcharts (except where indicated otherwise), the application functions of the Transaction money module <b>4</b>, whether they are imbedded in a hand-held unit or other type of processing device, are hereinafter designated with the suffix "A", and the Teller money module <b>5</b> applications and its associated bank are hereinafter designated with the suffix "B". In the case where a Correspondent Bank <b>2</b> interacts with an Issuing Bank <b>1</b>, the Issuing or Correspondent Bank <b>1</b> and its associated Teller money module <b>5</b> applications are hereinafter designated with a "C".
0252Additionally, transitions to steps in another figure are indicated by a pentagonal tag having an alphanumeric symbol, and continue on the other figure with a circle having the same alphanumeric symbol therein.
Withdrawal From An Issuing Bank
0253In Figures 28-35A, a process flowchart of a transaction between a Transaction money module <b>4</b> and an Teller money module <b>5</b> is shown. In this process example, it is assumed that the subscriber is desirous of completing a monetary transaction with a participating bank; specifically, a withdrawal of some amount of electronic money from his/her account, to be stored in his/her Transaction money module <b>4</b>.
0254The process flow to set up a withdrawal transaction begins at the top of Figure 28. The first flow bock is a withdrawal set up between a money module A and a bank's Teller money module B <b>5</b>, which is described further in Figure 29. This process begins with money module A performing a sign-on process that is also described in further detail in another figure, specifically Figure 31.
Subscriber Sign-On
0255Referring to the top of Figure 31, the subscriber prompts his/her Transaction money module <b>4</b> to perform a sign-on function (Step 10). The Session Manager <b>31</b> application receives the sign-on message (Step 12) and checks to see if the Transaction money module <b>4</b> has inhibited subscribers from signing on (Step 14).
0256Subscriber sign-on may be inhibited if a user makes several unsuccessful attempts to sign-on to the Transaction money module <b>4</b>. For example, the allowable attempts to sign-on may be limited to three, such that if a person makes more than three consecutive unsuccessful attempts to sign-on to the Transaction money module <b>4</b>, the Session Manager <b>31</b> will prohibit any further sign-on attempts. Additionally, this "lock-out" feature may be maintained for any predetermined time period, such as twenty-four hours, for example. Such an arrangement will provide security from persons who come into possession of the Transaction money module <b>4</b> but who are not properly authorized to access it. It should be noted that while this type of an arrangement is anticipated in the preferred embodiment of the invention, the invention should not be limited as such, since any of the methods known in the industry for providing security from unauthorized persons would be suitable for use herein.
0257When the sign-on is not inhibited, as will typically be the case, To Subscriber <b>33</b> prompts the subscriber to enter his/his sign-on characteristics, such as his/her PIN and biometric identifiers (Step 22). Inputs from the subscriber are forwarded through the Session Manager <b>31</b> to the To Subscriber <b>33</b> application (Steps 24-28), which responds to the characteristics entered and entitles the subscriber to operate the Transaction money module <b>4</b> if the subscriber's identification characteristics are the correct ones when compared to those stored in the memory of the Transaction money module <b>4</b> (Steps 30-32).
0258If the subscriber's identification characteristics do not match the identifiers stored in memory, the To Subscriber <b>33</b> application notifies the subscriber of the invalid sign-on condition (Step 34). From there, the To Subscriber <b>33</b> application checks to see how many times the user has attempted to sign-on (Step 36), and if the predetermined count has not been reached, the Session Manager <b>31</b> is notified (Step 38).
0259The Session Manager <b>31</b> works in conjunction with the Clock/Timer <b>43</b> application to set and to monitor the time that has elapsed between unsuccessful sign-on attempts (Step 40). In one embodiment, too many unsuccessful attempts within the set time period will cause the Session Manager <b>31</b> to prohibit any further sign-on attempts, effectively shutting down the Transaction money module <b>4</b>. The Session Manager <b>31</b> notes that the sign on is terminated in Step 42.
0260Turning back to Step 14 of Figure 31, assuming that the Transaction money module <b>4</b> is inhibited, the Session Manager <b>31</b> checks to see if the predetermined time period has expired (Step 16). If the Transaction money module <b>4</b> is still in the prohibited sign-on mode, the To Subscriber <b>33</b> sends a message to the subscriber that further access to the Transaction money module <b>4</b> is prohibited (Steps 18-20). The Session Manager <b>31</b> notes that the sign-on attempt is terminated, again in step <b>42</b>.
Setup Withdrawal
0261Turning to Figure 29, when a proper sign-on is accomplished, the To Subscriber A <b>33</b> prompts the subscriber for the type of transaction that is desired (Step 43). As mentioned previously, it is anticipated that a subscriber may transact with any one of a multitude of accounts at several different participating banks and financial institutions.
0262After selecting the particular bank and account (Step 44), the Transaction money module <b>4</b> initiates a procedure for communicating with the bank that was selected, by engaging the Network <b>25</b>. The overall program flow now passes to the procedures illustrated by flowcharts in Figure 33. In Figure 33, there is shown the data processing and flow for implementing a sign-on to the Network <b>25</b>.
Network Sign-on
0263The illustrative Network <b>25</b> sign-on method about to be described is in general applicable to any of the money modules <b>4</b>,<b>5</b>,<b>6</b> of the present embodiment. Thus, in this example, "A" denotes any class of money module.
0264After the bank that is to be accessed is selected, the money module initiates communication with the Network <b>25</b> under the control of its Session Manager A <b>31</b> (Step 50). The Network Server <b>26</b> begins by requesting the certificate of the Transaction money module <b>4</b> from Session Manager A <b>31</b> (Step 52-54). The Maintain Security A application <b>37</b> retrieves and sends the certificate to Session Manager A <b>31</b> (Step 56). Session Manager A <b>31</b> sends the certificate to the Network Server <b>26</b> (Step 58), which, upon receipt, routes it to the Security Server <b>27</b> (Step 60).
0265The Security Server <b>27</b> tests the certificate to check its validity (Step 62-64), and if it is not valid for any reason, the Security Server <b>27</b> will signal the Network Server <b>26</b> to deny access (Step 66). The Network Server <b>26</b> may in turn convey an access-denied message to Session Manager A of the Transaction money module <b>4</b> (Step 68-70).
0266If the Session Manager A that receives the denied access message is a Transaction money module <b>4</b>, its To Subscriber application A will inform the subscriber of this condition (Step 74). If it is a Teller money module <b>5</b> or Money Generator Module <b>6</b> that is trying to access the Network <b>25</b>, the To Bank A application <b>47</b> notifies the bank's systems <b>20</b> that its access will not be permitted (Step 76).
0267Assuming the certificate validity check is satisfied, the Security Server <b>27</b> sends an updated list of the bad money modules, and a new list of certificatory keys to the Session Manager A, (Step 78, Fig. 33A). The keys are signed using the last version of the certificatory key. This information is received by Session Manager A and forwarded to the Maintain Security A <b>37</b> application, which will validate the certificatory key list and the bad money module list (Steps 80-82, Fig. 33A).
0268Public Key A <b>44</b> tests the validity of the signature (Step 84) and if the signature is not valid, a message warning of a network security problem is sent by the To Subscriber application A <b>33</b> of a Transaction money module <b>4</b> (Steps 86-90), or alternatively, by the To Bank application A application of a Teller money module <b>5</b>, (Steps 86-88, 92). Advantageously, all money modules will check the validity of a signature received from even the Security Server <b>27</b>. This helps to ensure the integrity of the overall system.
0269In the case of a valid signature, Maintain Security A updates the bad money module list and the certificatory key list. (Step 94). If the certificate is to be recertified or the certificate has expired (Steps 96 and 98), the Maintain Security A generates a new certificate (Step 126 of Figure 33C) while Public Key A generates new keys and signs the certificate using the old public key (Step 128). Session Manager A sends the new certificate to the Security Server <b>27</b> who takes the certificate and tests the validity of the signature (Steps 130-136).
0270Assuming that the signature of the new certificate is not valid at this stage, Steps 66-76, Fig. 33, are repeated so as to terminate the communication link into the Network <b>25</b>.
0271On the other hand, a valid signature, Fig. 33C, will allow the Security Server <b>27</b> to sign the new certificate and send it back to the money module (Step 138). Session Manager A <b>31</b> receives the new certificate, Step 140, Fig. 33D, and forwards it to its Maintain Security application A to again validate the certificate through use of the Public Key application (Steps 142-146). Here, the money modules will repeat the test of the validity of the certificate issued from the Security Server <b>27</b>. For a valid signature, the Session Manager A <b>31</b> sends an acknowledgment to the Security Server <b>27</b> (Step 148) who responds by returning the process to Step 78, Fig. 33A.
0272Conversely, if the Security Server's signature on the new certificate generated by Transaction money module A proves to be invalid, Fig. 33D, Session Manager A will send an invalid certificate message along with the certificate back to the Security Server <b>27</b> (Step 150), which will again attempt to validate the signature on the certificate (Step 152). A valid signature will return the process to Step 66, Fig. 33. Alternatively, an invalid signature will cause the Security Server <b>27</b> to disconnect from the Network <b>25</b> (Step 156, Fig. 33D) and cause the Network Server <b>26</b> to notify the money module of a malfunction (Step 158).
0273The Session Manager A that receives the message (Step 160) will, in the case of a Transaction money module <b>4</b>, get the To Subscriber A <b>33</b> to inquire of the subscriber if they desire to retry the whole process of signing on to the Network <b>25</b> (Steps 164 & 168). In the case of a Teller money module <b>5</b> or a Money Generator Module <b>6</b>, the To Bank application A will inquire if there is a request to retry the Network <b>25</b> sign-on procedure (Steps 166 & 168).
0274No attempts for a retry will, of course, end the communication link into the Network <b>25</b>, and conversely, a request for retry of Network <b>25</b> access will return the procedure back to Step 56, Fig. 33, wherein Maintain Security A will again retrieve the Transaction money module's certificate for the Network Server <b>26</b>.
0275Back at Step 98, Fig. 33A if the certificate does not need to be recertified or has not expired, Session Manager A <b>31</b> will request the date and time (Step 100) from Clock/Timer A (Step 102, Fig. 33B), and forward this data to the Network Server <b>26</b> (Step 104).
0276The Network Server <b>26</b> checks the time and date after receiving it (Step 106) and if it is outside of an acceptable predetermined parameter, the Network Server <b>26</b> will send the new time and date (Step 110) to Clock/Timer A through Session Manager A (Steps 112 & 114). If Clock/Timer A <b>43</b> cannot adjust the date and time to be synchronized with the Network <b>25</b>, the operator of the money module for subscriber or the bank is notified of the clock malfunction (Steps 116-124).
0277In response to the apparent malfunction, the operator may attempt to have the time and date resent from the Network Server <b>26</b>, Step 124, and the procedure reverts back to Step 102 in which it attempts to send the new date and time to the money module. Alternatively, an acceptable date and time check, Step 108 allows the Network Server <b>26</b> and Session Manager A to exchange acknowledgements and note the successful Network <b>25</b> sign-on (Steps 126-128).
Establishing A Session
0278As shown in Figure 29, after the steps of money module sign-on, transaction selection and network sign-on are completed, sessions are established between the money modules. Figure 34 diagrams the flow process for establishing a money-module to money-module session, which, as will be understood by one skilled in the art, will in general be applicable as well to other sessions established between the various types of money modules of the present invention.
0279Referring to the top of Figure 34, the Session Manager A will first check to see if the subscriber has requested connection to a specific destination in the Network <b>25</b>. (Step 190). For instance, where a subscriber is desirous of transacting with his/her account at a specific bank, the Network <b>25</b> will connect the Transaction money module <b>4</b> to the selected bank, Steps 192-198. Conversely, when a subscriber is performing updating functions on the Network <b>25</b>, there is no need to establish a session with any specific bank, and the Network server <b>26</b> may decide where to route the connection, based on Network <b>25</b> traffic.
0280If a specific destination has been selected by the subscriber, Session Manager A conveys the destination information to the Network Server <b>26</b> (Step 194). The Network Server <b>26</b> initiates a communication link to the money module of the selected destination (Step 196) and sends an acknowledgement to Session Manager A <b>31</b>.
0281After receiving the acknowledgement that the destination money module has been contacted (Step 198), the Maintain Security application A will send its certificate to the Maintain Security application B through each application's respective Session Manager (Steps 200-206).
0282It is anticipated that the money modules will exchange certificates to verify that each money module is interacting with another valid money module. To this end (as seen in Fig. 34A), the Public Key application B <b>44</b> tests the certificate of money module A by using the public key algorithm and the public key corresponding to the private key used by money module A, to encrypt and check A's certificate and verify that it is valid (Step 208).
0283If the certificate is found invalid, the session Manager B will note the session is terminated (Step 210). In the case of a Transaction money module <b>4</b>, the To Subscriber B informs the subscriber of the transaction termination (Step 212). Likewise, a Teller money module <b>5</b> of Money Generator Module <b>6</b>, uses the To Bank application B <b>47</b> to notify the bank of the termination, Step 213. It is anticipated that the counterparty money module will then timeout to end the exchange.
0284In Step 214, Fig. 34A, assuming that the certificate of money module A is valid, the Maintain Security application B <b>37</b> checks to see if Transaction money module A is on the list of compromised money modules (Step 215). If money module A is on that list, the process flow returns to Step 210 so that the communications can be terminated.
0285Alternatively, when money module A is not on the list of compromised money modules, then Random Number Generator B <b>46</b> creates a session key (Step 216) and encodes the session key along with money module B's certificate and a verification message, using money module A's public key (Step 218). This encoded message is sent to money module A by Session Manager B <b>31</b> (Step 220).
0286Session Manager A <b>31</b> receives the message from money module B (Step 222), and uses its Public Key <b>44</b> algorithms application to decode the message (Step 224, Fig. 34B), and to verify money module B's certificate (Step 226).
0287If the test determines that money module B's certificate is invalid, the operation branches to an "abort transaction" procedure to terminate the steps taken thus far in establishing a session (Steps 500-524). This procedure may be used, for example, to end the communication session and to functionally shut off money module A, which results in the communication link ending. (Steps 500-524, Figure 32).
Abort Transaction
0288Branching to Figure 32, the functional shut-off of a money module through the abort transaction process will now be described in detail. It will be understood that the following process may be used when any two money modules are abnormally terminating the transactions occurring between them. Accordingly, the money modules will be designated "X" and "Y" to illustrate the generic applicability of the process steps.
0289An abort transaction process initiated by money module X to terminate communications with money module Y begins with Session Manager X <b>31</b> capturing and then reversing or rolling back any programmatic changes that were made to the money module (Step 500), and then noting that the session has been aborted (Step 502).
0290In the case where the money module that is initiating the termination is a Transaction money module <b>4</b>, the To Subscriber application <b>33</b> informs the subscriber of the communication termination (Step 510). Likewise, a Teller money module <b>5</b> informs its To Bank application <b>47</b> of the termination so that any accounting changes may be undone (Step 508). Next, the Session Manager X <b>31</b> of the terminating money module sends an encoded message to the other money module involved (Step 512).
0291Briefly referring to Figure 37, all encrypted messages between modules will be provided by the following steps. The sending money module (here also referred to as "X") uses its Symmetric Key <b>45</b> to encode the message to be sent to the receiving money module (here also referred to as "Y"). (Step 2). Again, it will be appreciated that there are a number of known encryption techniques which may be utilized.
0292The Session Manager X <b>31</b> sends the encoded message to Session Manger Y <b>31</b> which in turn decodes the message using its Symmetric Key Y <b>45</b> (Steps 4-8).
0293Continuing with Figure 32, the Session Manager Y responds to the termination notice sent by also undoing any changes it may have made towards establishing the session, and noting the aborted session (Steps 514-516). If it is a Transaction money module <b>4</b> that is now shutting down, the To Subscriber application <b>33</b> alerts the subscriber of the condition (Step 518 & 524). Correspondingly, in a Teller money module <b>5</b>, the To Bank application <b>47</b> will reverse all accounting transactions that have been undertaken (Steps 518-522).
0294Returning to Figure 34B, assuming that the money module B certificate is valid, in Step 228 Maintain Security A checks to see if money module B is on the list of compromised money modules. If money module B is on the list (Step 230), the session reverts to the abort transaction procedure, Steps 500-524. Thereafter, the communications session is dissolved.
0295More typically, money module B will not be on the list of compromised money modules, and the Clock/Timer A <b>43</b> will retrieve the date and time (Step 232) and send this information to the Maintain Security application A <b>37</b> so that the verification message may be assembled with the date and time (Step 234).
0296Symmetric Key A <b>45</b> then encrypts the verification message with the date and time information, using the random session key provided by money module B (Step 236). Session Manager A <b>31</b> sends this encrypted message (Step 238) to Session Manager B <b>31</b> (Step 240). From there, the Symmetric Key application B <b>45</b> decrypts the message (Step 242) and passes it to the Maintain Security B <b>37</b> for message verification (Step 244, Fig. 34C). An incorrect message will cause the session to be aborted through Steps 500-524, while a correct message will advance the procedure so that Maintain Security B <b>37</b> can compare the time and date with that of money module A (Step 248).
0297Clock/Timer B <b>43</b> will verify that money module A's clock is within a preset amount of deviation from the clock of money module B (Step 250). If the discrepancy between the two clocks is greater than a predetermined amount, the session will be aborted by branching to Steps 500-524.
0298If there is no discrepancy that is greater than the permissible amount, Session Manager B <b>31</b> will note its start of a session (Step 252), and send an acknowledgement to money module A to start the transaction (Step 254). After the encoded message is sent from money module B to Session Manager A <b>31</b> using process steps 2-8, Fig. 37, Session Manager A <b>31</b> acknowledges the message receipt and also notes the start of session (Steps 256-258).
Request Withdrawal
0299After a session is established between the Transaction money module <b>4</b> and Teller money module <b>5</b>, the Transaction money module <b>4</b> makes a withdrawal request from the Teller money module <b>5</b>. See Figure 29. Referring now to Figure 30, a process for requesting a withdrawal will now be described. It should be noted that although the figure denotes the parties as "X" and "Y," in the process steps described below, they are applicable to any money module transacting with a Teller money module <b>5</b>.
0300To begin, the To Teller X <b>34</b> sends a withdrawal request to the Teller money module <b>5</b>, requesting a certain amount of money to be withdrawn from a specific account. In its transmission of the withdrawal request, the account number and the account profile will be transmitted from the requesting money module to the Teller money module <b>5</b> (Step 700). To send this request, the process Steps 2-8 are repeated, in which the message is encrypted using the previously described cryptographic techniques.
Validate Account Number
0301Once the withdrawal request and the account number and profile are transmitted to the Teller money module <b>5</b>, a procedure to validate the account number is initiated (Steps 7041-7055). A flow diagram depicting how an account number is validated is shown in Figure 38.
0302In this process, the Maintain Security application <b>37</b> of the Teller money module <b>5</b> receives the account profile and signature and conveys them to its Public Key application <b>44</b> to verify the profile signature (Steps 7041-7042). The signature is tested using the public key generated and distributed by the Bank's Security Server <b>27</b>. An invalid signature causes the Maintain Security <b>37</b> application to inform the Session Manager that the account profile is invalid (Step 7044), whereby Steps 500-524, Fig. 32, are followed to abort the transaction between the two money modules.
0303If the signature test confirms a valid signature, the procedure advances to the To Bank application <b>47</b> which sends the account number it has received on to the bank's computer systems (Step 7046). An inactive account will cause the Maintain Security application <b>37</b> to inform the Session Manager of the inactive account (Step 7048) and have the transaction aborted following steps 500-524; an account that has not been inactive will allow the Maintain Security application <b>37</b> to check if the account profile needs to be recertified (Steps 7047-7050).
0304If the account profile does need to be recertified, the Maintain Security application <b>37</b> will then send the account profile to the Security Server <b>27</b> (Fig. 38A, Steps 7051-7052), which will recertify the account profile and send it on to the Teller money module <b>5</b> (Step 7053). In response, the Teller money module <b>5</b> sends it to the money module making the withdrawal request (Step 7054).
0305The communication from the Teller money module <b>5</b> to the money module utilizes the previously described routine for sending messages, Steps 2-8. The Maintain Security application <b>37</b> then updates the account profile in the money module and returns an acknowledgement to the Maintain Security application <b>37</b> in the Teller money module <b>5</b> (Step 7055), also using Steps 2-8. The electronic message is received by the Maintain Security application <b>37</b> of the Teller money module <b>5</b>, and acknowledged in Step 7056.
0306With the account information checked, the process returns to Step 704 of Figure 30. The To Bank application <b>47</b> now verifies that there are sufficient funds to support the withdrawal request (Step 704). Sufficient funds will prompt the return of an acknowledgement to a Transaction money module <b>4</b>, utilizing process Steps 2-8 to transmit the acknowledgement to its To Teller <b>34</b> application function (Steps 706-714). In the case of a Teller money module <b>5</b>, no acknowledgement is required.
0307In the case of a Transaction money module <b>4</b>, an insufficient amount of funds will cause the subscriber to be prompted to enter a new amount for the withdrawal (Steps 718-720, Figure 30A). As shown by Step 724, the newly entered amount causes the To Teller application <b>34</b> to send the new request to the To Bank application <b>47</b> (using Steps 2-8) of the Teller money module <b>5</b> to verify if there are sufficient funds to cover the latest requested amount, returning to Step 704 of Fig. 30. If the new request is still greater than the funds on balance at the bank, the Teller money module <b>5</b> will initiate Steps 500-524 to abort the transaction between the two money modules. In the case of a Teller money module <b>5</b>, the transaction is allowed to overdraw the account.
Transfer Notes
0308Referring back to Figure 29, To Teller A <b>34</b> transfers the total of its currency notes <b>11</b> to the Teller money module <b>5</b> (Step 45). If there are no notes <b>11</b> being held in the Transaction money module <b>4</b> at the time the withdrawal request is made, the To Teller A application <b>34</b> sends a message to the Teller money module <b>5</b> that there are no notes <b>11</b> present (Step 47), using process Steps 2-8.
0309Electronic notes <b>11</b> are transferred between money modules using the procedure described below (referring now to Figure 39). The Note Directory application <b>39</b> of the transfer or money module chooses the notes <b>11</b> of proper values for the transfer and updates the current amount of each electronic note after transfer (Step 750), and has the Notes application <b>40</b> create a transfer for each note <b>11</b> (Step 752). The Public Key application <b>44</b> creates signatures for all the notes <b>11</b> (Step 754) and sends the notes <b>11</b> to the Packet Manager application <b>41</b>, for assembling the note <b>11</b> transfers and signatures into a packet to be sent to the requesting money module (Step 756).
0310Steps 2-8 are utilized to transfer the packet of electronic notes <b>11</b> to the Packet Manager application <b>41</b> of the requesting money module for receipt and disassembly (Step 758). The Verifier application <b>42</b> verifies the transfers appended to the certificates, and verifies that the total amount conforms to the notes <b>11</b> that should be sent (Step 760).
0311Any invalid information will cause the transaction between the two money modules to be aborted, using the procedure outlined in Steps 500-524 above (Step 761). Valid notes <b>11</b> will have their expiration dates checked (Step 762) by the Verifier application <b>42</b> when it is a Transaction money module <b>4</b> that has conveyed the notes <b>11</b> (Step 763). Any expired notes <b>11</b> (Step 764) will cause the sessions to be aborted using the procedures outlined in Steps 500-524, Fig. 32.
0312Assuming the notes <b>11</b> have not expired, or in the case where a Teller money module 5 is accepting them, the process flow resumes at Step 765, Fig. 39A. In this Step, the Public Key Y application <b>44</b> verifies the digital signatures. Invalid signatures invoke the transaction abort process of Steps 500-524.
0313Valid electronic notes <b>11</b> are then sent to the Notes application <b>40</b> (Step 768) and the Note Directory <b>39</b> is updated with the new note locations and amount (Step 770).
0314Returning to Figure 28, the To Transaction B <b>49</b> checks if the electronic notes <b>11</b> have been transferred (Step 772), and if notes <b>11</b> have indeed been transferred from a Transaction money module <b>4</b>, accounting transactions are posted to reflect this situation (Step 776; see also Fig. 14, Step 1) by the To Bank application B <b>47</b>. Both in the case when no notes <b>11</b> have been transferred from the money module, and after the latter accounting transactions are posted in Step 776, a session is established between the Teller money module <b>5</b> and the Money Generator module <b>6</b> using the procedure outlined above in Steps 190-258, Figs. 34, 34A-C.
0315As notes <b>11</b> are requested to satisfy the withdrawal, an account posting occurs to reflect the request. The To Bank application B <b>47</b> will post the proper accounting transactions (Step 778, Fig. 28) as also illustrated in Figure 14, Step 2.
Request Notes
0316Directing attention to Figure 40, notes <b>11</b> may be requested between Teller money modules <b>5</b> and Money Generator modules <b>6</b> using the following procedure described below.
0317The To Money Generator application <b>48</b> of the requesting Teller money module <b>5</b> will issue a request for a specific amount of electronic money to be created (Step 780). The request will be sent using the above described Steps 2-8 for encrypted transmission, to the To Teller application <b>34</b> of the Money Generator module <b>6</b> so that the Money Creator application <b>50</b> may be activated (Step 784) to create the electronic notes <b>11</b> (Step 786).
0318After the creation of electronic notes <b>11</b>, they are signed by the Public Key application <b>44</b> of the Money Generator module <b>6</b> (Step 788) and placed in a holder by its Notes application <b>40</b> (Step 790). Finally, the Note Directory <b>39</b> is updated with the information about the newly created electronic notes <b>11</b> (Step 792).
0319The process flow now returns to the procedures shown in Figure 28. The requested notes in the Money Generator module <b>6</b> are transferred to the Teller money module B <b>5</b> using the process Steps 750-770 outlined above for transferring electronic notes <b>11</b>. The notes <b>11</b> are then transferred from the Teller money module B <b>5</b> to the Transaction money module <b>4</b> using these same process Steps 750-770 for transferring electronic notes <b>11</b>.
0320Finally, to successfully complete the withdrawal of electronic notes <b>11</b>, the money modules will "commit" to or finalize the transaction by utilizing the following procedure. Referring now to Figure 41 for a detailed description of this process, the Tran Log Mgr. application <b>36</b> updates its Tran Log to record the transaction that has occurred above (Step 690). When it is a Transaction money module <b>4</b> that is committing to the exchange (Step 691), the To Subscriber application will notify the subscriber that the transaction has been successfully completed (Step 692). Of course, the Session Manager application A <b>31</b> will note the end of session (Step 693), and employ process Steps 2-8 to send the message to the money module it is transacting with.
0321With this end of session notice received, the other money module, in this example a Teller money module <b>5</b>, will use its Tran Log Mgr. application <b>36</b> to update its own Tran Log (Step 694). Assuming, however, the second money module receiving the end of session notice is not a Teller money module <b>5</b>, an additional step of having the To Subscriber application <b>33</b> notify the subscriber of the end of the transaction occurrence (Step 696) will be necessary. Thereafter, the Session Manager <b>31</b> of the second money module in both cases will also make note of the end of the session (Step 698).
0322Directing attention back to Figure 28, the process to commit is initiated first by the Transaction money module <b>4</b> committing its transaction with the Teller money module B <b>5</b> (Steps 690-698). The process steps are also applied to commit the transaction between Teller money module B <b>5</b> and the Money Generator module <b>6</b> (Steps 690-698). That completes the processing for one complete withdrawal of electronic money from an Issuing Bank <b>1</b>.
Withdrawal From A Correspondent Bank
0323A withdrawal from a Correspondent Bank <b>2</b> will now be described, aided by reference to Figure 35. To begin, the previously described Steps 43-48 to set up a withdrawal are undertaken by a Transaction money module A <b>4</b>, in conjunction with an Teller money module B <b>5</b>. Next, Steps 190-258, used to establish a session, also described above, are initiated between Teller money module B <b>5</b> and Teller money module C <b>5</b>. After the sessions have been established, the To Bank application B <b>47</b> will post the accounting transaction corresponding to the withdrawal that is going to subsequently occur (Step 900; see also Fig. 13, Step 1).
0324As previously noted, it is contemplated that whenever a Transaction money module <b>4</b> interacts with a bank, both Issuing <b>1</b> and Correspondent <b>2</b>, all electronic notes <b>11</b> that are stored within the Transaction money module <b>4</b> are removed and replaced with electronic notes <b>11</b> containing the most recent certificate. To perform this operation, To Transaction B <b>49</b> will check to see if there are notes <b>11</b> stored within the Transaction money module <b>4</b> (Steps 902-904). If there are notes <b>11</b>, To Bank B <b>47</b> will post the appropriate accounting transactions (see accounting procedure illustrated in Figure 13; Step 2) (Step 906), and perform a deposit request to the Teller money module C <b>5</b> (associated with an Issuing Bank <b>1</b>) to return the notes <b>11</b> that need to be replaced.
0325For a detailed description for performing a deposit request, attention will be directed to Figure 44. Here, the To Teller application <b>34</b> sends a deposit request message, the amount of the deposit to be sent, the account number and the account profile of the account to which the notes <b>11</b> will be deposited (Step 920). This information is transferred to the Teller money module <b>5</b> using Steps 2-8 for sending messages, and then Steps 7041-7050 (see Figure 38) are performed to validate the account profile and number.
0326In the case where the depositor is a Transaction money module <b>4</b>, the To Transaction application <b>49</b> of the Teller money module <b>5</b> will send an acknowledgement to the Transaction money module <b>4</b> that the transfer of notes <b>11</b> is ready to proceed (Step 924). Alternatively, if it is another Teller money module <b>5</b> that is making the deposit, it is the To Teller application <b>34</b> that issues the acknowledgement to the Teller money module <b>5</b> (Step 926).
0327In either case, the acknowledgement is encrypted and transmitted using the procedure outlined in Steps 2-8, whereby it is received by a To Teller application <b>34</b> of a depositing money module (Step 928).
0328Referring back to Figure 35, once the deposit request is completed, the notes <b>11</b> are transferred from the Teller money module B <b>5</b> to the Teller money module C <b>5</b> using Steps 750-770, Figs. 39, 39A detailed above for transferring notes. Accordingly, To Bank C <b>47</b> posts the proper accounting transactions (see Figure 13, Step 2) to reflect this transfer of notes <b>11</b> (Step 908). In Teller money module C <b>5</b>, the To Teller application <b>34</b> acknowledges the deposit by sending a message back to the To Teller B <b>34</b> application (Steps 910-912), using Steps 2-8. Naturally, the To Bank B <b>47</b> will now post its accounting transactions to reflect the withdrawal request it will make to Teller money module C <b>5</b> (Step 914; see also Fig. 13, Step 3).
0329After all electronic notes <b>11</b> have been removed from the Transaction money module <b>4</b> and the proper accounts have been posted, a withdrawal is requested of a total amount that includes both the amount originally requested to be withdrawn from the subscriber's bank account and the amount that was removed from the Transaction money module <b>4</b> to be replaced with updated electronic notes <b>11</b>.
0330The withdrawal request is performed between Teller money module B <b>5</b> and Teller money module C <b>5</b> using the process Steps 700-724, Figs. 30, 30A, described above. Teller money module C <b>5</b> transacts with Money Generator module <b>6</b> to withdraw new electronic money and in doing so it establishes a session between the two modules using the process Steps 190-258, Figs. 34, 34A-C.
0331The electronic notes <b>11</b> are requested by the Teller money module C <b>5</b> from the Money Generator module <b>6</b> using process Steps 780-792, Fig. 40, and the notes <b>11</b> are transferred from the Money Generator module <b>6</b> to the Teller money module C <b>5</b> using the Steps 750-770, Figs. 39, 39A.
0332The To Bank application C <b>47</b> performs the accounting postings (Step 916; see also Fig. 13, Step 4). After this, the electronic notes <b>11</b> are transferred from Teller money module C <b>5</b> to Teller money module B <b>5</b> using the Steps 750-770; the notes <b>11</b> are than transferred to Transaction money module A <b>4</b> also using Steps 750-770.
0333To finalize the withdrawal from the Correspondent Bank <b>2</b>, each money module must commit to the transaction it has just had with the corresponding money module. Thus, Transaction money module A <b>4</b> commits to Teller money module B <b>5</b> using Steps 690-698, Fig. 41, and thereafter Teller money module B <b>5</b> commits to Teller money module C <b>5</b>. Finally, Teller money module C <b>5</b> commits to the Money Generator module <b>6</b>, using the same process Steps 690-698.
Deposit To An Issuing Bank
0334Referring to Figure 42 in combination with Figure 43, an example of a deposit to an Issuing Bank <b>1</b> will now be described in detail. To start the transaction, a deposit set up must be done which uses the process steps shown in Figure 43.
0335In Step 398 at the top of Figure 43, the subscriber decides to deposit some money to a bank. After performing the sign-on routine for a Transaction money module <b>4</b> (following Steps 10-42, Figs. 31-31A), the To Subscriber A <b>33</b> prompts the subscriber for the transaction desired (Step 400).
0336In this example, the subscriber chooses the deposit transaction, the amount to be deposited, and the bank and account number in which to deposit the electronic money (Step 402). Before any other procedures, Note Directory A <b>39</b> checks to see if the money module contains funds sufficient to support the deposit request (Step 404).
0337Assuming there are insufficient funds for the deposit, To Subscriber A <b>33</b> prompts the subscriber for a new amount (Step 410) and if no new amount is selected, the Session Manager A <b>31</b> informs the subscriber that the transaction must be terminated (Step 414). If the subscriber enters a new amount, Step 412, the process flow returns to Step 404, wherein the Note Directory <b>39</b> application again checks for sufficient funds for the transaction.
0338Assuming there are adequate funds within the money module, the process flow advances to the Network <b>25</b> sign-on procedures outline in Steps 50-168, Figs. 33-33A. A successful Network <b>25</b> sign-on then advances the process flow to Steps 190-258, for establishing a session between the Transaction money module A <b>4</b> and Teller money module B <b>5</b>.
0339Once the session is established between the two money modules, the deposit request steps outlined in procedures 920-928 are followed conveying the request from Transaction money module A <b>4</b> to the Teller money module B <b>5</b>. The To Teller A <b>34</b> transfers all of the electronic notes <b>11</b> stored within the money module to the Teller money module B <b>5</b> (Step 408) using the Steps 750-770 described above for transferring electronic notes <b>11</b> between two money modules.
0340Continuing with Figure 42, the To Bank B <b>47</b> posts the accounting transactions for the notes deposited (Step 418, see Fig. 12, Step 1). In Teller money module B <b>5</b>, the To Transaction application <b>49</b> checks to see if the amount deposited is less than the total notes <b>11</b> that were stored in module A and then transferred to the Teller money module <b>5</b> (Step 420). If the deposit is less than the total amount of transferred notes <b>11</b>, updated notes <b>11</b> must be generated and sent back to the Transaction money module <b>4</b>.
0341When all the notes that are contained in the Transaction money module <b>4</b> are deposited, i.e., the amount to be deposited is not less than the total amount of electronic notes <b>11</b>, the To Transaction B <b>49</b> will send an acknowledgement to the Transaction money module <b>4</b> (Step 428) using the Steps 2-8 for sending messages between money modules. The To Teller A <b>34</b> receives the acknowledgement (Step 430) and initiates the Steps 690-698 to commit the deposit transaction between the two money modules.
0342When the electronic notes <b>11</b> removed exceed the desired deposit amount, new updated notes <b>11</b> must be returned to the Transaction money module <b>4</b>. To perform this, the To Bank application B <b>47</b> of the Teller money module B <b>5</b> posts the proper accounting transactions (Step 424; Fig. 12, Step 2). Thereafter, Teller money module B <b>5</b> establishes a session with the Money Generator module <b>6</b> using process Steps 190-258, and requests electronic notes <b>11</b> from the Money Generator module <b>6</b> in the amount that should be returned to the Transaction money module <b>4</b>, by performing Steps 780-792.
0343The electronic notes <b>11</b> are created by the Money Generator module <b>6</b> and transferred to the Teller money module B <b>5</b> using Steps 750-770. With the electronic notes <b>11</b> in the possession of the Teller money module B <b>5</b>, they are transferred to the Transaction money module A <b>4</b> using Steps 750-770.
0344After Transaction money module A <b>4</b> receives the electronic notes <b>11</b>, it must finalize the transaction by committing Teller money module B <b>5</b> to Transaction money module A <b>4</b> using Steps 690-698. Likewise, Teller money module B <b>5</b> must commit to the Money Generator module <b>6</b> using the same Steps 690-698.
Deposit To A Correspondent Bank
0345Figure 45 illustrates the process flow for a deposit at a Correspondent Bank. In depositing to a Correspondent Bank <b>2</b>, the deposit set up described in Steps 398 through 414 are repeated in the first stage of the transaction. From there, the To Transaction B <b>49</b> tests to see if the deposit is less than the total amount of electronic notes <b>11</b> that have been withdrawn in the deposit set up procedures that were just processed (Step 440).
0346In the case where all the electronic notes <b>11</b> stored in the Transaction money module <b>4</b> are equal to the amount of notes <b>11</b> to be deposited, then To Transaction B <b>49</b> sends a deposit acknowledgement back to the Transaction money module <b>4</b> (Step 444), using Steps 2-8 to send the message from the Teller money module B <b>5</b> to Transaction money module A <b>4</b>.
0347On the Transaction money module <b>4</b> side, the To Teller <b>34</b> application receives the acknowledgement (Step 446) and uses Steps 690-698 to commit the transaction with Teller money module B <b>5</b>. The Transaction money module <b>4</b> is now finished and removed from the process. The finalization of the deposit provides for the account posting transactions to be made by the To Bank application <b>47</b> (Step 448). See Figure 11, Step 1 for the accounting transactions.
0348A session is now established between the Teller money module B <b>5</b> and Teller money module C <b>5</b> using Steps 190-258.
0349Teller money module B <b>5</b> issues a request to make a deposit to the Teller money module C <b>5</b> by using process Steps 780-792. The To Bank B <b>47</b> then posts the accounting transactions (Step 450; see also Fig. 11, Step 2).
0350Notes <b>11</b> are now transferred from the Correspondent Bank B <b>2</b> to the Issuing Bank C <b>1</b> using Steps 750-770; the Issuing Bank C <b>1</b> posts the corresponding accounting transactions (Step 452; see also Fig. 11, Step 2). The To Teller C <b>34</b> responds by sending the deposit acknowledgement (Step 454) using Steps 2-8, to To Teller application <b>34</b> of Teller money module B <b>5</b> (Fig. 45A, Step 456).
0351Here again, the deposit is checked to see if it is less than the amount of electronic notes <b>11</b> that have been removed earlier, and when it is not, the withdrawal is completed with the process Steps 690-698, Fig. 41, to commit Teller money module B <b>5</b> to Teller money module C <b>5</b>.
0352A deposit request that is less than the amount of notes <b>11</b> that are withdrawn requires account updating (Step 460; see also Fig. 11, Step 3), and new notes <b>11</b> to replace the additional notes <b>11</b> that were taken. Accordingly, a withdrawal request following the process Steps of 700-724 from Teller money module B <b>5</b> to Teller money module C <b>5</b> is made to provide these new electronic notes <b>11</b>.
0353Teller money module C <b>5</b> must first establish a session with the Money Generator module <b>6</b>, using the process Steps 190-258. The new electronic notes <b>11</b> are requested by the Teller money module C <b>5</b> from the Money Generator module <b>6</b> following process Steps 780-792, which are then transferred to the Teller money module C <b>5</b> using Steps 750-770 to transfer notes <b>11</b> between money modules.
0354This transfer of electronic notes <b>11</b> to the Teller money module C <b>5</b> requires that accounting transactions be posted by the To Bank application C <b>47</b> (Step 462, Fig. 45B; see also Fig. 11, Step 3).
0355From there, the notes <b>11</b> are transferred from the Issuing Bank's <b>1</b> Teller money module C <b>5</b> to the Correspondent Bank's <b>2</b> Teller money module B <b>5</b> and to the Transaction money module <b>4</b> by using Steps 750-770 for transferring notes <b>11</b>. Thereafter, each money module must commit to the money module with which it has established a session. Thus, Transaction money module A <b>4</b> commits to Teller money module B <b>5</b>, Teller money module B <b>5</b> subsequently commits to Teller money module C <b>5</b>, which then commits to the Money Generator module <b>6</b>. All three of these commitment transactions use process Steps 690-698 above.
Subscriber To Subscriber Payment
0356Figure 36 illustrates the process flow for a payment transaction from one Transaction money module <b>4</b> to another. In this example of a preferred embodiment, Alice (or a hypothetical payor corporation, is denoted "A" in Figure 36) will agree to pay Bob (or a hypothetical payee corporation, is denoted "B" in Figure 36) a specific amount of electronic money (Step 800). Both Alice and Bob sign on to their respective Transaction money modules <b>4</b> using the process Steps 10-42 described above. Through the To Subscriber A <b>33</b> application, Alice directs her Transaction money module <b>4</b> to make a payment (Steps 806 & 810), while Bob operates his Transaction money module <b>4</b> such that the To Subscriber B <b>33</b> application will issue an entitlement to receive payment (Steps 808 & 812).
0357In Steps 814 & 816 the Session Managers <b>31</b> of both Alice's Transaction money module <b>4</b> and Bob's Transaction money module <b>4</b> established communications. From there a session is established, as described in Steps 190-258 above for transacting between any two money modules.
0358With a session established, To Subscriber A <b>33</b> prompts the subscriber to enter the amount of payment that she desires to transfer (Step 818), which is displayed to the subscriber.
0359Alice enters the amount that she wishes to transfer to Bob. Pay/Exchange application A <b>35</b> receives the amount entered (Fig. 36, Step 820). The amount entered by type (currency or credit) is now compared by Note Directory A <b>39</b> to the balance of the value of the electronic money stored in the Transaction money module <b>4</b>, to see if there are sufficient funds available to permit the transaction to proceed (Step 822).
0360If there are insufficient funds, To Subscriber A <b>33</b> sends the subscriber a notice that there are not sufficient funds to cover the transaction desired (Steps 824-826), and prompts the subscriber again for a new amount of payment (Step 827). If the subscriber prefers not to enter a new amount, the abort transaction process Steps 500-524 are activated to terminate the communications link between the two Transaction money modules <b>4</b>. On the other hand, a newly entered amount will return the process to Step 820, to check for sufficient funds again.
0361When there are sufficient funds stored in Transaction money module A <b>4</b> to process the transfer, Pay/Exchange A <b>35</b> sends a message disclosing the amount of the transfer to Bob's Transaction money module <b>4</b> (Step 828), using the process disclosed in Steps 2-8. See Fig. 36A. From there, To Subscriber B <b>33</b> prompts the owner to verify that the amount to be transferred will be accepted by him (Step 830). Bob can then decide whether to accept or reject the amount to be transferred (Step 832).
0362If Bob responds in the negative, then Pay/Exchange B <b>35</b> will send a message back to Transaction money module A <b>4</b> using Steps 2-8, that the amount to be transferred is incorrect (Step 834); the process again returns to Step 826, Fig. 36, to prompt Alice for a new amount to be entered.
0363When Bob responds in the affirmative in Step 832, Pay/ Exchange B <b>35</b> will send an acknowledgement to Transaction money module A <b>4</b> using Steps 2-8 (Step 835). Back in Transaction money module A <b>4</b>, the message will be conveyed to Pay/Exchange A <b>35</b> to receive the acknowledgment sent by Transaction money module B <b>4</b> (Step 836).
0364With this acknowledgement received, Pay/Exchange A <b>35</b> will send the amount desired to be transferred to the Money Holder <b>38</b> (Step 838) so that the electronic notes <b>11</b> may be transferred using Steps 750-770. With the transfer completed, the two Transaction money modules <b>4</b> must commit to the transfer using Step 690-698 described above. The communication link between the two transaction modules may now be terminated.
Subscriber to Subscriber Foreign Exchange
0365Referring to Figure 46, the process flow for an exchange of foreign currencies between two Transaction money modules <b>4</b> will now be illustrated. In this example Alice (or a hypothetical corporation, denoted "A" in Figures 46-46A) agrees to exchange dollars for pounds with Bob (or a hypothetical corporation, denoted "B" in Figures 46-46A). The exchange rate that they have agreed to will be a ratio of dollars to pounds (Step 300).
0366Alice begins by signing on to her Transaction money module <b>4</b> (using Steps 10-42 described above) while Bob signs on to his Transaction money module <b>4</b> (using Steps 10-42). Thereafter, the To Subscriber <b>33</b> applications of both Transaction money modules <b>4</b> prompt the respective users to select a type of transaction (Steps 302-303). In this example, Alice and Bob agree to exchange her dollars for his pounds.
0367By requesting the foreign exchange transaction, Session Manager A <b>31</b> will establish a communications link with Session Manager B <b>31</b> (Steps 306, 307) so that a session may be established between the two money modules using Steps 190-258. Alice is then prompted by To Subscriber A <b>33</b> for the amount of dollars she will sell, and the exchange rate that she will use in the transaction (Step 308).
0368Pay/Exchange A <b>35</b> receives the input (Step 310) and Note Directory A <b>39</b> checks for sufficient funds by comparing the amount requested to the amount of value contained in the Transaction money module <b>4</b> (Step 312). An insufficient funds condition will cause the To Subscriber A <b>33</b> to send an insufficient funds message to Alice and prompt the subscriber to select another amount of dollars and exchange rate (Steps 318-320). When new selections are entered, the process flow returns to Step 312 and continues from there. If Alice does not select a new amount, the session is dissolved using abort transaction Steps 500-524.
0369When the funds are sufficient to meet the amount requested, the Pay/Exchange A <b>35</b> sends the amount of the dollars and the proposed dollar/pound exchange rate (Step 316) to the To Subscriber application <b>33</b> of Transaction money module B <b>4</b> using the Steps 2-8. (See Figure 46A). At this point, To Subscriber B <b>33</b> prompts Bob with the amount and rate proposed by Alice, to determine if the values are what Bob will agree to exchange (Step 322).
0370The Pay/Exchange B <b>35</b> receives the dollar amount and the rate that is proposed by Alice and if the amount and rate are not agreed to by Bob, Pay/Exchange B <b>35</b> will send a message indicating that the value or exchange rate is incorrect (Step 326), through the Steps of 2-8 for sending messages. To Subscriber A <b>33</b> prompts Alice for the dollar amount and exchange rate over again (Step 327). Entry of new values returns the process to Step 310 for continuation, see Fig. 46, while the lack of new values entered causes the abort transaction process of Steps 500-524 to be initiated.
0371If the amount and rate are agreed to by Bob, Pay/Exchange B <b>35</b> will calculate the equivalent amount in pounds, based on the rate provided (not shown), and then initiate the step of having Note Directory B <b>39</b> check to see that Transaction money module B <b>4</b> contains sufficient funds to fulfill the exchange (Step 323). When the funds in Transaction money module B <b>4</b> are insufficient to meet the exchange, Pay/Exchange B <b>35</b> sends a message to Alice of insufficient funds (Step 325) using Steps 2-8. The process flow returns to Step 327.
0372Proceeding with the case in which sufficient funds do exist in Transaction money module B <b>4</b>, Pay/Exchange B <b>35</b> will send an acknowledgement using Steps 2-8 to Transaction money module A <b>4</b> (Step 329). After receiving this acknowledgement, Pay/Exchange A <b>35</b> sends the amount of dollars requested to its corresponding Money Holder <b>38</b> application in Step 330. The dollars are transferred from Alice to Bob via the Steps 750-770 described above for transferring notes <b>11</b>.
0373Pay/Exchange B <b>35</b> receives the notes <b>11</b> and then transfers the amount of pounds to its Money Holder <b>38</b> application (Step 331). From there, the electronic pounds are transferred to Alice using the transfer notes process described in Steps 750-770. To record this exchange, Transaction money module A <b>4</b> commits with Transaction money module B <b>4</b> by using process Steps 690-698 described above. With a satisfactory exchange, the communications link between the two Transaction money modules may now be terminated.
Foreign Exchange At An Issuing Bank
0374Turning attention now to Figure 48, if a subscriber were to exchange his/her dollars for pounds with an Issuing Bank <b>1</b> instead of with a subscriber, the following process is followed.
0375Subscriber A sets up the foreign exchange transaction by signing on to his/her Transaction money module <b>4</b> (see Fig. 47Z) using Steps 10-42 described above. To Subscriber A <b>33</b> prompts the subscriber for the transaction desired (Step 334), and in this example, the subscriber chooses the dollar/pound exchange, and the amount of dollars the subscriber will exchange. It is anticipated that the choice of the bank to transact with may be an option offered to the subscriber (Step 336).
0376The Note Directory A <b>39</b> checks for a sufficient balance to complete the request (Step 338). An insufficient balance permits the subscriber to again enter the amount he/she will exchange (Step 340-342), whereby Session Manager A <b>31</b> will terminate the transaction (Step 345) if no new amount is entered. Entry of a new amount returns the process to Step 338 to check for sufficient funds to meet the new request. When the funds are sufficient for the exchange request, a Network <b>25</b> sign-on using Steps 50-168 is commenced.
0377After the Network <b>25</b> sign-on, the Network <b>25</b> checks if a bank or financial institution has been selected (Step 346). If a bank or financial institution was not chosen earlier, To Teller A <b>34</b> must prompt the Network Server <b>26</b>, through Session Manager A <b>31</b>, for a list of banks or financial institutions that will provide the exchange (Steps 348-350). The Network Server <b>26</b> sends the list (along with rates) to the subscriber through the To Teller A <b>34</b> and To Subscriber A <b>33</b> applications (Steps 352-356).
0378After prompting (Step 357, Fig. 47A), the subscriber chooses a bank or financial institution, or ends the transaction (Step 359). When a bank or financial institution is chosen, a session is established with the Teller money module <b>5</b> chosen using Steps 190-258 described above. After a session is established, To Teller A <b>34</b> sends the amount of dollars to be exchanged for pounds (Step 360) using Steps 2-8 for encrypting and transmitting a message.
0379To ensure that the subscriber still wants to proceed with the exchange, To Transaction B <b>49</b> sends the current exchange rate to the subscriber using process Steps 2-8 (Step 362). At this point, To Subscriber A <b>33</b> prompts the subscriber with the bank's exchange rate and if the subscriber does not wish to proceed, the transaction is aborted by following Steps 500-524 (Steps 364-366). If the transaction is to proceed, the dollars are transferred from Transaction money module A <b>4</b> to Teller money module B <b>5</b> using Steps 750-770 described herein.
0380Returning to Figure 48, once the set up of the foreign exchange transaction is accomplished, the proper accounting transactions are posted (Step 368; also illustrated in Figure 15, Step 1) to reflect the dollars that have just been transferred. A session is established between Teller money module B <b>5</b> and a Money Generator module <b>6</b> via Steps 190-258. Teller money module B <b>5</b> requests the proper pound notes <b>11</b> through process Steps 780-792. The notes <b>11</b> are returned from the Money Generator module <b>6</b> to the Teller money module B <b>5</b> using Steps 750-770.
0381This latter transfer of notes <b>11</b> requires a corresponding updating of the accounts involved (Step 370; see also Fig. 15, Step 2). The notes <b>11</b> are transferred to the Transaction money module A <b>4</b> through process Steps 750-770. To complete the exchange, Transaction money module A <b>4</b> commits to Teller money module B <b>5</b> who subsequently commits to the Money Generator module <b>6</b> using process Steps 690-698.
Foreign Exchange At A Correspondent Bank
0382The foreign exchange with a Correspondent Bank <b>2</b> is described with the aid of Figure 49. Initially, the foreign exchange transaction is set up by repeating process Steps 334-366, (Figs. 47-47A) and updating the proper accounts (see Figure 16, Steps 1-2) to reflect the notes <b>11</b> that have just been transferred from the subscriber's money module <b>4</b> to Teller money module B <b>5</b> (Step 372). Thereafter, Teller money module B <b>5</b> will establish a session with Teller money module C <b>5</b> at an Issuing Bank <b>1</b>, by performing process Steps 190-258.
0383A withdrawal is requested by Teller money module B <b>5</b> to Teller money module C <b>5</b> using process Steps 700-724 described above. To obtain the notes <b>11</b> for the request, Teller money module C <b>5</b> must get them from a Money Generator module <b>6</b>. Accordingly, a session is established between the two money modules via Steps 190-258, and the notes <b>11</b> are requested following process Steps 780-792 outlined above.
0384The Money Generator module <b>6</b> will create the notes <b>11</b> requested and transfer them to Teller money module C <b>5</b> using process Steps 750-770. This is followed by a posting to the proper accounts in the (bank's systems (Step 374), see Figure 16, Step 3 for accounting transactions). The notes <b>11</b> are now transferred from Teller money module C to Transaction money module A <b>4</b> via Teller money module B <b>5</b> using for each transfer the process Steps 750-770. Finally, all the sessions must be committed, and Transaction money module A <b>4</b> commits to Teller money module B <b>5</b> who in turn commits to Teller money module C <b>5</b> using Steps 690-698. Teller money module C <b>5</b> commits to the Money Generator module <b>6</b> to complete the exchange of dollars for pounds.
Updating Notes, Certificate
0385As mentioned above, it is anticipated that the date of expiration of a note, used as a security measure, may expire while it is stored in a Transaction money module <b>4</b>. If this occurs, the holder of expired notes <b>11</b> will not be able to transfer them to another Transaction money module <b>4</b>, but the holder may deposit them or exchange them for new notes <b>11</b> by transacting with a participating bank or financial institution.
0386Additionally, if the certificate associated with a particular Transaction money module <b>4</b> expires, the subscriber must sign on the Network <b>25</b> to update the certificate in order to transact with another Transaction money module <b>4</b>. The following is a description of the process flow for updating an expired certificate or expired notes <b>11</b>.
0387Beginning at the top of Figure 50, a subscriber signs on to the Transaction money module <b>4</b> using the Steps 10-42 described above, and is prompted by To Subscriber A <b>33</b> to select a transaction (Step 570). After selecting the transaction for "updating" (Step 572), a sign-on to the Network <b>25</b> is performed using Steps 50-168. The sign-on to the Network <b>25</b> will perform the updating of the certificate, as described above with reference to Figure 33-33A.
0388For updating the notes <b>11</b>, the Session Manager A <b>31</b> sends the update notes request to the Network <b>25</b> (Step 574); the Network Server <b>26</b> responds by sending the selected bank identifier back to the Transaction money module <b>4</b> (Step 576). Now, a session may be established between the Transaction money module A <b>4</b> and the Teller money module B <b>5</b> of the bank selected, using Steps 190-258.
0389Once the session is established, To Teller A <b>34</b> sends the request to update notes <b>11</b> (Step 578) using the message sending routine in Steps 2-8. To Transactor B <b>32</b> responds, Fig. 50A, with an acknowledgement (Step 580) sent using Steps 2-8. Transaction money module A <b>4</b> can now transfer the expired notes <b>11</b> to Teller money module B <b>5</b> using Steps 750-770. Thereafter, the corresponding accounting (see Figure 24, Step 1) is performed in the bank's records (Step 582), and a session is established between Teller money module B <b>5</b> and the Money Generator module <b>6</b> through Steps 190-258.
0390The request notes routine of Steps 780-792 is then performed. The Money Generator module <b>6</b> sends the requested notes <b>11</b> via Steps 750-770, and updates the accounts at the bank (Step 584; see also Fig. 24, Step 2). Teller money module B <b>5</b> takes the updated notes <b>11</b> and passes them to Transaction money module A <b>4</b> using the same Steps 750-770.
0391Now that the notes <b>11</b> have been updated in the Transaction money module <b>4</b>, the sessions are completed by having Transaction money module A <b>4</b> commit to Teller money module B <b>5</b>, and having Teller money module B <b>5</b> then commit the transaction with the Money Generator module <b>6</b>. Finally, both committing routines are performed using Steps 690-698 described above.
0392The above described process flows illustrate the capability of the invention to provide an improved system for exchanging electronic representations of economic value, while avoiding the inherent limitations of paper based monetary systems.
0393Operation of the invention has been described primarily with currency notes and credit notes that can be used by subscribers in the same processes. It will be understood that the described system can also be adapted to other monetary instruments. For example, personal and corporate checks and bank drafts could be provided by enhancing several of the Transactor applications. More complicated multiparty payment processes such as letters of credit and banker's acceptances could also be provided with appropriate changes to the system. It may also be possible to adapt the system of the invention to provide corporate financial obligations such as commercial paper.
0394Moreover, although the invention has been described in detail with particular reference to a preferred embodiment thereof, it should be understood that the invention is capable of other and different embodiments, and its details are capable of modifications in various obvious respects. As is readily apparent to those skilled in the art, variations and modifications can be affected while remaining within the spirit and scope of the invention. Accordingly, the foregoing disclosure, description, and figures are for illustrative purposes only, and do not in any way limit the invention, which is defined only by the claims.
69 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7 Sheet 8 Sheet 9 Sheet 10 Sheet 11 Sheet 12 Sheet 13 Sheet 14 Sheet 15 Sheet 16 Sheet 17 Sheet 18 Sheet 19 Sheet 20 Sheet 21 Sheet 22 Sheet 23 Sheet 24 Sheet 25 Sheet 26 Sheet 27 Sheet 28 Sheet 29 Sheet 30 Sheet 31 Sheet 32 Sheet 33 Sheet 34 Sheet 35 Sheet 36 Sheet 37 Sheet 38 Sheet 39 Sheet 40 Sheet 41 Sheet 42 Sheet 43 Sheet 44 Sheet 45 Sheet 46 Sheet 47 Sheet 48 Sheet 49 Sheet 50 Sheet 51 Sheet 52 Sheet 53 Sheet 54 Sheet 55 Sheet 56 Sheet 57 Sheet 58 Sheet 59 Sheet 60 Sheet 61 Sheet 62 Sheet 63 Sheet 64 Sheet 65 Sheet 66 Sheet 67 Sheet 68 Sheet 69
Every citation, both ways
| Document | Relation | Office | Cited during |
|---|---|---|---|
| EP0950968A4 | Cited by | European Patent Office (EPO) | Examiner |
| WO9930294A1 | Cited by | World Intellectual Property Organization (WIPO) | International search |
| FR2803678A1 | Cited by | France | Search report |
| US6038552A | Cited by | United States of America | Search report |
| WO2009053335A3 | Cited by | World Intellectual Property Organization (WIPO) | International search |
| EP0950968A1 | Cited by | European Patent Office (EPO) | Examiner |
| US7209889B1 | Cited by | United States of America | Applicant |
| EP1111555A1 | Cited by | European Patent Office (EPO) | Search report |
| US7899755B2 | Cited by | United States of America | Applicant |
| EP1221120A4 | Cited by | European Patent Office (EPO) | Search report |
| WO2009053335A2 | Cited by | World Intellectual Property Organization (WIPO) | International search |
| WO02075679A3 | Cited by | World Intellectual Property Organization (WIPO) | International search |
| EP0944011A4 | Cited by | European Patent Office (EPO) | Search report |
| WO02075679A2 | Cited by | World Intellectual Property Organization (WIPO) | International search |
| EP0944011A1 | Cited by | European Patent Office (EPO) | Search report |
| US9684889B2 | Cited by | United States of America | Applicant |
| EP2056245A1 | Cited by | European Patent Office (EPO) | Search report |
| EP0421808A2 | Cites | European Patent Office (EPO) | Search report |
| US4625276A | Cites | United States of America | Search report |
| US4839504A | Cites | United States of America | Search report |
| WO9109370A1 | Cites | World Intellectual Property Organization (WIPO) | Examiner |
| WO9109370A1 | Cites | World Intellectual Property Organization (WIPO) | Examiner |
| WO9116691A1 | Cites | World Intellectual Property Organization (WIPO) | Search report |
| CHAUM D.: "On-Line Cash Checks", LECTURE NOTES IN COMPUTER SCIENCE, vol. 434, 1990, NEW YORK, pages 288 - 293 | Non-patent | – | Examiner |
| EVEN S.: "Secure off-line electronic fund transfer between nontrusting parties", PROCEEDINGS OF THE IFIP WG 11.6 INTERNATIONAL CONFERENCE, 1989, AMSTERDAM, NETHERLANDS, pages 57 - 66 | Non-patent | – | Examiner |
201 members in 31 offices
Priority claims9
| Document | Office | Kind | Date |
|---|---|---|---|
| 794112 | United States of America | – | |
| 79411291 | United States of America | A | |
| 79411291 | United States of America | A | |
| 92119461 | European Patent Office (EPO) | A | |
| 92119461 | European Patent Office (EPO) | A | |
| 794112 | – | – | – |
| 92119461 | – | – | – |
| EP19920119461 | – | – | – |
| US19910794112 | – | – | – |
Members201
| Document | Office | Kind | |
|---|---|---|---|
| UY23501A1 | Uruguay | A1 | |
| IL103397A0 | Israel | A0 | |
| IL103397D0 | Israel | D0 | |
| ZA928773B | South Africa | B | |
| CA2080452A1 | Canada | A1 | |
| BR9204413A | Brazil | A | |
| EP0542298A2 | European Patent Office (EPO) | A2 | |
| WO9310503A1 | World Intellectual Property Organization (WIPO) | A1 | |
| MX9205890A | Mexico | A | |
| AU2739292A | Australia | A | |
| CN1073789A | China | A | |
| FI933208A | Finland | A | |
| FI933208A0 | Finland | A0 | |
| FI933208A7 | Finland | A7 | |
| NO932577D0 | Norway | D0 | |
| NO932577L | Norway | L | |
| HU9302008D0 | Hungary | D0 | |
| GR930300107T1 | Greece | T1 | |
| DE542298T1 | Germany | T1 | |
| ES2046156T1 | Spain | T1 | |
| PL300041A1 | Poland | A1 | |
| HUT65212A | Hungary | A | |
| TW224172B | Taiwan Province of China | B | |
| JPH06162059A | Japan | A | |
| EP0542298A3 | European Patent Office (EPO) | A3 | |
| AU658233B2 | Australia | B2 | |
| AU2013695A | Australia | A | |
| AU2013795A | Australia | A | |
| AU2013895A | Australia | A | |
| AU2013995A | Australia | A | |
| US5453601A | United States of America | A | |
| US5455407A | United States of America | A | |
| CA2184380A1 | Canada | A1 | |
| CA2287130A1 | Canada | A1 | |
| CA2287133A1 | Canada | A1 | |
| CA2287136A1 | Canada | A1 | |
| WO9530211A1 | World Intellectual Property Organization (WIPO) | A1 | |
| AU2105895A | Australia | A | |
| JPH07111723B2 | Japan | B2 | |
| IL116370A0 | Israel | A0 | |
| IL116370D0 | Israel | D0 | |
| IL116371A0 | Israel | A0 | |
| IL116371D0 | Israel | D0 | |
| IL103397A | Israel | A | |
| US5557518A | United States of America | A | |
| FI964032A | Finland | A | |
| FI964032A0 | Finland | A0 | |
| FI964032A7 | Finland | A7 | |
| CA2218612A1 | Canada | A1 | |
| WO9633476A2 | World Intellectual Property Organization (WIPO) | A2 | |
| NO964538D0 | Norway | D0 | |
| NZ244903A | New Zealand | A | |
| NZ286668A | New Zealand | A | |
| NZ286669A | New Zealand | A | |
| NZ286670A | New Zealand | A | |
| NZ286671A | New Zealand | A | |
| AU673304B2 | Australia | B2 | |
| AU673305B2 | Australia | B2 | |
| AU5561596A | Australia | A | |
| HU9602478D0 | Hungary | D0 | |
| NO964538L | Norway | L | |
| WO9633476A3 | World Intellectual Property Organization (WIPO) | A3 | |
| EP0758474A1 | European Patent Office (EPO) | A1 | |
| PL317026A1 | Poland | A1 | |
| SK68593A3 | Slovakia | A3 | |
| US5621797A | United States of America | A | |
| CN1147875A | China | A | |
| KR970702540A | Republic of Korea | A | |
| US5642419A | United States of America | A | |
| AU679359B2 | Australia | B2 | |
| AU679360B2 | Australia | B2 | |
| SI9520039A | Slovenia | A | |
| EP0784282A2This record | European Patent Office (EPO) | A2 | |
| EP0785515A2 | European Patent Office (EPO) | A2 | |
| EP0785516A2 | European Patent Office (EPO) | A2 | |
| EP0785517A2 | European Patent Office (EPO) | A2 | |
| EP0785518A2 | European Patent Office (EPO) | A2 | |
| PL172072B1 | Poland | B1 | |
| EP0788066A2 | European Patent Office (EPO) | A2 | |
| BR9507107A | Brazil | A | |
| JPH09245108A | Japan | A | |
| HUT76463A | Hungary | A | |
| SK117696A3 | Slovakia | A3 | |
| CZ251396A3 | Czechia | A3 | |
| NO974835D0 | Norway | D0 | |
| HU213819B | Hungary | B | |
| EP0803827A2 | European Patent Office (EPO) | A2 | |
| MY109965A | Malaysia | A | |
| JPH09511350A | Japan | A | |
| CA2080452C | Canada | C | |
| NO974835L | Norway | L | |
| US5703949A | United States of America | A | |
| MX9605174A | Mexico | A | |
| IL116371A | Israel | A | |
| EP0823105A2 | European Patent Office (EPO) | A2 | |
| NZ283103A | New Zealand | A | |
| PL323007A1 | Poland | A1 | |
| NZ329065A | New Zealand | A | |
| NZ329066A | New Zealand | A | |
| NZ329067A | New Zealand | A |
15 legal events, as 2 offices reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | Office | |
|---|---|---|---|
| Application deemed to be withdrawnWithdrawn18D | 18D | EP | |
| Information on the status of an ep patent application or granted ep patentGrantedSTATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWNSTAA | STAA | EP | |
| Information related to communication of intention to grant a patent modifiedORIGINAL CODE: EPIDOSCIGR1GRAC | GRAC | EP | |
| Applications withdrawn, deemed to be withdrawn, or refused after publication in hong kongWithdrawnWD | WD | HK | |
| Despatch of communication of intention to grant a patentORIGINAL CODE: EPIDOSNIGR1GRAP | GRAP | EP | |
| Interlocutory revision of appeal recordedAppealORIGINAL CODE: EPIDOSNIRAPEAPBV | APBV | EP | |
| Date of receipt of statement of grounds of appeal recordedAppealORIGINAL CODE: EPIDOSNNOA3EAPBR | APBR | EP | |
| Date of receipt of notice of appeal recordedAppealORIGINAL CODE: EPIDOSNNOA2EAPBN | APBN | EP | |
| First examination report despatched17Q | 17Q | EP | |
| Designated contracting statesAK | AK | EP | |
| Search report despatchedORIGINAL CODE: 0009013PUAL | PUAL | EP | |
| Request for examination filed17P | 17P | EP | |
| Divisional application: reference to earlier applicationAC | AC | EP | |
| Designated contracting statesAK | AK | EP | |
| Public reference made under article 153(3) epc to a published international application that has entered the european phaseORIGINAL CODE: 0009012PUAI | PUAI | EP |
Numbers
- Publication
- 0784282
- Publication, DOCDB
- 0784282
- Publication, EPODOC
- EP0784282
- Application
- 97105391
- Application, DOCDB
- 97105391
- Application, EPODOC
- EP19970105391
Titles3
- German
- Elektronisches Geldüberweisungssystem
- English
- Electronic-monetary system
- French
- Système monétaire électronique
Classification
- CPC, 20
- G07F7/1008
- G06Q20/02
- G06Q20/04
- G06Q20/06
- G06Q20/10
- G06Q20/108
- G06Q20/1085
- G06Q20/26
- G06Q20/29
- G06Q20/341
- G06Q20/367
- G06Q20/3674
- G06Q20/3676
- G06Q20/3678
- G06Q20/381
- G06Q20/40
- G06Q40/00
- G06Q40/02
- G07F7/082
- G07F19/211
- IPC, 14
- G07F19 00
- G06F19 00
- G06F21 00
- G06G7 52
- G06K19 07
- G06Q20 36
- G06Q20 40
- G06Q40 02
- G06Q40 04
- G07F
- G07F7 08
- G07F7 10
- G07G1 12
- H04L9 32
Designated states1
- Contracting states, 1
- Sweden