WO1998017045A1 - Reprogrammable wireless local loop phone capable of emulating a wireline phone - Google Patents

Abstract

A wireless local loop phone (10) is provided that accepts payment from a variety of sources for wireless calls. The phone (10) emulates, with a speech processor (40) having dial (42) tone generator and a DTMF tone generator (44), a standard telephone set by providing dial and DTMF tones to the earpiece of the handset (12). The speech processor (40) may also play audio prompts that provide instructions or advertisements. A display (20) provides operating instructions to the user, as well as an accounting of call cost and remaining credit. A phone management system (100) communicates with a number of the phones (10) to download new rate and dialing plan information, change stored visual and audible prompts and retrieve accounting data to create call statistics.

Description

REPROGRAMMABLE WIRELESS LOCAL LOOP PHONE CAPABLE OF EMULATING A WIRELINE PHONE

The present invention relates to a wireless local loop phone that can emulate a wireline phone, accepts various forms of payment and is reprogrammable.

BACKGROUND OF THE INVENTION

Evolving telecommunication technology has engendered many systems through which users can communicate. Included in the wide array of choices are: the wired, Public Switched Telephone Network ("PSTN"), Private Branch

Exchanges, paging systems, Local Area Networks, ATM networks, Wide Area Networks, Metropolitan Area Networks and wireless networks.

Numerous countries throughout the world lack a wired PSTN. However, installing networks of wires for wired PSTN service not only is costly, it also is time consuming and leaves many potential customers without service in the interim.

One solution is to deploy wireless networks like cellular or PCS networks. Cellular networks use multiple independent cellsites connected via a dedicated network (usually leased lines or microwave) to a Mobile Switching Center ("MSC") that is then connected to the PSTN. The MSC handles all call processing intelligence, switching functionality, fault detection and diagnostics.

MSCs are also integral to operation of recently developed Personal Communication Systems ("PCSs"). A PCS uses "microcells" that blanket a high use area, or an area where terrain features limit transmission capabilities (e.g., a downtown office district with tall buildings). Because of the greater number of cells, the PCS can handle a significantly greater volume of traffic. A low power transmitter within each PCS microcell receives the subscriber's signal and communicates (normally via microwave public telephone company or data lines) with a controller, which in turn communicates with the MSC. Because such ne' rks allow for mobile communication, they may be a better long term solution than installing an expensive wired network. Moreover, in countries lacking a wired base, such networks can be deployed quickly and more efficiently.

But an enormous market of potential customers effectively cannot be serviced even with wireless and PCS networks. That is because many countries lack the infrastructure needed for billing and collection. Further, despite numerous forms of fraud detection and prevention systems, cellular and PCS networks are notoriously suspect to fraud losses from users who manipulate the networks to obtain telecommunications services without payment. Also, those users familiar with wired telephony signaling protocols may not feel comfortable using wireless phones, which typically lack the dial tone, DTMF tones and other signaling protocols of standard, wired telephones. Wireless phones require use of a "Send" button to initiate a call. These differences render wireless phones awkward, unfamiliar and less attractive to many potential customers.

U.S. Patent Nos. 4,658,096, 4,775,997, 4,922,517, each to West, Jr., et al., and 4,737,975 to Shafer describe interface systems by which a user can use a familiar, standard telephone set with a cellular radio transceiver. "The interface system converts tone-dial or pulse-dial inputs from the telephone into a serial data stream for storage in the transceiver." Such conversion is required because the radio transceiver is used with "a standard telephone set." The Shafer patent describes a "programmable" interface system that "automatically determines when the last numeral or digit is dialed for a particular area telephone system."

But the interface systems described in the West, Jr., et al. and Shafer patents add another layer of cost and expense into the phones. Not only must the user have a standard wireline telephone, but the interface and cellular radio also must be purchased.

Thus, it would be cheaper to provide cellular or PCS phones to users. Such cellular and PCS phones require a high level of maintenance, however. Phones must be constantly reprogrammed and maintained — sometimes by inexperienced or inadequately trained technicians. SUMMARY OF THE INVENTION

This invention addresses these and other problems by providing a wireless local loop phone that: emulates a standard, wireline telephone; rates incoming and outgoing wireless telephone calls; accepts a variety of forms of customer payment, including pre-paid cards or credit cards; can be remotely reprogrammed and can self-diagnose maintenance problems in order to minimize intervention by service technicians. Other features are also provided, including optional printing of credit or call detail information, programming that allows the phone to provide visual or audio information in multiple languages, a management system for managing a number of wireless phones or a display for showing the current call cost and credit remaining to the user.

The phone of the present invention couples a microprocessor, speech processor and handset via a digital bus to a transceiver for communicating with a wireless network, such as a cellular, trunked radio or satellite network. Users may remove the handset off-hook and enter a desired telephone number into the handset. Upon off-hook detection, the microprocessor controls the speech processor to generate dial tone, which is provided to the ear piece of the handset. The speech processor also can access a memory in order to provide voice prompts such as instructions, advertisements, or even call progress data. A user then inputs through the keypad a desired telephone number. A

DTMF generator is activated from the matrix output of the keypad through the modem in order to provide to the handset the tones associated with the selected key position. Those tones, however, are not sent to the transceiver. The microprocessor controls an analog-to-digital converter that sends the transceiver the dialed numbers in digital format via the digital bus.

The microprocessor constantly checks the buffered numbers against a stored dialing plan to determine whether the user has entered a valid telephone number. Upon a match, the microprocessor first checks to determine whether the user has paid for the call. That can be done by having the user insert a pre-paid or credit card into an appropriate card reader. The card is verified and, optionally, an initial charge for a selected (e.g., two minute), call to the dialed number is deducted from the value held in the pre-paid card or stored in memory for later charging against the credit card, whose card number, expiration date and user name is collected and stored. The initial and subsequent charges are determined by having the microprocessor rate the call based on a call cost rating database. A display shows the user the credit remaining on the card, the charge for the call or the call time left.

After (1) the buffered numbers are determined to match a valid telephone number and (2) initial payment, the microprocessor sends the complete number to the transceiver, along with a "send" command. This initiates the call. A preselected interval before the user's initial credit lapses, the microprocessor checks the particular authorized credit amount available to the user by checking the credit remaining on the pre-paid card or stored in the phone against the current call cost to determine whether to allow the call to proceed. For user credit card calls, the microprocessor may simply allow the charge to accumulate for later billing or it may cut off calls whose cost exceeds a certain threshold value.

