CA2267314A1

CA2267314A1 - System and method for pseudo cash transactions

Info

Publication number: CA2267314A1
Application number: CA002267314A
Authority: CA
Inventors: Jacob Y. Wong; Roy L. Anderson
Original assignee: Jaesent Inc.; Jacob Y. Wong; Roy L. Anderson
Current assignee: Jaesent Inc
Priority date: 1996-10-03
Filing date: 1997-09-05
Publication date: 1998-04-09
Also published as: US5913203A; EP1005682A4; WO1998014900A1; US5956699A; US5937394A; EP1005682A1; AU4255597A

Abstract

Totally anonymous or effectively anonymous cash-like transactions are accomplished by using a pseudo cash data packet converter for inserting a user key into a pseudo cash preliminary data packet through the use of a user monetary value that can be used to purchase goods or services via the Internet. A pseudo cash repository facilitates the cash-like transactions and maintains a record of the pseudo cash units and their fixed monetary value.
Depending upon the level of anonymity selected by a purchaser (1), the pseudo cash repository can either transmit pseudo cash preliminary data packets or pseudo cash units to a first entity. If the first entity loses an effectively anonymous pseudo cash preliminary data packet, it can be replaced by the pseudo cash repository without risk of loss.

Description

DESCRI TION
System and Method for Pseudo Cash Transactions 1. Field of the Invention The present invention is in the field of electronic money/Internet payment systems.

2. Background of the Invention When the idea of shopping on the Internet was first introduced a few years ago and made known to people using the Internet for reasons other than shopping, it was believed to be an instant retail business bonanza. From the standpoint of commerce and retail business, the Internet makes buying and selling of goods, information and services exceedingly simple and easy. Suddenly the whole world is at one's disposal through the so-called "browsing" software designed for the Internet. A tremen-dous wealth of information, just about anything one wishes to know, is suddenly at one's finger tip through a few clicks of the mouse attached to one's PC. But that is only referring to the part of buying and selling something on the Internet and the mechanism of payment involved must also be rendered the same in order to take advantage of the overall situation. Thus the payment part of the transaction must also be devised just as simple and convenient as the buy-sell part. What we are aiming at here is an overall system that will take care of both the buy-sell and the subsequent payment parts as efficiently as possible for such transactions on the Internet.
Today shoppers purchasing goods or services on the Internet are required to give their credit card numbers, phone numbers and/or addresses over the Internet in order to complete their transactions. The problem is that they=
do not know who else might be able to retrieve this information without their consent. People are still enthusiastic about the idea but are much more reserved in believing its potential, a11 because of the issues of privacy and potential credit liability not being totally resolved in shopping on the Internet at the present time.
However, no sooner than these issues were first identified, a number of entrepreneurs and companies went straight to work in the hope of solving these problems with the simplest of answers.
Not necessarily introduced in chronological order, a concept called "First Virtual" first asks a potential customer to fill out an application form providing standard personal information. First Virtual would then send a personal identification number (PIN) with an 800 number over the Internet to the customer's email. Then the customer is supposed to use the 80d number to give his credit card information over the phone to First Virtual to establish or open no more than just an electronic charge account. Clearly this system or procedure to shop on the Internet is no less complicated than the home shopping network and is nowhere close to a simple and anonymous cash dispensing system that one would desire.
Another concept called "Cybercash" requires customers or buyers on the Internet to first open a special Cybercash bank account that contains money designated for spending on the Net. A consumer issues instructions to purchase goods or services on the Net and money for these items are transferred from the consumer's Cybercash bank account to that of the merchant's. Transactions are anonymous unless the seller specifically asks for the identity of the buyer. Again one can readily see that this concept, although rather secured from the money handling standpoint, is not totally anonymous. Further-more, it is rather complicated involving a number of interactions between the buyer, the Cybercash bank and the seller. It is definitely incompatible with the simple_ elegance of doing shopping on the Internet, particularly with regards to speed and ultimate privacy.

WO 98I14900 PCT/US97l15701

3 Yet another concept called the "Netbill" requires a buyer on the Internet to first put money in a Netbill account and subsequent transactions made by the buyer are to be drawn off from the account sum or balance. Accounts of both buyers and sellers are maintained on a Netbill server, to keep transactions off the Net and to maintain lower transaction costs. After a purchase is made, the transfer of funds will automatically take place at the server. Digital goods, e.g. programs, documents etc. are transferred to the buyer in encrypted form. When the Netbill account has cleared the transaction, a receipt containing the key to the encrypted goods is sent to the merchant, then forwarded to the consumer. The advantages of this concept clearly lie in the good security of fund transfer and in accountability. However, the transaction is complicated and could be time consuming. Furthermore, it is not totally anonymous.
A two-step process called "Millicent" had also been introduced. This two-step process uses fake money much like Geoffrey Bucks at Toys 'R' Us stores. A merchant creates his own electronic currency, or "scrip", that is sold to brokers. Brokers then sell the scrip to buyers.
Sellers deal with just a handful of accounts, spreading transaction costs over a large volume of purchases.
Millicent customers need to buy currency from only a few trusted brokers, not every vendor. Anyone can see the request for merchandise or services and the transfer of scrip over the Net as transactions take place. Clearly the principal advantage of this system is its potential efficiency and extremely low transaction costs. However, merchants can run off with the money and the system lacks privacy and auditability.
The best system to date, but by no means perfect or totally practical, is the so-called "Digicash" or "ecash".
In theory this system turns a user's or buyer's hard drive on his PC into a purse. To use this system, one first establishes an account with a bank. To obtain digicash or ecash, the user creates on his own a series of numbers that will represent a mixture of coins or money bills in various denominations according to his own wishes. This request for digicash is then sent to the bank, which deducts the total amount requested from the user's exist-ing valid account. The bank then sends him an equivalent amount of ecash as an encrypted email message containing a series of numbers. Each number corresponds to a specified amount of money.
Before the user can actually use these encrypted series of numbers from the bank to purchase goods or services on the Net, the user must first obtain a user name and a password from Digicash. Then the user has to download Digicash's ecash software to the user's PC. The final step is to create the user's own encryption key (in essence another password) and together with the user's password obtained earlier from Digicash, the user can then spend ecash on the Net.
The Digicash system has two excellent features that are essential to any such system eyeing to become the future standard of the electronic money/Internet payment industry. They are strong anonymity (not absolute) and cryptography. The shortcomings of this system, on the other hand, are quite plentiful. First of a11, crypto graphy implementation for information transfer, if not very carefully thought out ahead of time, can be very expensive. Such is the case for the Digicash system.
Second, as implemented today, the Digicash system is very interaction intensive and rather loosely organized.
Requests by users to the bank and the bank's handling of their requests alone could be an awesome burden to the bank when the traffic builds up in a hurry. This is especially the case when there is no amount limits of any kind imposed on any ecash request. Thus a one dollar=
request must be handled in the same way as one that is for $1,000.

WO 98l14900 PCTlUS97115701 Third, even though the anonymity for any transaction is strong, it is by no means absolute. The reason is that the encrypted ecash that is passed on to a user originates from a bank who has the account information of the 5 individual. In order that the bank subsequently honors this particular ecash from the merchants, it needs to reconcile with its initial issuance and that leads to the original account that requested it.
Finally, a user's ecash is stored as a series of numbers on the hard disk of his PC. But storing numbers on the hard disk is risky. If one has a disk crash, which is quite common nowadays in view of the complexities of modern day software, or if one's computer is stolen, one has lost his money. It likens in this case to losing one's wallet. Because of this, users are likely to acquire encoded electronic cash only shortly before they intend to spend it and acquire only as much as they think they will really need. This particular user behavior renders the overall system highly inefficient and ulti-mately causes transaction overload and increased dissatis-faction and higher operating costs.
It is clear from the above discussion of prior art in systems and/or procedures for electronic money/Internet payment existing and available today that a better system is desired and badly needed. Since personal privacy and credit liability will no doubt continue to be issues of great importance for the potential Internet users, com-merce on the Internet simply cannot flourish without a cash dispensing system that would not only guarantee these features but also others that take advantage of the simplicity and convenience of buying and selling on the Net.
Summary of the Invention The present invention is generally directed to elec-tronic money/Internet payment systems, and specifically relates to a procedure and method whereby customers and vendors can buy and sell merchandise and information on the Internet in a manner resembling various degrees of a real-life cash transactions, namely from a traceable transaction to an absolutely anonymous or private one, like using real cash. In particular, the present inven-tion uses a pseudo cash data packet converter for inserting a user key into a pseudo cash preliminary data packet through the use of a user insertion key to generate a pseudo cash unit with a fixed monetary value.
In a first, separate aspect of the present invention, a pseudo cash unit is generated by a pseudo cash reposi-tory by use of the user key and the user insertion key of a first entity. The pseudo cash unit is assigned a fixed monetary value and the first entity exchanges the fixed monetary value for receipt of the pseudo cash preliminary data packet which was used to generate the pseudo cash unit. Once the pseudo cash unit is generated, an active record of the pseudo cash unit and the fixed monetary value assigned to the pseudo cash unit is generated and maintained by the pseudo cash repository until the record is deactivated. When the first entity wishes to spend the pseudo cash unit associated with the pseudo cash prelim-inary data packet received from the pseudo cash reposi-tory, the pseudo cash unit is generated by a pseudo cash data packet converter by inserting the first entity's user key into the pseudo cash preliminary data packet in accordance with an algorithm that uses the user insertion key of the first entity. Now the pseudo cash unit can be transmitted to a second entity who transmits the pseudo cash unit back to the pseudo cash repository. Once the pseudo cash repository verifies that an active record exists for the pseudo cash unit, the record is deactivated and the fixed monetary value of the pseudo cash unit is transferred from the pseudo cash repository to the second-entity.
In another, separate aspect of the present invention, the pseudo cash preliminary data packet can be dispensed by any number of means, including mail, an automatic teller machine or even over an electronic communication medium.
In still another, separate aspect of the present invention, the user key and the user insertion key of the first entity are stored in a first entity account file of the pseudo cash repository associated with the first entity which is used to generate a pseudo cash unit for the first entity. As a result, a record associated with each pseudo cash unit is kept by the pseudo cash reposi-tory which can be used to confirm transactions between the first entity and a second entity, or to verify outstanding pseudo cash units created by the pseudo cash repository for the first entity. In accordance with this aspect of the present invention, if the first entity should lose or misplace a pseudo cash preliminary data packet, the pseudo cash repository could dispense the pseudo cash preliminary data packet to the first entity one or more additional times. Similarly, if there is a question as to where a particular pseudo cash unit was spent by the first entity, this information could be obtained by the first entity from the pseudo cash repository.
In yet another, separate aspect of the present inven tion, the first entity receives a pseudo cash unit generated by the pseudo cash repository in exchange for the fixed monetary value associated with the pseudo cash unit. The pseudo cash repository maintains an active record of the pseudo cash unit until the pseudo cash unit is exchanged for the fixed monetary value. Because the identity of the first entity cannot be determined from any record maintained by the pseudo cash repository, the transaction is an anonymous transaction similar to an anonymous cash transaction.
Accordingly, it is a primary object of the present -invention to provide a novel cash dispensing system and procedure for use in conducting cash transactions on the WO 9$I14900 PCT/US97/15701 Internet such as the purchases of goods, information and services between buyers and sellers.
Brief Description of the Drawings Figure 1 is a schematic drawing depicting a system for providing pseudo cash transaction emulating real cash transactions on the Internet.
Figure 2 is a schematic drawing depicting a system for providing pseudo cash transactions on the Internet.
Figure 3 is a schematic drawing depicting an alternative embodiment of a system for providing pseudo cash transactions on the Internet.
Detailed Description of t a Preferred Embodiment In the preferred embodiment of the present invention, a system for providing pseudo cash transactions is provided which relies upon pseudo cash units generated by insertion of user keys into pseudo cash preliminary data packets in accordance with user insertion keys through the use of an algorithm. Although the system is designed for multiple transactions, for the sake of simplicity in its description, the system will be described in the singular, i.e., it will describe how a single sequence will work.
Initially, there must be a money source. This is described as a pseudo cash repository, but it does not need to be a single entity. In practice, it can be a single bank, or a single credit card company or a number of affiliated banks (a bank group) or a number of affiliated credit card companies (a card group) affiliated with one or more merchants and set up to do business with one or more money source customers or some other entity or entities that will perform such a function. The pseudo cash repository, in concept, is similar to an entity that issues traveler's checks (for a non-anonymous cash-like-transaction) or a money order (for a potentially anonymous cash-like transaction).