Accounting data like call start time, stop time, dialed number, cost and credit card details may be stored by the microprocessor. A phone management system uses a computer to program remotely a number of the phones and to retrieve such accounting data and formulate it into useful call statistics or billing information for the wireless service provider. Additionally, the phone management system can be used to diagnose remotely maintenance problems and assist with maintenance of down phones, which can initiate communication with the phone maintenance system by calling in on the line. Such remote calls from the phone to the maintenance system may also be initiated at selected times, when the phone's memory is filled with accounting data or even during acts of vandalism.

The phone on the present invention may be used as a true wireless public telephone that allows multiple types of pre-payment for outgoing and incoming calls. The phone simulates a land line telephone operation using a cellular, trunk radio or satellite handset and sends the same handset commands to a compatible microprocessor-control transceiver. Alternatively the phone on the present invention may be deployed in fixed locations, such as at a user's home or office, and used on a pre-payment or credit card basis. This allows the service providers operating the phones to receive guaranteed payment if a pre-paid card is used, or if a credit card is used, to receive payment without the necessity of establishing a separate billing and collection procedure from the credit card company.

It is accordingly an object of the present invention to provide a local wireless loop phone that eliminates the need for a centralized billing system or the extension of credit by the telephone company in administration of a wireless telephone system. It is another object of the present invention to provide a wireless local loop phone that rates calls and accepts payment from credit or pre-paid cards, either by allowing the card to escrow the credit and altering the balance following use or by escrowing the credit within the memory of the phone.

It is an additional object of the invention to provide a wireless local loop phone that may emulate a standard telephone.

It is a further object of the invention to provide a wireless local loop phone with a speech processor capable of delivering audio signals to the handset for communicating with the user.

It is yet another object of the invention to provide a wireless local loop phone that is reprogrammable and easy to service.

It is an additional object of the invention to provide a wireless local loop phone adapted to emulate a wireline phone, rate incoming and outgoing wireless communications, accept a variety of forms of customer payment, be remotely reprogrammed, run self-diagnostics, or display advertisements, prompts or payment information.

Other objects, features and advantages of the present invention will become apparent upon reading the rest of this document.

BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 shows a perspective view of the wireless local loop phone of the present invention. Figure 2 is a block diagram of the components of the wireless local loop phone of the present invention.

Figure 3 is a flow chart illustrating operation of the microprocessor 30 of the wireless local loop phone of the present invention. Figure 4A and 4B are flow charts illustrating the call initiation and rating processes.

Figure 5 is a flowchart illustrating the use of a pre-paid card to escrow credit within the wireless loop phone of the present invention.

Figure 6A is a block diagram of the components of the phone management system of the present invention.

Figure 6B is a flow chart illustrating the processing logic of the phone management system of the present invention.

DETAILED DESCRIPTION OF THE DRAWINGS Figure 1 shows a preferred embodiment of a wireless local loop phone 10 according to the present invention. A standard handset 12 couples to the phone 10 and a keypad 14 accepts a number from the user. To emulate a conventional wired phone, the handset 12 of phone 10 may use either a carbon microphone earpiece system or a microphone/speaker handset 12. A pre-paid card reader 16 allows the user to input credit for a call into the phone 10. For instance, the pre-paid card reader 16 may be one that accepts embedded chip cards, 9-mil cards or so-called Kapsch cards that use an embedded chip and have an inductive coupling device, a capacitive device, both or other coupling devices (including magnetic) for remotely interfacing with the card reader 16. A second, credit card reader 18 may also be provided. Available credit may be shown to the user via the display 20. That credit begins decreasing after the user pushes a start button 15. The phone 10 may also have a port for coupling with a computer or other digital device (e.g., a facsimile machine, personal digital assistant, etc.) in order to allow data to be transmitted through the phone 10. Figure 2 shows, in block form, the internal components of the phone 10, which components are powered by the power supply 70 that may include an AC prime power source, a charger, battery or regulator. Power supply 70 regulates power to supply both twelve volt and five volt power for the phone 10 and logic circuitry within the phone 10. The handset 12 couples to a speech processor, multiplexer and dialer 40. Speech processor 40 multiplexes for multiple or independent access a number of inputs, such as inputs from the handset 12, a dial or DTMF tone generators 42, 44, or a memory 41 in which audio prompts are stored. A switch 28 couples the speech processor 40 to a transceiver 24. Microprocessor 30 controls the switch 28 so that when a call is not being made through the speech processor 40 microprocessor 30 can, at times, send data through the transceiver 24 via a modem 26. Microprocessor 30 may be any suitable Intel, Motorola, National Semiconductor or similar microprocessor.

Microprocessor 30 also draws from a memory 32, which can be an EPROM chip or equivalent, appropriate instructions for sending to display 20, which could be a low cost, readily available two line, twenty character per line vacuum florescent display. Different displays 20, like a liquid crystal display or the like, could also be used, so long as the display 20 is capable of showing the user call cost and remaining credit or time. Stored speech processor 40 allows microprocessor 30 to send stored, audible voice prompts from memory 41 to the handset 12.

Microprocessor 30 controls the functional operations of the phone 10. Those functions and the instruction set reside in memory 32. Memory 32 can be random access memory, RAM, or read only memory, ROM. For instance, the operating system described below may reside in ROM and the visual and speech information may reside on RAM. Memory 32 additionally may store details or multiple prepaid or credit calls and tables for rating the cost of such calls.

Microprocessor 30 may also be provided with a real time clock, used for determining the proper care and time. This information is helpful in rating the cost of incoming and outgoing calls. 1. Operating System: The flash ROM contains the BIOS (operating system) of the microprocessor 30. The BIOS may be a modified version of ROM DOS, produced by Datalight Corporation, or any other suitable operating system. This basic instruction set determines the actions of the microprocessor 30 including its control of the speech processor 40; display 20; the various card readers 16, 18; the microcontroller for the bus 50; access to the various RAM segments within memory 32 (e.g., those that are used for determining the number of digits used for dialing, and the dialing patterns; the rates to charge for the time periods that are used based upon the entered destination of the end user); the transceiver 24 conditions; the modem section that communicates with the Remote Management System 100; how to deal with the interrupts from the hook switch, handset 12, keypad 14, and "Start" switch 28; the progress of a call including the startup, setup, connection and disconnection phase; the interconnection of all accessory items like a printer for customer receipts, an RJ11 external 30 milliampere loop for computer fax or remote connection, additional credit/debit cards and any other accessories that a service provider adds. 2. Visual and Speech Memory:

Visual RAM holds the visual displays that are interconnected to the "on hook" (idle state) or call progress functions. The messages can include advertisements, operating instructions, state of the call, charges for the call, value of the payment instrument, and language chosen by the end user for usage.

Speech RAM has all of the prompts used in the languages offered by the vendor of the phone 10. The individual words have specific locations, and the locations can be attached together to form sentences, with time pauses between the words. The words can be in multiple languages, which usage is chosen by the interrogation of the end user when the initial call set up is being made. Both visual and speech RAM can be changed via uploading or downloading new information. The visual RAM is connected to the speech RAM, so that the actual language displayed is the same language selected by the customer. Phone Operation 1. Messages to the User:

Figure 3 shows the operation of phone 10. Upon application of power, a microprocessor 30 boots up and activates the display 20 to show operating instructions, advertisements or a combination as directed by the service provider. Display 20 shows the destination digits entered into the keypad 12 as well as the charge to the user for an initial call period. Display 20 may also show the value of the form of payment (e.g., pre-paid card 17) submitted or the credit card number if a credit card 19 is used. Visual or audible prompts could be provided by the microprocessor 30 upon detection of a change in status of a hook switch 11. Or, such prompts could be provided when the microprocessor 30 receives data into buffers labeled SP0 and SP1 that respectively connect to pre-paid card reader 16 that accepts pre-paid telephone cards 17 and credit card reader 18 that accepts standard credit cards 19. Those audible voice or visual prompts could be instructions or advertisements, either of which can be changed via remotely reprogramming the phone 10 through a Phone Management System 100 (shown in Figure 6 and described below in associated text).

Operating instructions tell the user to lift the handset 12 to place a call. When the user lifts the handset 12 off the switch hook 36, an off-hook detector informs the microprocessor 30, which turns on the dial tone generator 42 located in the speech processor 40. The user thereby hears dial tone when he places the handset 12 to her ear.

Optionally, the microprocessor 30 may then show on display 20 a message that an alternate language is available by pressing the # key on the keypad 14. Pressing the # key toggles a pointer within the microprocessor software between two languages: e.g., English/Spanish, Spanish French, French/German, Chinese/Japanese, etc. Text for the languages is stored in memory 32 of the microprocessor 30; the pre-recorded audio prompts for those languages may be stored in memory 41 of the stored speech processor 46, which may be a MSM6650 (ORI) IC. Once the user selects a language, the microprocessor 30 provides future visual and audible prompts in that selected language. Visual messages are fetched from memory 32 as digital words and sent to the display 20 by the microprocessor 30. The audible prompts are requested by the microprocessor 30 and the embedded microcontroller recalls the message from its memory, performs the required digital to analog conversion, with filtering, and drives the audio line (marked A) into the speech processor 40, which then delivers the audio to the ear-piece of handset 12. Throughout the call and especially during call initiation, the user is prompted with audio messages in the language of his choice. The phone 10 is equipped with an array of "canned messages" in either of two languages that inform the user how to use the phone, the status of the call, etc. These can also include advertisements, like phone services. Additionally the user gets audible prompts as to the remaining credit on his card 17, 19. 2. Payment Check and Card Security:

Regardless of the language selected, audio or visual prompts direct the user to insert either a credit card 19 or a pre-paid card 17. Two card readers 16, 18 may be provided so that each type of card 17, 19 may be accepted. Or the phone 10 may be provided with just one type of card reader 16, 18. Following displayed or audible instructions, the user will either enter a pre-paid phone card 17 or draw his credit card 19 through the card reader 16, 18. The information from the inserted card 17, 19 therein is transferred to the card reader 16, 18 where it is held until transfer to the microprocessor 30. If a prepaid card reader 16 is used, a motorized mechanism such as a wheel or the like may pull the card 17 into the reader 16 and read the recorded data as the card 17 moves through. In the case of the pre-paid card 17 insertion, the card reader 19 reads certain codes, such as those recorded on a magnetized strip on the card 17. Those codes identify the issuing company, the card serial number, and the credit amount still remaining on the card 17. The pre-paid card reader 19 holds the card 17 until the entire call is finished and the hand set 12 is returned to the "on hook" position.

Microprocessor 30 continuously and sequentially checks the status lines from the card readers 16, 18. If either has data available, status lines so indicate and an interrupt service routine stops the microprocessor 30 from following its normal routine and causes it to service the reader 16, 18 in question. Thus, the microprocessor 30 immediately accepts, through one of the two dedicated, built in serial I/O ports, the data from either card reader 16, 18, which is stored in memory 32.

Microprocessor 30 checks the card's identification code against a stored list of stolen or invalid cards 17, and if stolen or otherwise invalid, mutilated, damaged or tampered with, returns the card 17 to the user with a message that the card 17 is invalid. If the card 17 is valid, the remaining credit (for a pre-paid card 17) is placed in a register to be used in further calculations. When a credit card 19 is used, the credit card reader 18 reads its information and sends it to a RAM cache in memory 32. Microprocessor 30 checks the card 19 information for valid digits, valid expiration dates, routing and PIN numbers. Microprocessor 30 can then run a comparison to a valid/invalid credit card database, which is stored in Memory 32 and updated remotely. Alternatively, phone 10 can also speed dial a real time on-line validation system. If an approval code is returned, that code is logged into the call record and the call proceeds. If a denial code is received, the call progress is stopped and the user is prompted to try another form of payment.

When there is no card 17, 19 inserted or card data to retrieve, the microprocessor 30 continues sampling other inputs and servicing any requesting action. An example of one continuing process is the servicing of the visual display 20. The microprocessor 30 writes a new letter to the display 20, the display 20 acknowledges receipt of the letter and then activates a status line that indicates that the display 20 is ready for the next letter. Meanwhile, the microprocessor 30 uses a clock 38 to calculate a preset time; after passage of that time, the microprocessor 30 sends the next letter to the display 20. This causes the message to scroll across the display 20.

3. Call Initiation and Rating:

In a "not busy," powered-up state the phone 10 continuously monitors the bus 50 for any activity emanating from the logic unit of the transceiver 24. If no activity exists, the phone 10 is free to place a call. Phone 10 may display in the interim welcome messages or advertising. When a user initiates a call by lifting the handset 12 "off hook" an interrupt is sent to the microprocessor 30. Microprocessor 30 services the interrupt and immediately initiates generation of dial tone by applying power to or otherwise activating the dial tone generator 42 associated with the speech processor 40 (which alone could provide dial tone, if properly configured to do so). Simultaneously, operating instructions are shown on the display 20. Messages shown on the display 20 are stored in the main memory 32 of the phone 10, recalled and passed to the display 20 under the control of the microprocessor 30.