There must also be at least one customer desirous of engaging in a pseudo cash transaction. This customer, which can be an individual person, a company or some other entity, is described as a first entity. It is envisioned that the first entity will use pseudo cash to transact business with another entity, described as a second entity, that has made arrangements with the pseudo cash repository to receive money for pseudo cash units it transfers to the pseudo cash repository. However, it is possible that the second entity is identical to the first entity when the first entity merely wishes to cash in a pseudo cash unit (this would be analogous to a person cashing a traveler' s check or money order that the same person had earlier purchased).
There is no limit to how many customers and merchants a single bank, a single credit card company, one or more banks within a bank group or multiple bank groups, or one or more credit card companies within a card group or multiple card groups can have within the system structure.
Similarly, a customer can affiliate with a single bank, a single credit card company, one or more banks within a bank group or multiple bank groups, one or more credit card companies within a card group or multiple card groups, or any combinations thereof within the system structure. Also, a merchant can affiliate with a single bank, a single credit card company, one or more banks within a bank group or multiple bank groups, one or more credit card companies within a card group or multiple card groups.
A simple system for providing pseudo cash trans-actions in accordance with the preferred embodiment includes a pseudo cash dispenser, a pseudo cash data packet converter, a pseudo cash repository, means for generating a record and means for deactivation of the-record, as described more fully hereinafter.
The pseudo cash dispenser dispenses a pseudo cash preliminary data packet or a pseudo cash unit in exchange for a fixed monetary value. A pseudo cash preliminary data packet is a string of characters, preferably eight or more. The characters, for convenience, are either letters of the alphabet or numerals, but other characters could 5 also be used without departing from the spirit of the invention. The pseudo cash dispenser can dispense the pseudo cash preliminary data packet to the first entity by any suitable means. If the pseudo cash preliminary data packet is dispensed by an automated teller machine, the 10 string of characters could be printed on a receipt in the same fashion that account balances and other information are commonly available to bank customers in the United States today by automatic teller machines. The pseudo cash preliminary data packet could also be dispensed over an electronic communication medium, such as the Internet or a telephone line.
The pseudo cash data packet converter can take on any of a variety of forms. In an especially preferred embodiment, the pseudo cash data packet converter is a computer program located in a computer. However, if the algorithm is simple enough, the pseudo cash unit could be generated by an individual having knowledge of a11 of the requisite input data, and the algorithm, needed to generate the pseudo cash unit.
The pseudo cash preliminary data packet is based upon a randomly generated number that can be generated by commonly available techniques already in existence.
Instead of using a bit sequence of data, it is preferred that the pseudo cash preliminary data packet be converted to a sequence of characters, such as an alphanumeric sequence, which will be easier to use. It is presently contemplated that the pseudo cash preliminary data packet will have eight or more characters, but this is somewhat dependent upon encryption technology, and what level of_ possibilities is needed to ensure a secure system.
The user key and the user insertion key are also strings of characters, preferably numeric characters. It WO 98/14900 PCTiUS97i15701 is presently contemplated that the user key will have at least four characters and, in an especially preferred embodiment, the user insertion key will be a string of numeric characters that has an identical number of characters as the user key, each of the characters of the user insertion key being unique as compared to the other characters of the string. In a very simple algorithm for the pseudo cash data packet converter, the pseudo cash data packet converter will insert each character of the user key into the pseudo cash preliminary data packet at a location which corresponds to a corresponding character of the user insertion key to generate the pseudo cash unit.
The pseudo cash repository maintains a record of the pseudo cash unit and the fixed monetary value associated with the pseudo cash unit and, in an especially preferred embodiment, can be either a computer or a network of computers that operates as the money source. If the pseudo cash repository relies upon a network of computers, the network can be dedicated or it can be connected by an encrypted two-way communication linkage. The pseudo cash repository must also have a means for generating the record from the pseudo cash preliminary data packet, the fixed monetary value, the user key and the user insertion key in response to an exchange of the preliminary data packet to the first entity for the fixed monetary value and means for deactivation of the record and exchanging the fixed monetary value for receipt of the pseudo cash unit . The nature of the record of the pseudo cash unit kept by the pseudo cash repository will depend upon the level of anonymity and traceability selected by the first entity. If total anonymity is desired, then the identity of the first entity cannot be determined from the record kept by the pseudo cash repository. If total anonymity is-not required, then the identity of the first entity can be determined because the record associated with the pseudo cash unit kept by the pseudo cash repository will contain information relating to the identity of the first entity.
The means for generating a record of the pseudo cash unit and subsequently deactivating the record can be extremely varied. In terms of efficiency and speed of execution, use of one or more computers is preferred. If a pseudo cash unit is being generated for a known entity, once the request is received and the entity is identified, the pseudo cash repository can check its records for the user key and the user insertion key of the known identity. Next, the pseudo cash repository can generate the pseudo cash unit and create a file that is uniquely identified with the pseudo cash unit which also contains the fixed monetary value associated with the pseudo cash unit. In its simplest form, the identity of the file could be pseudo cash unit. In connection with that file, other information could be stored, such as the identity of the individual requesting the pseudo cash unit. If the pseudo cash unit is being generated for an unknown entity, the unknown entity could enter its user key and user insertion key into the system. After the record of the pseudo cash unit and its fixed monetary value is generated, it can be stored in a data base containing other pseudo cash records. When a pseudo cash unit is transmitted to the pseudo cash repository for redemption of its monetary value by a redeeming party, the data base containing pseudo cash records is searched for an active record corresponding to the pseudo cash unit. If an active record is found, the record is deactivated and the fixed monetary value associated with the pseudo cash unit is identified and then credited or turned over to the redeeming party. When an active record is deactivated, the record can be reconfigured, or a new record can be generated, which includes information such as the identity-of the redeeming party, and if the transaction does not involve an anonymous pseudo cash unit, the identity of the first entity. The details of how records should be generated and deactivated should be well within the skill of one of ordinary skill in the art of computer programing once the inventive concept of this application is made known to such a person.
To better describe the operation of a system of the preferred embodiment, and the method by which operates, the system and method will be described in greater detail in connection with Figures 1-3. In each of these Figures, the system is designed for providing pseudo cash transactions between a first entity and a second entity through use of a pseudo cash repository and the Internet.
With reference to Figures 1 and 3, the pseudo cash dispensing system requires a customer (the first entity) 1 to first establish a business relationship with a money source (the pseudo cash repository) 2 such as a bank or a credit card company. For ease of description, it will be assumed that the money source is a bank. The bank obtains the usual personal information from the customer and establishes a certain amount of credit for the customer according to the customer's personal financial condition. According to the present system, the bank will also issue the customer an account number, a user key and a user insertion key. Because the user key is similar to the concept of a personal identification number (PIN) presently in common use, the user key will hereinafter be referred to as PIN and the user insertion key will hereinafter be referred to as a PIN insertion sequence number (PISN). The customer may also pick his or her own PIN and PISN so that the customer can remember these numbers and use them without having to look them up.
There is no difference in the use of the PIN number between the current banking practice and the present system. Normally the customer uses this PIN to obtain cash from his or her bank account at ATMs and for other-private financial transactions with the bank. The present system has similar ideas.

The PIN insertion sequence number or PISN on the other hand is a distinct feature of the present Internet cash dispensing system. Together with the PIN, these two numbers constitute the private "Key" to the customer's bank account in the system. Whereas the PIN is typically a 4 or 5 character numeric number in ordinary bank usage, in the current system, the PIN can be any number of alpha-numeric digits, preferably not less than four (4).
For a very simple system, the PISN number is a little bit more restricted. First, the number of characters in PISN should preferably be the same as the total number of alpha-numeric digits in the PIN. Second, because of its function (see below), no two characters in the PISN should be the same, unless the algorithm used to generate a pseudo cash unit is designed to account for such a possibility. For example, '2236', '9440', '5588' would all be invalid PISN numbers unless the algorithm accounts for duplicate numbers, such as converting a duplicate number to a new number in accordance with a predetermined parameter. As its name implies, PISN instructs the user how to insert his PIN number into a particular pseudo cash preliminary data packet, which, for example, might be an eight-character alpha-numeric number.
An example of ho.w to use a customer's private "Key"
or PIN and PISN numbers together to convert a pseudo cash preliminary data packet into a pseudo cash unit follows in which the algorithm is a simple substitution algorithm in which the PISN characters are used to denote a specific insertion location. In this example, let the PIN be 'Z123', PISN be '0246' and the pseudo cash preliminary data packet be 'ABCD1234'. Since the PIN is supposed to be inserted into the pseudo cash preliminary data packet according to the PISN insertion sequence, the pseudo cash unit will have a total of twelve (12) alpha-numeric-characters, namely 8 from the pseudo cash preliminary data packet plus 4 from the PIN. Furthermore, the sequence of the pseudo cash unit is labeled from the 0th position to the 11th position, a total of 12 positions consistent with having 12 characters.
The first character of the PISN '0' means to start the first character of the PIN, namely 'Z' in the very 5 first or 0th position of the encrypted pseudo cash preliminary data packet. Similarly the second character of the PIN, namely '1' should occupy the second position and so on. The result of the pseudo cash unit is then 'ZA1B2C3D1234'. One can see that the PIN number has been 10 inserted into the pseudo cash preliminary data packet according to the insertion sequence of PISN.
The pseudo cash preliminary data packet is an alpha-numeric number having any number of digits. In the example above, the pseudo cash preliminary data packet has 15 eight (8) digits. In the present system, the pseudo cash unit is used as a way to represent Internet cash, or cash that is negotiable for buy-sell on the Internet. In the example above, the pseudo cash unit has a total of 12 alpha-numeric digits, namely, 'ZA1B2C3D1234'. In the current system, we pick the pseudo cash preliminary data packet to have eight (8) digits with a purpose. Since we are taking advantage of the already existing PIN number, which has four (4) numeric digits, the pseudo cash unit or Internet cash for the present system will have twelve (12) digits, eight of whom is alpha-numeric and the other four numeric. As an encrypted code the security is equivalent to 1: 368 x l0gor 2.82 x 1016 For even higher security, we can pick the pseudo cash preliminary data packet to have more than 8 digits or to change the PIN to have four (9) alpha-numeric instead of four (4) numeric only digits.
For example, if the pseudo cash preliminary data packet is changed to have 10 digits, then the security would have been increased to 1: 361~ x 10q or 3. 65 x 1019. On the other hand, if the pseudo cash preliminary data packet remains-at 8 digits and the PIN changes to alpha-numeric digits, then the security would have been increased to 1: 361z or

4.73 x 1018. It is also possible to extend the security level by using characters other than alpha-numeric characters. For example, other common characters found in typewriter keyboards, such as '. , @, #, $, o, ~, &, * , (, -, ?, <, >, ?, ?, [, ] , { , } , and \ could also be used. And, of course, the system is capable of being adapted to other language systems that use characters other than the Arabic alphabet.
Although one can clearly see the simplistic advantage of using the PIN as the starting point and the introduction of the PISN to form the system "Key", the present invention is not limited to such a selection. As a matter of fact, any methodology used in the formulation of the "Key" would work in the system but it might be more complicated from the overall system standpoint. A
customer, armed with his or her private system "Key" from the money source with whom the customer has a valid account, is ready to do Internet business using the presently invented cash dispensing system for the Lnternet.
There are two categories of Internet cash identified by the current cash dispensing system according to their level of anonymity. Category I (Cat I) cash refers to pseudo cash units created by the system that absolutely cannot be traced. Category II (Cat II) cash refers to pseudo cash units created by the system that can only be traced through the bank of origin, or the nerve center.
Consequently Internet cash generated and used in the current system can generally be considered anonymous.
Furthermore, for this reason a special name had been chosen for the presently invented cash dispensing system for the Internet. It is called System for Processina Electronic Cash Transactions Anonymously or the SPECTA
system.
Referring again to Figures 1 and 3, a person can wal l into a bank and use real cash to purchase Category I cash from the bank using the SPECTA system. In this case the bank simply issues the person the Cat I cash in exchange for real cash. Example: A person wishes to purchase $200 Internet Cat I cash in the following denominations:
$100 One (1) $ 20 Five (5) The bank issues the person the following Cat I Internet cash as follows:
1289GTK8DE66 $100 4567ABGH4578 $20 4567ABIKL36Z $20 4567ABCK7890 $20 4567ABCF8999 $20 999034KLL456 $20 Needless to say, as the bank issues these Cat I
Internet cash, it only keeps track of what Cat I cash or codes have been issued without having to inquire about the purchaser's personal information or references. In essence, this is just a cash transaction. Thus, these Cat I cash are just like real cash and any person who has access to these Cat I codes will in fact be the owner of these cash. If these Cat I cash were lost or misplaced, or the codes revealed to a stranger, then it is like losing the cash and the original purchaser might never be able to recover these Internet negotiable cash.
From the System standpoint, as these Cat I cash are issued, the bank will immediately create a record of these Cat I codes with their associated monetary value. Note that these Cat I codes (or "keyed" Cat II codes, see below) are stored for verification purposes only and they are not available for inspection or revelation to anybody.
Thus the purchaser can indeed spend these Cat I cash on the Internet as negotiable cash without any restriction except that the merchants have to be affiliated with the same money source from which the Internet cash was purchased. The purchaser can in fact purchase Cat I cash_ from the bank in any amount with real cash if the customer knows ahead of time exactly how much Internet cash the customer will need, for example like $125.78.

Still referring to Figures 1 and 3, a person can walk in and purchase Cat I cash from the bank using a bank account or credit instead of real cash. The bank can issue the customer the same Cat I cash codes as before without having to link the customer in any way to these Internet cash.
The customer can also use the customer's bank account or credit to purchase Cat II cash. Since the bank knows and can use the customer's private "Key" at the bank, the Cat II cash can be issued to the customer on site in a simpler form as follows (same example of $200 as before):
128PYU34 $l00 9567DFGT $20 THU4567S $20 789JKIUP $20 56790TYY $20 TYRE5647 $20 Furthermore, the customer can even have the bank send these Cat II codes to the customer's email address on the Internet without risking anything. (In this latter case, the customer might just as well use a regular phone to call up the bank instead of showing up at it to do the transaction.) Note that the Cat II codes only contain eight (8) alpha-numeric digits instead of 12 like the Cat I cash or codes. By giving up absolute anonymity, Cat II
cash is much more secured. It is because the Cat II codes themselves are not negotiable on the Internet as they are issued. The purchaser in this case must "key" these Cat II codes using his personal "Key" (see example given earlier) in order to turn them into 12-character Cat II
Internet cash. Since his "Key" is private and the customer does not have to "key" the Cat II codes to convert them into Cat II cash until the very last minute when the customer needs the cash on the Net, the customer_ can treat these Cat II codes with much less care. But the bank knows the customer' s "Key" and it must convert the Cat II codes into Cat II cash before . Thus even if these Cat II codes are lost or misplaced, nobody can take advantage of them and the purchaser can retrieve them from the bank with information linking to the customer's bank or credit card account.
The SPECTA system does not specify the nature and characteristics of the encrypted communication link between the money source and its affiliated merchants or bank members. Such communication links can vary a11 the way from digital phone lines like the Integrated Services Digital Network (ISDN) , digital cellular radio network using advanced satellite systems, or even the Internet network itself. At the same time the encryption method could use any on-the-fly encryption technology ranging from 64- to 128 bit or any future enhancement imple-mentation. The purpose for not specifying the exact nature and characteristics of the encrypted link for the system is to allow for future technological advancement in this area without any impact to the systems's operation.
Thus, it is up to the nerve centers of this system to take advantage of any performance enhancement and cast reduc-tion in this area in order to minimize the overall system transaction costs.
Still referring to Figures 1 and 3, a person with an email address on the Internet can purchase Cat II cash from the money source using the Internet alone. The only requirement is that the person has to "key" his or her bank or credit account number with his or her private "Key" before forwarding it to the bank's email address with any messages or requests. Like before, the bank will email the customer the Cat II codes and make activate a record of Cat II cash. Everything is exactly the same as in the previously illustrated examples.
To make keying the Cat II codes into. Cat II cash easier and simpler, it is relatively straightforward to_ program one's own "macro" software to perform this relatively tedious task. The macro software will take the "Key" or PIN and PISN 'passwords' from the user and can easily convert a Cat II pseudo cash preliminary data packet into Cat IT cash, i.e. from an eight (8) alpha-numeric digits number into a twelve (12) digits number.

The content of the Cat II cash depends upon whether or not

5 the PIN is strictly an a11 numeric number or alpha-numeric.

The SPECTA system overcomes many of the shortcomings of presently available electronic money/Internet payment systems. Its system structure correctly centers around 10 the money source and leaves the actual buy-sell transactions to the Internet where it excels with ease, speed and convenience. It elegantly adapts the system's customer/money source interface to existing practices in the banking and credit industry thereby streamlining many 15 system procedures and making them extremely user-friendly.

The end result is the advent of a new cash dispensing system fully compatible in performance with and takes full advantage of the Internet. The system as presently devised is fully auditable and secured. If desired, 20 transactions within the system can be tailored to have absolute anonymity. Even ordinary transactions are auto-matically rendered very private. Furthermore, the system can grow with the advancements of future digital communication and encryption technologies.

The cash dispensing system for the Internet according to the present invention is simple and convenient to use for a11 users. At the same time the system is fully secured (i.e. no accidental loss of money due to computer hardware or software failures) and auditable. Further-more, the system can grow with time and its structure can easily be expanded to accommodate any technological advances in the fast lanes of our Information Superhigh-way. The transaction cost is also reduced to a minimum by 1) limiting the use of encryption as much as possible; 2)-taking full advantage of the rapidly advancing digital telecommunication technologies such as Integrated Services Digital Network (ISDN) and digital cellular wireless network for Personal Communication Services (PCS); 3) sharing costs with existing services offered by the money center; 4) making the merchants share the transaction costs much like the present credit cards situation; and 5) making also the users do the bulk of the work to obtain their cash and only when they need to.
In operation a customer establishes an account and credit with a money source and obtains from it his personal "Key". To obtain Internet cash, he makes an request to the money source either in person, by phone or via the Net email. For completely unidentifiable Internet cash, the customer uses cash to purchase and obtain Category I (Cat I) cash or codes directly from the money source or has the latter send him Cat I cash or codes via the encrypted link. Customer acknowledges receipt of these codes or cash via email on the Internet. For ordinary Internet cash, namely identifiable or traceable, the money source sends him Category II (Cat II) codes via the Internet email. Cat I codes or cash liken to real cash and are good on the Internet for commerce without further identification. On the other hand, the customer has to personally "key" Cat II codes with his personal "Key" from the money source to turn them into Cat II cash before they become valid cash for commerce on the Internet.
The above discussion of this invention is directed primarily to the preferred embodiments and practices thereof. Further modifications are also possible without departing from the inventive concept. Thus, for example, the algorithm used to generate the pseudo cash unit could also insert an additional string of characters into the pseudo cash preliminary data packet. This string could be used for additional security, or for other purposes, such as providing data. For instance, the string could be used-to identify the entity that originally generated the pseudo cash unit, when the pseudo cash unit was generated, etc. Also, the algorithm could be periodically changed for additional security provided there is a suitable means to update the algorithm used by the first entity and then reconfigure the records maintained by the pseudo cash repository to account for the changed algorithm. In addition, the system can be designed to take into account the possibility that two pseudo cash units might be generated that are identical. To avoid this problem, the system could check the database of existing active records of pseudo cash units to prevent duplication prior to issuance of a preliminary data packet or pseudo cash unit to a first entity. If duplication is detected, one or more additional preliminary data packet could be used to generate a unique pseudo cash unit that is not active.
Accordingly, it will be readily apparent to those skilled in the art that still further changes and modifications in the actual implementation of the concepts described herein can readily be made without departing from the spirit and scope of the invention as defined by the following claims.

Claims

1. A system for providing pseudo cash transactions, comprising:
a pseudo cash dispenser for dispensing a pseudo cash preliminary data packet in exchange for a fixed monetary value;
a pseudo cash data packet converter for inserting a user key into the pseudo cash preliminary data packet through the use of a user insertion key to generate a pseudo cash unit;
a pseudo cash repository for maintaining a record of the pseudo cash unit and the fixed monetary value;
means for generating the record from the pseudo cash preliminary data packet, the fixed monetary value, the user key and the user insertion key in response to an exchange of the preliminary data packet to a first entity for the fixed monetary value; and means for deactivation of the record and exchanging the fixed monetary value for receipt of the pseudo cash unit.

2. A system as recited in claim 1, wherein the pseudo cash dispenser dispenses the pseudo cash preliminary data packet to the first entity.

3. A system as recited in claim 2, wherein the pseudo cash preliminary data packet is dispensed by an automated teller machine.

4. A system as recited in claim 2, wherein the pseudo cash preliminary data packet is dispensed to the first entity over an electonic communication medium.

5. A system as recited in claim 1, wherein the pseudo cash preliminary data packet is a string of at least eight characters.

6. A system as recited in claim 1, wherein the user key is a second string of at least four characters.

7. A system as recited in claim 6, wherein the user insertion key is a third string of numeric characters that has an identical number of characters as the second string, each of the numeric characters of the third string being unique as compared to the other numeric characters of the third string.