Figures 4A and 4B illustrate this call initiation and rating process. Microprocessor 30 controls the display 20 or speech processor 40 to prompt the user to input through the keypad 14 the desired telephone number. Entering digits at step 140 turns off, through the microcontroller, the dial tone generator 42. As each key is depressed, a Dual Tone Multiple Frequency (DTMF) tone pair maybe applied to the handset 12 to be heard by the user. The tone pairs are the same frequencies used on a "Touch Tone" type telephone. The DTMF tone pairs are not used to actually dial the call. Rather, they are used to simulate a standard, wireline phone for the user of the phone 10. Thus, as each successive key is pressed, the DTMF generator 44 produces tones associated with the selected key. Those tones are delivered to the handset 12 but are not sent to the transceiver 24. Simultaneously, the keypad 14, via a connection to a front end gate array, sends the selected key to an analog-to-digital converter coupled to the microprocessor 30 of the phone 10. Microprocessor 30 buffers the digital number and also sends it to the transceiver 24 via the bus 50.

An interdigit timer is set (e.g., via software at the customer's request) after each digit and if a selected period (e.g., three seconds) expires before the next key is depressed, the microprocessor 30 assumes dialing is complete and attempts to place a call to the number dialed. Alternatively, microprocessor 30 performs a digit analysis that determines when dialing is complete by constantly checking the buffered numbers against a dialing plan stored in the phone 10. Upon a match, the microprocessor 30 determines that a complete valid number has been dialed. The digit analysis determine whether the end user has entered valid digits by comparing the entered numbers to a dialing plan loaded into phone 10's memory to determine whether the numbers are a free call, local, toll or international destination or a destination that does not exist. If the digit analysis determines that random numbers were entered or a "fat finger" error occurred, the call is terminated and the user notified. Once the destination of the call has been determined, the digit analysis results are sent to a rating process 150 (see Figure 4B) that determines the rate to charge for the call.

In any event, each complete dialed number is sent to the transceiver 24 formatted as described above and a SND command is issued if sufficient credit remains on the card 17, 19 to place the desired call for a selected minimum time period (e.g., two minutes). To do that, microprocessor 30 communicates with the transceiver 24 and requests that it send the dialed numbers (destination number) to the appropriate cellsite. Transceiver 24 stores the destination numbers until it receives the digital "send" command from the microprocessor 30. Transceiver 24 then initiates the out- going call. Typically, this involves: scanning channels for a radio link with a base station at a nearby cellsite; scanning the available systems to determine the best radio link; and locking onto a particular cellsite. Various messages are exchanged between the transceiver 24 and the microprocessor 30 to set up the call properly. Transceiver 24, in turn communicates with the cellsite, passing on its registration number, its telephone number and the dialed number. If the phone 10 receives a supervisory control message that indicates the call cannot be completed, the microprocessor 30 terminates the call and displays a message describing the problem, e.g., "Your call cannot be completed at this time. Please hang up and try again later."

When the proper supervisory messages have been exchanged and the call is being initiated, microprocessor 30 mutes the user's transmitter (microphone), but leaves open his handset 12 receiver so that he can hear the ringing signal and the called party answer. When the call is answered and the user hears the called party's voice, the user, following a visual prompt on display 20, must push the start button 15 to cause the microprocessor 30 to un-mute the mouthpiece of handset 12 so the conversation can begin. Simultaneously, the microprocessor 30 debits enough credit, stored in the credit register, to pay for the preselected time period (e.g., two minutes). Also, the microprocessor 30 records the start time in memory 32 for call accounting and starts a clock 38 to record the elapsed call time. Clock 35 may be a real time clock such as a DS 1302 coupled to a supercapacitor for back-up power and provided with a watchdog program for power failures.

Cellular, satellite and trunked radio standards traditionally did not support answer supervision. Only the more recent CDMA standard supports answer supervision and allows end office progress tones to be passed back to the phone. As a substitute for answer supervision, some service providers have modified their switches to produce a DTMF or fourth column tone upon receiving an answer supervision signal from the wireline end office. Accordingly, microprocessor 30 may be equipped with a receiver circuit to acknowledge that tone if presented by the service provider. Microprocessor 30 would then, upon reception of the predetermined tone signifying answer supervision, send a signal to automatically release the mute condition, allow the user to communicate, record the start time and charge the user for the initial time period of the call. Alternatively, the phone 10 could be provided with Digital Signal Processing chips that could process the sound information received from the called party and the calling party to determine whether and when a conversation was initiated. Status lines could then interrupt the microprocessor 30 in order to start recording the call time.

Before actual call completion, microprocessor 30 initiates a rating process 150 that determines the "per minute rate" of the dialed destination. Briefly, the rating process 150 determines the distance the call will travel, the time and the day of the week, and references the rate structure provided by the service provider in order to determine the proper charge for the initial, and subsequent, portion of the completed call. Service provider to phone 10 determines the basic monetary rate for the time the phone 10 is used.

Charges may be based upon the airline distance of the phone 10 to the destination called and the call classification. Three typical classifications are time of day, day of week and whether the call is local to the area, toll out of the area (long distance) or toll to another country (international). For instance, daytime may be full rate, evening may be at 0.75 of full rate, or night may be at 0.5 of full rate. The day of week may also include a discount, with Monday through Friday at full rate, Saturday at 0.5 of full rate and Sunday at 0.75 or 0.5 of full rate. Distance, multiplied by time, rate and any discount determines the final amount to be charged to the customer for the actual usage. Surcharges, taxes, or other special charges or discounts (e.g. for holidays) are added from an exception table in memory 32 that is also provided by the phone 10's service provider and can be used to show the final charge for the total call or each part of the call that is completed. 4. Call Progress and Termination:

In any event, the new balance is stored where the original credit was stored (e.g., either on the card 17 or in memory 32). Meanwhile, throughout the telephone call the remaining credit is shown on the display 20, which also shows the remaining call time in the current, paid-for interval (i.e., the initial two minute interval or the current one minute interval). These may be bar-graph or other type displays. At the end of a set time (e.g., 1.5 minutes), and preferably for chosen intervals (e.g., a minute) thereafter, the microprocessor 30 checks to verify that sufficient credit remains for another minute of connect time. If so, the call process continues and the credit check procedure repeats. But if insufficient credit remain, the microprocessor 30 flashes display 20, which then shows instructions the user to insert another card 17. Some additional free time or grace period may be allowed (e.g., ten seconds), but if no new card 17 (with sufficient credit) is inserted, the call will be terminated and the card 17 ejected.

Microprocessor 30 continuously monitors the data lines and intercepts, decodes and reacts to (when called for) message from the transceiver's logic unit. If the circuit connection fails and this is reported to the phone 10 by the transceiver 24, the call will be terminated. The call is also ended by the microprocessor 30 sending an END command to transceiver 24 when the user returns the handset 12 to the "on hook" position by placing the handset 12 in its cradle. When the call is completed the call duration is added to a statistical file for accounting data on calls made from phone 10. The call statistics consist of the year, month, day and time of call initiation, duration of call and the called number.

Final deductions are made from any pre-paid card 17, the new balance is displayed and recorded magnetically on the card 17 and the card 17 is ejected from the reader 19 for return to the user. The phone 10 then displays a "thank you" type message and returns to the idle and ready mode. The remaining call statistics are recorded and held in memory 32 for later uploading to the Central Office on request.

A credit card 19 call may progress in much the same way as the pre-paid card 17 call described above with the exception that there is no debiting of the credit card 19. The total cost of the call together with the credit card 19 number, expiration date, etc. is recorded for later uploading to the central office or a central computer for billing. Alternatively, if the wireless service provider so decides, the phone 10 can be configured to call in to pre-authorize each credit card call, as previously described. 5. Incoming Calls: Phone 10 may be configured as a stand-alone public phone or wireless local loop phone. If configured as a public phone, phone 10 will not accept incoming calls because there will be no method of billing the user before accepting the call, although phone 10's modem may be configured to answer the call after a selected number of rings in order to allow remote programming. As a wireless local loop phone, phone 10 activates an external ringer upon receipt of an inbound call. Additionally, phone 10 may activate the real time clock 35 in order to begin timing the call. If provided with a caller identification feature, phone 10 will also begin rating the call in order to charge the user.

Internal Messaging In the embodiment shown in Figures 1 through 3, bus 50 may be a Motorola

3-wire digital bus. Voice and data signals originating from and going to the phone 10 pass through a transceiver 24, such as one manufactured by Motorola. The transceiver 24, in turn, communicates with a particular selected cellsite via electromagnetic waves. Transceiver 24 responds to command and control signals from the microprocessor 30 of the phone 10. Transceiver 24 also receives, responds to and passes through to the phone 10 status signals received from the cellsite.

The bi-directional communication between the microprocessor 30 and the transceiver 24 may be carried over the three wire digital bus 50 using a priority message protocol developed by Motorola, as described in Motorola's "3-wire bus peripheral messaging specification," which document is hereby incorporated in its entirety by this reference. Generally, the three data lines, referred to as the C-Data (Complement Data), the R-Data (Return Data) and the T-Data (True Data) lines, are buffered and shaped, but otherwise connect directly between the transceiver 24 and the microprocessor 30. Each of the three lines are always in either a "true" (high) state or a "false" (low) state. Information is contained on the bus 50 by virtue of the relative states of the lines and also by the absolute changes of a single line. For example, if both the C-data and T-data lines are low (0, 0) the transceiver 24 is in the reset state. As a further example, if the microprocessor 30 takes the R-data line low from a high condition, that signals the transceiver 24 that the microprocessor 30 is sending a message to the transceiver 24. A logic unit within the transceiver 24 controls the timing on the bus 50.

At selected intervals (e.g., about once a minute), the transceiver 24 checks the status of the phone 10 by issuing a status request message on the bus 50. Microprocessor 30 responds, typically within a set time period (like thirty seconds or so). For example, a "Switch Hook" code may be sent to the transceiver 24. The switch hook code may be $IF (a hexadecimal number equal to sixteen). This switch hook code indicates that the phone 10 is classified as a secondary peripheral, which means that messages through the transceiver 24 to activate or deactivate a call must use a Send (SND - begin) and END (terminate) message. Phone numbers that the microprocessor 30 determines are complete and valid, result in the microprocessor 30 sending the "SND" command to the transceiver 24 via bus 50. Similar commands are sent via bus 50 to the transceiver 24, when appropriate. When the phone 10 sends a message to the transceiver 24, the transmitted message must conform to the prescribed format. For instance, the sixteen bit message may have an address (four bits) followed by a destination code (four bits) which is, the turn, followed by a data field of eight bits. Each message on the bus 50 must consist of sixteen bits or it is ignored.

In any event, through this regular exchange of status data, the transceiver 24 knows that the phone 10 is handling an in-progress call or is operative but idle due to lack of traffic.

Phone 10 must be able to receive all bus 50 traffic at all times and, to this end, may have an interrupt generator that detects both positive and negative transitions in the T-data and C-data lines of bus 50. The resulting interrupt is presented to the microprocessor 30, which immediately services the interrupt, receives traffic addressed to the microprocessor 30 and decodes that traffic.

Stored-Value Card Reader Operation There are two basic ways of operating phone 10 with pre-paid card 17. Either the credit on card 17 may be left on the card and altered by a card reader/writer after use (as described above) or the credit may be escrowed within memory. This second alternative embodiment of the invention, described below and in Figiure 5, uses the card reader 15A shown in Figure 4. Card reader 15 A, whose physical components are manufactured and available from Xico, Inc. of 9737 Eton Ave., Chatsworth, CA, is configured as a stored value card reader. Typical card readers both "read" a card to determine its value and have a mechanism for writing over the card value to account for a charged amount. The "writing" action is important to make sure the card 17 is not left with the same value, which would allow the user to re-use card 17 and obtain services free of further charge.

By contrast, card reader 15A works with a stored value card 17a to read the entire value of the card 17a into the memory 32 of the phone 10. Thus, the writing mechanism may be eliminated from card reader 15 A, which provides substantial cost savings. There are many methods of configuring and operating card reader 15 as a stored value card reader; three illustrative methods are described below and Figure 5. 1. Single Phone Card:

Stored value card 17a may be issued for use with a selected phone 10 and include at least the following information: serial number for the phone 10; transaction code and credit amount. Typically, stored value cards 17a will be obtained from an issuing station located as a public dispensing machine, at a retail outlet or at a wireless service provider's business location. These issuing stations use a swipe encoder connected to the RS 232 port of a PC host computer that has a separate serial port for connection to the phone 10. The user (after cash or other payment) enters the desired card value into the PC host, which forwards that information, the serial number of the user's phone 10 and other data to the encoder. The encoder generates a UNIX time stamp which acts as a unique transaction code, encrypts into the card 17a the phone 10 serial number, the card value and the UNIX time stamp or some other unique transaction code. The PC host stores that transaction information in order to maintain a trail for later auditing. The user inserts stored value card 17a into card reader 18a, which confirms the card's 17a validity and reads the information from the card 17a. This transfers the entire card 17a value (e.g., $50) to the memory 32 of the phone 10. Card reader 18a may be configured either to read upon insertion of the card 17a or to read upon its withdrawal. Card reader 18a decrypts data on card 17a and sends all the data to the phone 10's microprocessor 30. Microprocessor 30 validates the data, and if valid adds the new card value to its memory 52 and updates its transaction code files with the transaction code or the card 17a. The information stored in card 17a, however, is left unchanged because unlike ordinary card readers, reader 17a lacks an encoder. Optionally, phone 10 may display for the user the value of pre-paid card 17a or number of credit cards 17b. Or, green and red LEDs can be used to let the user know credit is or is not available.

Validation is done in order to ensure no lost or stolen card is wrongly used. This can be done simply by checking information on the card 17a with information on lost or stolen cards 17a that may be periodically downloaded to the phone 10 by the Phone Management System 100, shown in Figure 6. Suppose, however, that the user consumes the entire $50 credit by using phone 10 and then tries to reuse the card 17a that still holds a $50 credit with the phone 10 or another phone. To prevent this, as shown in Figure 5, the phone 10 is programmed to determine whether (1) the serial number stored on the card 17a matches a stored serial number of the phone 10 and (2) the transaction code or identification (e.g., the UNIX time stamp) stored on the card 17a matches a transaction code or identification already stored within the transaction files of phone 10 from previous cards 17a. If either the serial number does not match or the transaction code does match, the stored value from the card 17a will not be transferred to the phone 10. In this manner, the phone 10 rejects already used cards 17a, even though the information on the cards 17a is the same as before their use because card reader 18a does not overwrite cards 17a. 2. Vending Phone Card:

While highly secure, single phone card 17a can be used only with a single phone 10, requiring the card 17a to be issued with the phone 10, preselected. Two alternative methods exist for eliminating this disadvantage.

First, card 17a may be made available through a vending machine. The customer inserts cash or credit into the venting machine and enters the mobile number, ESN or other identifier for phone 10. Card 17a may be encoded with that identifier plus the unique transaction code (e.g., a time stamp). Validating proceeds as shown in Figure 5.

Alternatively, rather than requiring users to program a card 17a with a particular mobile number, card 17a can be encoded only with a unique transaction code. This is especially useful when numerous phones 10 have been configured to validate based only on the transaction code. This method, however, requires phone 10 to be programmed to erase the card 17a to prevent a user from re-using it with other phones. Because card 17A may be block erased, no "write" hardware need be supplied with card reader 16 A. Optional Features

1. Value- Added Features.

During the call, the user may desire to provide DTMF tones to interface with an automated system (e.g., an information system, company directory, ordering system, etc.). To do so, the user simply presses the numbers in the keypad 14, which activates either a DTMF tone generator built into the transceiver 24 or the DTMF tone generator 44. Alternatively, after acknowledging the "send" command via the bus 50, the simultaneous analog- to-digital conversion of the keypad 14 signals stop, microprocessor 30 determines that a call is ongoing, and DTMF signals are thereafter passed from the handset 12 to the transceiver 24 for transmission. This allows the DTMF tones to be heard by remote devices in telecommunication with the phone 10 that required DTMF tones for operation.

Because the phone 10 is wireless, it may also be a mobile phone, mounted for instance in a vehicle like a bus, subway car, airplane or taxi. In that event, the user may desire a receipt, in which case the phone 10 can be equipped with a printer, such as a thermal printer on the like. The receipt may record the date, time of day, day of the week, called number, number of minutes and call charge.

2. Remote Programming.

The wireless service provider servicing phone 10 can use the Phone Management System 100 to reprogram the phone 10 to favor particular "SIDs"

(wireless System Identification Numbers). Thus, phone 10 may be provided with a "preferred" list of SIDs for the phone 10. As the phone 10 moves into a new area, the phone 10 monitors the network control channels for the SID of each service provider within the area, compares each SID with the list, and, upon a match, chooses to make calls through the preferred SID. The list may be updated or changed through remote programming sessions between the phone 10 and the Phone Management System 100. Of course, similar results could be obtained by programming phones 10 to avoid particular SIDs. Using either method, a particular wireless service provider can program phone 10 to prefer itself or entities associated with it, thereby enhancing its revenue stream. When the phone 10 is not in use, a switch (controlled by the microprocessor 30) connects the audio paths of the radio transceiver 24 to the audio path of the modem 26, thereby cutting out the inputs from the handset 12. In this default mode the phone 10 may always accept an incoming call from the central office or Phone Management System 100 for uploading statistical data or downloading rate table updates. During low traffic hours, Phone Management System 100 can call individual phones 10 (or vice versa) and download the most recent traffic rates, dialing plans, etc. For instance, phone 10 can be programmed remotely with new prices of local, forming, long distance, "800" or international calls or the price of inbound calls or service requests. Each phone 10 can report its maintenance status to the Phone

Management System 100 upon request, at a preselected call-in time or as local fault detection circuits determine. Revised visual display 20 messages can also be down loaded in this way.

Alternatively, instead of making an expensive cellular call between each of phones 10 and the Phone Management System 100, phones 10 can be provided with the capability to send and receive data over the cellular control channel, preferably during low traffic periods on the network. Apparatus and methods for implementing that procedure are described in U.S. Patent No. 5,546,444, which document is hereby incorporated in its entirety by this reference. In any event, the visual display 20, the memory 32 and the modem 26, for instance capable of between 300 and 9600 Baud operation and provided with built- in error detection and correction algorithms and the entire AT command set, are all connected to the bus 50. Also, an RJ11 jack may be incorporated in the phone 10 in order to provide an external fax machine or modem for the user. A call may be placed by using either on-hook or off-hook calling. For instance, for on-hook calling, the microprocessor 30 detects a load across the leads of the RJ 11 jack, and causes the dial tone generator 42 to generate artificial dial tone. Voice prompts are disabled by the microprocessor 30, which still provides visual prompts in order to show the progress of the call. As in a voice communication, a pre-paid card 17 or a credit card 19 must be inserted to allow the call to proceed. After call completion, the external device returns to the on hook position and the phone 10 terminates the call as described above.

Alternatively, for off hook calling, the communication through the RJ11 jack proceeds just like a normal call, with the user initiating the call by removing the handset 12 from the hook.

Bus 50 may be an external, bi-directional, twenty bit digital bus, through which flows commands from and information to the microprocessor 30. Such a bus 50 would make the phone 10 of the present invention interchangeable with various transceivers and wireless networks. For instance, phone 10 may be easily modified and configured to work with various cellular, PCS, satellite and trunked radio networks. Similarly, the phone 10 can be used with other manufacturers' transceivers 24, provided those transceivers 24 interface with a digital bus 50. The transceiver 24 can be programmed by having a programming card inserted into the prepaid card reader 18. Microprocessor 30 accesses information on the programming cards such as sequence codes for the transceiver 24. Those same codes are echoed to the display 20. Thus, the technician can enter a new "SID" or a new mobile telephone number ("MIN") through the keypad 14. Microprocessor 30 accepts those commands and stores them. Also, the phone management system 100 may also be used to assist with on-site maintenance of the phone 10. For instance, insertion of the programming card can also trigger an internal diagnostic software program within the phone 10 that runs a complete maintenance routine.

Phone Management System Figures 5A and 5B illustrate the components and processing operations undertaken by the Phone Management System 100. The aim of the Phone Management System 100 is to provide a simple and useful system for managing cellular phones 10 with the following features: two way communication capability with the phones 10, including the capability to accept communication initiated by phones 10, and a capability to detect and reestablish lost communications and continue data transmission and receipt. Typically, the system operates on a convenient, wide-spread platform such as or work station running Windows (3.1, NT, etc.) or UNFX, although other operating systems can also be used. All phone 10 functions from rates to voice prompts may be controlled by this operating system.

Figure 6A shows the system 100 components, including a central processing unit 106, modem 108 for interfacing with phones 10 and a database 110. Modem 108 calls phones 10 in order to upload information or check their status. A second modem can be provided in order that phones 10 may freely and frequently call into the system 100 to report call accounting data at specified times or when their buffers fill. This way both modems may work without interference.

A database 110 for the system 100 must hold, organize and manage the following types of information:

• Phone Management System 100 setup and configuration;

• configuration and assignment information for phones 10;

• rate tables for each phone 10, including Free, Local, Local Toll, Long Distance Toll and International Calls; • identify groups of stolen/lost cards 17, 19; and

• store accounting information on each phone 10.

Database 110, for instance, an Informix relational database, also must provide the ability to group phones 10 into sets for communication requests and initiate communication sessions with individual phones 10, based on database 110 maintenance or other programmable parameters. Such sets allow system 100 operators to build groups of phones 10 that have the same rate structure (e.g., where the phones 10 are in close geographic proximity or the destination rates are identical for the phones 10).

Figure 6B shows some of the processes run on the system 100, such as monitor process 130 or GUI ("Graphical User Interface") process 130. Monitor process 120 decodes incoming messages at 122, stores those messages in a database at 124 and notifies the message processor at 126. Main message processor 106 runs on the central processing unit 106. That unit 106 also runs the GUI input process 130, by which phone 10 database maintenance at 132 and maintenance at 134 of the location of phones 10 is performed. GUI process 130 may also be responsible for transmitting messages to phones 10, as seen at 136. Further, system 100 operators can provide through GUI process 130 initial information for the system 100 (e.g., owner or operator of a particular phone 10, modem speed and location, system passwords); add new phones 10 to the system 100; perform self-diagnosis functions on the phones 10 when uploading or downloading information to them; adjust rating information; download to phones 10 serial numbers of lost or stolen families of prepaid cards 17 or credit cards 19 to minimize fraud; and poll phones 10 in order to generate desired reports.

System 100 communicates with a number of the phones 10 in order to download and upload data and operating systems, request call records and perform maintenance checks. Typically, the system 100 communicates with a particular phone 10 to:

• send a change of group message;

• send a maintenance check message; • request the status of the phones 10;

• request call records;

• send rate table, or a part of the rate table like the local, local toll, long distance or international call plan; or

• send initialization information or software like the application software.

Various communications protocols, such as ZMODEM may be used by the system 100 to communicate with phones 10. Various formats for sending data to and receiving data from the phones 10 also may be chosen. However, typical phone status data requested includes error correction or states information. Call accounting data includes information about the number of free, local, local toll, long distance or international calls made from a particular phone 10 since the last request of the system 100. Finally, accounting data may be retrieved such as credit card information including: user, card number, expiration date, charged amount, etc. Obviously, this information should be at least scrambled and preferably encrypted to prevent its interception by unauthorized persons. Transmission of large amounts of data, like rate tables or dialing plans, to particular phones 10 requires careful error correction.

One method for each phone 10 to ensure receipt of rate tables or a dialing plan is to have the system 100 first build a message, such as a rate table, by partitioning it into blocks of data, e.g., 256 bytes large. Each phone 10 will receive not just the data within the block, but also error correction information like the byte count for the entire rate table, checksum information for a particular block and total number of expected blocks. Based on this information, the phone 10 will generate an acknowledgment message to the system 100 when the entire rate table has been received. As data blocks come in, the phone 10 generates and sends status messages for each data block sent. If an error does occur, only the block in error is retransmitted ~ attempted a preset number of times — saving on the two to three minutes of modem connect time that could be required to download a rate table. A lost connection or incomplete transmission results in the system 100 or phone 10 timing out for a set period. System 100 may then request a status update from the phone 10, which may have sent a negative acknowledgment message at the end of its time-out period. Error messages between phone 10 and system 100 typically will contain an error code that will help determine which portion of the message went bad, which portion should be resent or whether to reconnect at a later time because of, for instance, a bad carrier signal.

Microprocessor 20 will automatically call into the phone management system 100 if a physical or mechanical problem occurs. Either the microprocessor 30 or phone system 100 can then toggle on a test routine within microprocessor 30 that test the connections and components of the phone 10. Severe faults will result in taking phone 10 out of service or sending a technician for correction.

The foregoing is provided for purposes of explanation and disclosure of preferred embodiments of the present invention. For instance, the operating software for the microprocessor, protocols for communicating between the phone 10 and a phone management system 100 or between the microprocessor 30 and the transceiver 24 may be modified, yet still fall within the following claims. Further modifications and adaptations to the described embodiments will be apparent to those skilled in the art and may be made without departing from the scope or spirit of the invention and the following claims.

Claims

What is claimed is:

1. A wireless telephone having a handset and keypad and capable of emulating a standard wireline telephone, the wireless telephone comprising: a. a transceiver for communicating over a wireless network; b. a microprocessor, coupled to the transceiver via a digital bus, for causing the transceiver to send a number entered into the keypad; and c. a processor, coupled to the handset, for generating predetermined audio signals and delivering the audio signals to the handset in order to emulate a standard wireline telephone.

2. A wireless telephone according to claim 1 further comprising a card reader for accepting payment from a user.

3. A wireless telephone according to claim 1 further comprising a dialing plan database for use in (1) determining when the numbers entered into the keypad comprise an established telephone number or (2) assessing a charge for a telephone call.

4. A wireless telephone having a handset and keypad for initiating a remote communication, the wireless telephone comprising: a. a transceiver for communicating over a wireless network; b. a microprocessor, coupled to the transceiver via a digital bus, for causing the transceiver to send a telephone number entered into the keypad in order to initiate the remote communication; and c. a card reader for accepting payment information from a user, wherein the microprocessor calculates a charge to assess the user based upon (1) the telephone number and (2) rating information contained within the telephone.

5. A wireless telephone according to claim 4 further comprising a processor, coupled to the handset, for generating audio signals upon command from the microprocessor and delivering the audio signals to the handset.

6. A wireless telephone according to claim 5 wherein the audio signals are selected from the group consisting of: DTMF tones, simulated dial tones and segments of speech.

7. A wireless telephone according to claim 6 further comprising a dialing plan database for use by the microprocessor to (1) determine when the numbers entered into the keypad comprise an established telephone number and (2) calculate the charge for a telephone call.

8. A wireless telephone according to claim 7 further comprising a display for showing the cumulative charge for the telephone call.

9. A wireless telephone according to claim 4 wherein the card reader is a pre-paid card reader for accepting payment from a pre-paid card.

10. A wireless telephone according to claim 9 further comprising a second credit card reader for accepting payment from a credit card.

11. A wireless telephone according to claim 4 further comprising means for determining a call start time for each remote communication and means for determining a call termination time for each remote communication.

12. A wireless telephone according to claim 11 wherein the microprocessor determines the call termination time and stores call accounting information comprising the telephone number, call start time and call termination time.

13. A wireless telephone according to claim 12 further comprising a modem for remotely communicating with a computer in order to send call accounting information.

14. A wireless telephone, comprising: a. a transceiver for communicating over a wireless network; b. a keypad and a first processor, coupled to the transceiver and to the keypad, for causing the transceiver to send over the network a telephone number entered into the keypad; c. a handset and a second processor coupled to the handset, for generating simulated dial tone and other predetermined audio signals, coupling the signals to the handset, and thereby simulating a wireline telephone; d. a card reader adapted to read values on a card, to verify information read from the card based on information stored in a storage device, and to transfer the information into an account memory device; e. a rating device adapted to rate, based on information stored within the telephone, the cost of a telephone call to the telephone number entered into the keypad; and f. a management device adapted to track the length of a telephone call made to the telephone number entered into the keypad, information in the account memory device, and information from the rating device in order to update information in the account memory device based on the length of the call and on the rating information.

15. A method of operating a wireless communications device comprising a handset, a transceiver, a card reader and a processor, the method comprising the steps of: a. generating DTMF tones with the processor upon entry by a user of a particular dialed number; b. emulating a standard telephone by providing the DTMF tones to the handset; c. automatically verifying a card inserted into the card reader in order to provide payment; d. determining the end of the dialed number; and e. controlling the transceiver to send digital data representing the dialed number to a wireless network to initiate a wireless communication.

16. The method according to claim 15 further comprising the step of generating simulated dial tone upon use of the handset by a user.

17. The method according to claim 16 in which the emulating step further comprises the step of providing dial tone to the handset.

18. The method according to claim 15 further comprising the steps of determining a call start time; determining a call termination time; determining the call cost and displaying the call cost.

19. The method according to claim 18 further comprising the step of storing call accounting information selected from the group consisting of: call start time, call termination time and call cost.

20. The method according to claim 15 further comprising the step of remotely reprogramming the communications device.

21. The method of claim 15 in which the verifying step further comprises the step of determining that a transaction code stored on the card does not match any transaction code stored within the wireless communications device.

22. The method of claim 15 in which the emulating step further comprises the step of automatically determining when the user has entered a dialed number and forwarding that number and a SEND command to the transceiver for communicating with a wireless service provider.

23. The method of claim 15 in which the verifying step further comprises the step of comparing a serial number stored in the card with a serial number associated with and stored within the wireless communications device.

24. A method for operating a wireless communications device for remotely communicating with a wireless service provider comprising the steps of: a. accepting from a user a card holding a stored value, verifying the card and transferring the stored value to a memory within the wireless communications device; b. rating an incoming or outgoing telephone call to determine a charge for the call; and c. deducting the charge for the call from the stored value resident within the memory.

25. The method of claim 24 further comprising the step of simulating a standard, wireline telephone.

26. The method of claim 24 in which the simulating step further comprises the step of generating a dial tone upon activation of the wireless communications device.

27. The method of claim 26 in which the simulating step further comprises the step of generating a DTMF tone upon entry of a selected number into the wireless communications device.

28. Apparatus for allowing a user to communicate remotely with a wireless service provider and for accepting immediate payment from the user for such communication, the apparatus comprising: a. means for initiating communication with the wireless service provider; b. means for determining a charge associated with the communication; c. means for reading a storage device holding payment information, including a first transaction code, from the user; d. a microprocessor for validating the payment information, wherein the microprocessor compares the first transaction code with a second transaction code and, depending on the comparison, the microprocessor stores a credit from which the charge is deducted.

29. Apparatus according to claim 28 further comprising means for simulating a wireline telephone.

30. Apparatus according to claim 28 further comprising means for delivering to the user audible messages.

31. Apparatus according to claim 29 in which the delivering means comprises a speech processor coupled to a memory in which voice segments are stored.

32. Apparatus according to claim 28 further comprising means for communicating with a host computer in order to obtain instructions and upload accounting information.

33. Apparatus according to any of claims 29 through 32 in which the microprocessor determines if the first and second transaction codes differ.