8. A system as recited in claim 7, wherein the pseudo cash data packet converter inserts each character of the second string into the pseudo cash preliminary data packet at a location which corresponds to a corresponding numeric character of the third string to generate the pseudo cash unit.

9. A system as recited in claim 1, wherein the pseudo cash data packet converter is a computer program located in a computer.

10. A system as recited in claim 1, wherein the record contains information relating to the identity of the first entity.

11. A system as recited in claim 1, wherein the identity of the first entity can not be determined from the record.

12. A system for providing pseudo cash transactions between a first entity and a second entity via the Internet, comprising:
a pseudo cash dispenser for dispensing a pseudo cash preliminary data packet with a fixed monetary value to the first entity in a readable format;
a pseudo cash data packet converter for inserting a user key of the first entity into the pseudo cash preliminary data packet through the use of a user insertion key of the first entity to generate a pseudo cash unit;
a pseudo cash repository for maintaining a file associated with the pseudo cash unit and the fixed monetary value;
means for generating the file;
a first entity link to the Internet;
a second entity link to the Internet;
means for transferring the pseudo cash unit from the first entity link to the second entity link via the Internet;
a communication link betweem the second entity and the pseudo cash repository; and means to deactivate the file and transfer the fixed monetary value from the pseudo cash repository to the second entity in response to transmission of the pseudo cash unit from the second entity to the pseudo cash repository via the communication link.

13. A system as recited in claim 12, further comprising:
means for transmitting the pseudo cash preliminary data packet from the pseudo cash dispenser to first entity link via the Internet.

14. A system as recited in claim 12, wherein the communication link is an electronic link via the Internet.

15. A system as recited in claim 12, wherein the pseudo cash preliminary data packet is a string of at least eight characters, the user key is a second string of at least four characters, and the user insertion key is a third string of numeric characters that has an identical number of characters as the second string, each of the numeric characters of the third string being unique as compared to the other numeric characters of the third string.

16. A system as recited in claim 12, wherein the file contains means for identifying the first entity.

17. A method for providing pseudo cash transactions, comprising:
generating a pseudo cash preliminary data packet;
generating a pseudo cash unit from the pseudo cash preliminary data packet by inserting a user key of a first entity into the pseudo cash preliminary data packet in accordance with a user insertion key of the first entity;
assigning a fixed monetary value to the pseudo cash unit;
dispensing the pseudo cash preliminary data packet from a pseudo cash dispenser to the first entity in exchange for the fixed monetary value received from the first entity;
regenerating the pseudo cash unit from the pseudo cash preliminary data packet by inserting the user key of the first entity into the pseudo cash preliminary data packet in accordance with the user insertion key of the first entity; and exchanging the pseudo cash unit for the fixed monetary value.

18. A method as recited in claim 17, comprising the additional steps of:
creating a file in a pseudo cash repository which contains the pseudo cash unit and the fixed monetary value;
deleting the file in the pseudo cash repository when the pseudo cash unit is exchanged for the fixed monetary value.

19. A method as recited in claim 17, wherein the pseudo cash unit is generated by the first entity.

20. A method as recited in claim 17, wherein the pseudo cash unit is generated by a money repository for the first entity by use of the user key and the user insertion key of the first entity.

21. A method as recited in claim 20, comprising the addition steps of:
creating a file in a pseudo cash repository which contains the pseudo cash unit, the fixed monetary value and means for identifying the first entity;
deleting the file in the pseudo cash repository when the pseudo cash unit is exchanged for the fixed monetary value.

22. A method as recited in claim 21, comprising the additional step of:
maintaining a record of the exchange of the pseudo cash unit for the fixed monetary value that includes means for identifying the first entity and the identity of who exchanges the pseudo cash unit for the fixed monetary value.

23. A method as recited in claim 17, wherein the pseudo cash preliminary data packet is dispensed to the first entity by electonic means.

29. A method as recited in claim 17, wherein the pseudo cash preliminary data packet is dispensed to the first entity more than once.

25. A method for providing pseudo cash transactions between a first entity and a second entity through use of a pseudo cash repository, comprising the steps of:
generating a pseudo cash preliminary data packet in the pseudo cash repository;
generating a pseudo cash unit in the pseudo cash repository from the pseudo cash preliminary data packet, a user key of the first entity and a user insertion key of the first entity by inserting the user key of the first entity into the pseudo cash preliminary data packet in accordance with an algorithm that uses the user insertion key of the first entity;
assigning a fixed monetary value to the pseudo cash unit by the pseudo cash repository;
generating a record of the pseudo cash unit and the fixed monetary value in the pseudo cash repository which is activated by transferring the fixed monetary value from the first entity to the pseudo cash repository and which remains active until it is deactivated by the pseudo cash repository;
dispensing the pseudo cash preliminary data packet from a pseudo cash dispenser to the first entity;
generating the pseudo cash unit from a pseudo cash data packet converter by inserting the user key of the first entity into the pseudo cash preliminary data packet in accordance with the algorithm that uses the user insertion key of the first entity;
transmitting the pseudo cash unit from the second entity to the pseudo cash repository;
verifying that the pseudo cash unit matches the record of the pseudo cash unit which is still active;
deactivating the record of the pseudo cash unit; and transferring the fixed monetary value from the pseudo cash repository to the second entity.

26. A method as recited in claim 25, wherein the pseudo cash unit is generated by the pseudo cash repository by use of the user key and the user insertion key of the first entity which are stored in a first entity account file of the pseudo cash repository associated with the first entity.

27. A method as recited in claim 26, wherein the record of the pseudo cash unit includes means for identiying the first entity.

28. A method as recited in claim 27, wherein the fixed monetary value is transferred from the first entity to the pseudo cash repository by transferring the fixed monetary value from a monetary account associated with the first entity account file to the pseudo cash repository.

29. A method as recited in claim 28, wherein the pseudo cash preliminary data packet is dispensed to the first entity from a pseudo cash dispenser by an automated teller machine.

30. A method as recited in claim 28, wherein the pseudo cash preliminary data packet is dispensed to the first entity from a pseudo cash dispenser over an electronic communication medium.

31. A method as recited in claim 25, wherein the fixed monetary value is assigned to the pseudo cash unit as a result of a communication between the first entity and the pseudo cash repository.

32. A method as recited in claim 25, wherein the pseudo cash preliminary data packet is a string of at least eight characters.

33. A method as recited in claim 32, wherein the user key is a second string of at least four characters.

34. A method as recited in claim 33, wherein the user insertion key is a third string of numeric characters that has an identical number of characters as the second string, each of the numeric characters of the third string being unique as compared to the other numeric characters of the third string.

35. A method as recited in claim 25, wherein the pseudo cash data packet converter is a computer program located in a computer.

36. A method as recited in claim 35, wherein the algorithm is periodically revised.

37. A method as recited in claim 35, wherein the algorithm also inserts a fourth string of characters into the pseudo cash preliminary data packet.

38. A method as recited in claim 37, wherein the fourth string of characters identifies the pseudo cash repository.

39. A method as recited in claim 25, wherein the first entity and the second entity are the same.

40. A method as recited in claim 25, wherein the pseudo cash unit is transferred from the second entity to the pseudo cash repository over an electronic communication medium.

41. A method as recited in claim 25, wherein the record of the pseudo cash unit includes means for identiying the first entity.

42. A method as recited in claim 41, further comprising:
maintaining a record of the transfer of the fixed monetary value from the pseudo cash repository to the second entity that includes means for identifying the first entity, the second entity and the fixed monetary value transferred from the pseudo cash repository to the second entity as a result of receipt of the pseudo cash unit.

43. A method as recited in claim 41, further comprising:
dispensing the pseudo cash preliminary data packet from the pseudo cash repository to the first entity more than once.

44. A method as recited in claim 41, further comprising the steps of:
searching for any active record maintained by the pseudo cash repository that is associated with the first entity; and dispensing the pseudo cash preliminary data packet associated with any active record located by the search to the first entity.

45. A method as recited in claim 25, wherein the pseudo cash unit is generated in the pseudo cash repository by the first entity.

46. A method as recited in claim 45, wherein the record of the pseudo cash unit generated in the pseudo cash repository does not include means for identifying the first entity.

47. A method as recited in claim 46, wherein the record of the pseudo cash unit is deleted when it is deactivated.