TELEPHONE DIALER HAVING AN INFRARED OR RADIO TRANSCEIVER AND METHOD OF USE THEREFOR

Abstract: A telephone speed-dialer (2 of fig. 1) for use with a personal digital assistant or other mobile device (figs. 6a and 6b) has an infrared transceiver for communication therewith. The dialer unit (dialer 2 of fig. 1, step 60 of fig. 2A) is connected to a land-based phone line, and remains next to a phone. When a user desires to make a phone call to a number on his or her PDA's address book, the user selects the phone number in the address book and sends the number via infrared link to the dialer. After the dialer receives the number from the PDA, the dialer senses when the user picks up the receiver of the adjacent phone, and automatically dials the phone number with proper area code and any predialing digits. Preferably, the dialer emulates another PDA receiving an electronic business card from the user's PDA, so that no special software need be installed on the user's PDA other than the existing operating system. To conserve battery power when not in use, the dialer remains in a "sleep mode" until it senses infrared activity. In an alternative embodiment, the dialer communicates with the PDA with a short range radio frequency link, such as that specified in the emerging Bluetooth Standard, instead of with the infrared link.

Description: TELEPHONE DIALER HAVING AN INFRARED OR RADIO TRANSCEIVER AND METHOD OF USE THEREFOR This application claims the benefit under 35 U.S.C. 1 19(e) of U.S. Provisional Application No. 60/158,581, filed October 7, 1999. BACKGROUND OF THE INVENTION The present invention relates to telephone speed-dialers or autodialers for assisting in placing ordinary telephone calls on a land-based telephone line, and in particular to a dialer that communicates with a mobile device via an infrared or short range radio frequency link. Sales of mobile computing or communication devices such as personal handheld organizers (personal digital assistants, or PDA's), cellular phones, and laptop/notebook computers have grown immensely in recent years. Devices are beginning to emerge that combine the functionality of a PDA with a cellular phone. One of the main functions of these mobile devices is the ability to store and organize contact information, such as the names, addresses, telephone numbers, and other information of people and companies. Since this contact information in the mobile device can be shared or synchronized with information in other mobile devices, desktop computers, and internet databases, these "electronic address books" have become powerful tools, capable of storing thousands of phone numbers. Although cellular phone use is growing very rapidly, it will be some time, if ever, before cell phone usage makes the previously existing land-based phone line system obsolete. With virtually every home and office in the United States already having hard-wired phone systems in place, it is often more convenient and less expensive to place phone calls over these land-based phone lines than it is to make a cell phone call. Land-based phone calls also result in a more reliable, secure and higher quality connection. In light of the above, whenever a typical PDA user wants to place a phone call, the user will often look up the telephone number in the address book of his or her PDA and dial it manually on an ordinary land-based phone. This often involves juggling the phone receiver and the PDA, squinting at small phone numbers on the PDA screen through glare or in dim lighting, and looking back and forth between the PDA screen and the telephone key pad while pressing 7 to 12 or more buttons. Complicating matters further, recent area code splits in metropolitan areas are making each area code geographically smaller every year. This means that more people must place phone calls from several different area codes each day to many different area codes. When dialing, the user must consider what area code he is dialing from, whether the person being called is still within that area code, whether a 1 must be dialed before the number, and whether a predialing digit such as an 8 or 9 must be dialed, depending on whether the person is calling from the home, office or hotel, etc. This can add up to 12 digits, or more if an international call is being placed or an extension is being dialed. While many people have grown accustomed to this increasing complex ritual of dialing the phone, it would be a real convenience to not have to think about ANY digits or push ANY buttons after selecting a person to call from the PDA address book. Speed dialers or autodialers to automate the task of dialing have existed for many years. These devices can be separate units that sit beside the phone and plug into the phone line, or they can be built into the phone. Unfortunately, these dialers have a limit to the number of phone numbers they can store, typically 10, sometimes 100. Each one (e.g. different units used by a user in different rooms at home and/or the office) can have its own way of programming that is often cumbersome and may require "reading the manual" to accomplish. Often there is insufficient or no space to label each phone number, and the user is required to remember or record which phone number is associated with which speed dial number (e.g. speed dial number 01 is assigned to John Smith of ABC Company, whose phone number is 555-1212, etc.) When someone's phone number or area code changes, the user must reprogram every speed dialer unit individually, and must remember which units have been changed if they are not all updated at once. Similar problems can occur when the dialer batteries wear down. These problems are unacceptable to a PDA user, who is able to intuitively and easily enter or change a phone number in his PDA address book just once, and have it be automatically synchronized and backed up with all other computers and mobile devices associated with his address book. For these reasons, speed dialers tend to be used in only one or two locations for a user, and contain only one or two phone numbers, rather than being more fully utilized. Personal Information Managers (PIM's) are included in many different software programs that allow contact information to be managed on a personal computer. Some of these programs, such as Microsoft Outlook or Palm Desktop, allow the user to speed dial a number located in its database. However, these dialing features do not appear to be widely used, perhaps because they are small features hidden in feature-rich programs, and their use is not necessarily intuitive and simple. To use these dialers, the user must have his computer connected to an analog phone line (as opposed to a possibly incompatible digital PBX phone line in an office.) If a computer is already connected to a phone line (for example through a modem), it may be connected to a line used for computer communications (such as to an Internet Service Provider), rather than to a phone line the user wants to use for voice calls. This type of dialing also requires the user to place a call from a phone location next to a computer, and the computer must be turned on and the appropriate application program must be running. It would be more desirable to allow a user to place a speed-dialed call from any telephone in his house or office, for instance from a kitchen where there is no computer, and to do so without having to boot up a computer. Better yet, the user should be able to have a powerful yet simple and convenient autodialer without being required to even have a computer. Lastly, handheld dual tone multiple frequency (DTMF) dialers have been sold that emit dialing tones into a receiver mouthpiece to dial a phone number. However, this requires the user to juggle the dialer and the phone receiver simultaneously, to select the phone number and get the dialer to the mouthpiece before any tones are emitted, and to start the dialing process before the phone's available dial tone goes away. Dialing may not always be accurate due to problems associated with dialer volume and/or ambient noise. If the DTMF dialer is part of another device such as a voice recorder, the user may not want to spend the extra money required to buy the device if the other features are not exactly what the user needs. Such a device suffers from the same problems discussed above for speed-dialers that plug into or are part of a phone. If the DTMF dialer is an attachment that plugs into a PDA, the device must be plugged in to make a call and then removed to allow the PDA to fit into its case, or to allow another device to be plugged into the PDA. such as a HotSync® cradle or modem for a Palm Computing® organizer, or a Springboard™ module for a Handspring™ organizer. What would be desirable, and is not provided by the prior art, is an autodialer that works with a PDA's address book to automatically dial phone numbers quickly, accurately, and effortlessly. Preferably, no cables or devices would have to be attached to the PDA. Preferably, no special software would have to be purchased, downloaded, installed, configured, learned, or used. Preferrably, the dialer could be used without ever needing a computer. Preferrably, the dialer could determine the proper area codes and predialing digits needed, if any, for dialing each particular phone number. Ideally, such an autodialer would be powerful in order to perform complex processing tasks, yet simple and intuitive for the user to learn and operate. SUMMARY OF THE INVENTION A telephone dialer constructed according to the present invention is able to receive and dial telephone numbers sent to the dialer via infrared (IR) link with a mobile device such as a personal hand-held organizer (personal digital assistant, or PDA), cellular phone, notebook/laptop computer, or similar infrared equipped device which stores phone numbers. (Hereinafter these various types of devices will be referred to simply as "PDA" for brevity.) Alternatively, the inventive dialer could communicate with the PDA through a short range radio frequency (RF) link, such as one complying with the emerging Bluetooth Standard. The dialer unit is connected to a land-based phone line, and remains next to a phone on that line. When a user desires to make a phone call to a number in his or her PDA's address book, the user selects the phone number in the address book and sends the number via infrared or radio link (i.e. "beams" it) to the dialer. After the dialer receives the number from the PDA, the dialer senses when the user picks up the receiver of the adjacent phone, and automatically dials the phone number with proper area code and any predialing digits. According to one aspect of the invention, the dialer emulates a PDA or similar device capable of storing, sending and receiving address entries. This allows a PDA or similar device to use its built-in operating system and/or standard application software to transmit an address entry via IR or RF without the need for the user to purchase. download, configure, and learn separate software designed to transmit phone numbers. The user need never access a computer at all to use the inventive dialer: the user just uses a PDA or similar device and the dialer. The entire address entry is transmitted by the PDA, but only the primary phone number is used by the dialer. According to another aspect of the invention, the PDA is used to configure the dialer by sending a standard address entry having a unique title or other field to distinguish it from other address entries. Preferably, each configuration setting is input and sent via IR or RF as a separate field within the address entry. This allows the dialer to be made without a display screen and complex input device, yet multiple configuration settings can be easily and clearly input through the PDA. According to still another aspect of the invention, the PDA is used to display error messages by receiving a standard address entry, memo, or other non-proprietary block of information from the dialer via IR or RF. This allows more complete information to be displayed to the user without the need for the dialer to include its own display screen. Preferably, error messages are written out in full with suggested solutions, rather than just displaying an error code. According to yet another aspect of the invention, Caller ID information is uploaded from the dialer to a PDA via IR or RF. Preferably this is done with the same standard address entry format. This allows information to be added to the PDA more quickly, easily and accurately than with inputing the information with the PDA's handwriting recognition software or even a keyboard. According to yet another aspect of the invention, phone numbers are intelligently parsed from an address entry. Almost all non-numeric characters and symbols are removed. The dialer can determine when an area code should be added or removed, a preceding 1 should be added or removed, a preceding 0 should be removed, and when a potential error may exist. This allows numbers to exist in the PDA address book in a multitude of different formats without the need to enter or re-enter them in a particular format in order for the dialer to recognize and dial them properly. According to yet another aspect of the invention, phone numbers having extensions after them are automatically recognized, and the extension is removed from the number and stored in a separate buffer. Once the number has been dialed, the extension can be dialed from the buffer by pushing a button on the dialer. According to yet another aspect of the invention, the dialer can be set up to sense when the phone line goes "off-hook" and dial the phone number as soon as it does, or alternately wait until a button is pushed on the dialer before dialing the number. According to yet another aspect of the invention, the dialer can be set up to dial pre and/or post-dialing digits, such as digits to access an outside line, international calling codes, charge numbers, alternate carrier access numbers, and automated phone system menu commands. Pauses between dialing of digits can also be set up. According to yet another aspect of the invention, "vanity" phone numbers can be automatically detected and dialed, so that they do not have to be re-entered as numerical digits in the PDA address book. According to yet another aspect of the invention, the dialer can be configured to dial multiple phone numbers during one call, such as to set up a conference call. According to yet another aspect of the invention, the dialer can be configured to be used on two phone lines. For instance, the phone number sent to the dialer by a PDA can be dialed on the first of the two lines to go off-hook. The Caller ID feature can also monitor information on both of the two phone lines. According to yet another aspect of the invention, the dialer can be configured to work with digital phone systems, such as many office PBX's. According to yet another aspect of the invention, the dialer is powered by the phone line current rather than by batteries or AC adapter current. Alternately, batteries can be used (may be required to comply with telecommunication standards.) To preserve battery life, the processor controlling the dialer enters a low power "sleep" state when it has been idle for a predetermined period of time. The processor can be awakened from its sleep state by IR or RF activity, a press of the dialer button, or when the phone goes off-hook. All of the above features work in conjunction to allow the dialer to be small and lightweight for travel and for occupying a small space on a desktop, to be low cost, and extremely simple to learn and use. BRIEF DESCRIPTION OF THE DRAWINGS Fig. 1 is an exploded perspective view showing a telephone dialer constructed according to the present invention. Figs. 2a through 2f are a series of block diagrams that together form a single flowchart showing the preferred operation of the inventive dialer. The flowchart is formed by aligning Figs. 2a through 2f in a vertical series end-to-end, with Fig. 2a at the top and Fig. 2f at the bottom. Fig. 3 is a block diagram schematically showing the major components and connections in the preferred embodiment of the dialer. Fig. 4 is a block diagram showing an IrDA compliant software stack architecture for use by the dialer processor. Fig. 5a and 5b are two flowcharts that together show the operation of an alternative embodiment of the dialer, Fig. 5a showing a data acquisition phase and Fig. 5b showing a dialing phase. Fig. 6a is a block diagram showing the overall operation of the dialer with a mobile device and an ordinary telephone. Fig. 6b is a block diagram showing the overall operation of an embodiment wherein the inventive dialer is built into a telephone. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Referring to Fig. 1 , a telephone dialer 2 constructed according to the present invention is shown in exploded view. A generally square case 4 constructed of injection molded plastic is provided to house the dialer components. Case 4 includes a top half 4a and a bottom half 4b which are held together by a single screw 6 as shown, or by ultrasonic welding and or by molded features that allow the two halves 4a and 4b to be snapped together. Printed circuit board 8 rests on molded stand offs 10 and lower stepped boss 12 located in case bottom 4b. Circuit board 8 is securely sandwiched between lower boss 12 and a similar upper boss protruding from the bottom of case top 4a when screw 6 fastens the two bosses together. When assembled, the back surface of case 4 includes an input phone jack 14 for connecting to a phone line, and an output phone jack 16 for connecting to a telephone. Preferably, both jacks 14 and 16 are standard RJ-11 jacks, with four conductors each to accommodate two phone lines. Along the front top edge of case 4 is a window 18 having an infrared (IR) passing filter mounted therein for allowing IR signals to be sent and received from dialer 2. Preferably, window 18 extends from the top surface around to the front surface of case 4 so that IR signals can be sent and received throughout a field of view of 90 degrees. A power switch can be provided, but preferably is omitted for simplicity (particularly if dialer 10 is powered by a phone line rather than by battery or an AC outlet transformer.) Push-button switch 20 is accessible through hole 20h provided in case top 4a, and its functions will be described later. A series of light emitting diodes (LED's) protrude from holes 22h - 32h in case top 4a to indicate the status of dialer 2. In the embodiment shown and described herein, LED 22 indicates that dialer 2 is turned on (or receiving power from the phone line.) LED 24 indicates that a phone connected to the circuit is off-hook. LED 26 indicates when an error has occurred. LED 28 acknowledges when setup parameters have been successfully received, LED 30 indicates when a phone number is loaded into memory ready for dialing, and LED 32 indicates when dialer 2 is actually dialing a number. Other LED's could be added to indicate other functions, such as which of the setup modes dialer 2 is in, as described below. Alternatively, a single tri-state LED could be used to show the basic status of dialer 2 in place of the six LED's shown. For instance the single LED could flash red to indicate an error, light solid red to acknowledge receipt of setup parameters, light solid yellow to indicate a phone number has been loaded into memory, flash yellow to indicate the number in memory may be anomalous, and light green when the number is being dialed (or a similar consolidated LED arrangement.) Rubber feet or preferably suction cups 34 can be utilized to support or mount dialer 2 on a horizontal or vertical surface such as on a desk or a telephone where IR window 18 is readily accessible for communication with another device. IR transceiver 36, such as part no. HSDL-1000 from Hewlett Packard of Palo Alto, California, or part no. TFDU4201 from Vishay Telefunken / Vishay Semiconductor GmbH, of Heilbronn. Germany, is mounted on circuit board 8 such that it located just behind IR window 18 when dialer 2 is assembled. Preferably, IR transceiver is mounted on circuit board 8 at a 45 degree angle. IR window can be shaped to have a rounded edge rather than the square edge shown for more continuous IR transmission therethrough. Decoder chip 38, such as part no. HSDL-7000 from Hewlett Packard of Palo Alto, California, is also provided on circuit board 8. Decoder chip 38 converts the 3/16 cycle IR pulses to and from binary signals read and produced by the other circuitry of dialer 2. Microprocessor 40 and memory chip 42 are also located on circuit board 8. Microprocessor 40 controls all of the functions of dialer 2, such as sending and receiving information from an external IR device, parsing and processing that information, lighting the LED's, and generating the dual tone multi- frequency (DTMF) tones for dialing the telephone numbers. Memory chip 42 retains the configuration settings and other information received from an external IR device, such as phone number digits and phone extension digits. The microprocessor can be chosen from the PIC16F or PIC12C families of microprocessors with a compatible memory chip, both from Microchip. Alternatively, the microprocessor can be a part no.COP8SGG5 from National Semiconductor Corporation of Santa Clara, California, which has ROM, RAM and a UART built in, as shown in Fig. 3. The UART's function is both to convert serial data to byte wide parallel format and the converse. The system clock can be run from an 8 MHz crystal, also shown in Fig. 3. A battery or batteries as shown in Fig. 3 can also be provided on circuit board 8 for powering dialer 2 and or providing enough power to retain programmable settings in memory (if required.) It is difficult to comply with telecommunication equipment requirements for current drain if power is drawn from the phone line, so use of batteries is highly recommended, preferably two size AAA alkaline batteries. A voltage level sensing chip, such as a MAX 6377 from Maxim Integrated Products of Sunnyvale, California, can be used as shown in Fig. 3 to signal microprocessor 40 when the batteries are getting low, so that a warning LED can be flashed and/or the dialer can be shut down. Only the major components of dialer 2 have been shown and/or described. Clearly, other components well know to those skilled in the art are needed to complete the circuitry required for executing the functions described herein. These components may include a digital to analog converter (DAC) and dialing interface circuitry components between microprocessor 40 and the phone line, shown in block form in Fig. 3. It is envisioned that the DAC circuitry will include six 1% binary weighted resistors all feeding into the base of a MPS-A42 transistor. Each resistor will be connected to a separate output line from microprocessor 40, and have a resistance double that of the previous resistor in the series, forming a 6 bit DAC. The emitter and collector of the transistor will be connected to a connector from each of the phone jacks through a diode bridge. A zenor diode and a capacitor will also be connected across the emitter and collector of the transistor, and another capacitor will be connected across the other two opposite nodes of the diode bridge. It is envisioned that the dialer will be connected in series with a phone on the phone line, rather than in parallel. Preferably dialer 2 is constructed to be compliant or at least compatible with the Infrared Data Association (IrDA) specification for IR data transfer. At the time of filing this patent application, the IrDA specification (Version 1.3) comprises three mandatory specifications: the Physical Layer, Link Access Protocol (IrLAP), and Link Management Protocol (IrLMP). These specifications, incorporated herein by reference, can be downloaded free of charge from http://www.irda.org. Many laptop applications, hand-held organizers and Personal Digital Assistants (PDA's), such as from Palm, Inc. (formerly 3Com) of Santa Clara, California, and Handspring of Mountain View, California, use the IrDA standards to establish, maintain, and terminate the IR data links, and use a data format know as vCard for transferring the actual phone number and address data frames (i.e. the "payload" frames) within the IrDA carrier scheme. The vCard specification for Personal Data Interchange (PDI), incorporated herein by reference, is managed by the Internet Mail Consortium and can be downloaded free of charge from http://www.imc.org/pdi. Only a small portion of the above "open standard" specifications need be utilized to allow a slow speed data link to be established between dialer 2 and another desired IR capable device (such as a Palm III® from Palm, Inc), and the desired telephone number(s) to be extracted and parsed from the data received. To accomplish these tasks, source code known as JetBeam for Process Automation with IrOBEX - IrDA Lite protocol stack, can be licensed from Counterpoint Systems Foundry Inc., located in Corvallis. Oregon, an Extended Systems Company, located in Boise, Idaho. JetBeam IrDA Lite is a very tiny (less than 10K) IrDA stack optimized for 8-bit implementations. The IrOBEX Add-in (IrDA Object Exchange) can transmit objects such as files, graphics, vCards, vCalendars and vMessages, and takes care of discovery, setup, and maintenance of the IR connection. The IrDA compliant JetBeam stack architecture is shown in Fig. 4. An application (shown at the top of the stack) can be written to accomplish the dialer-specific tasks detailed below, and then the entire stack can be compiled and downloaded/burned into the microprocessor 40, as is well known in the art. In the preferred embodiment, dialer 2 emulates another PDA (preferably a Palm III®) when receiving the data. The built-in functionality of a PDA running on a Palm® operating system permits an entire "address book" entry to be "beamed" via IR to another PDA which also runs on the Palm® operating system. When dialer 2 emulates another Palm PDA, it can receive this address entry without the need for special software to be loaded into the PDA to transmit the desired phone number. Furthermore, the use of such proprietary software does not have to be learned by the user. The desired address entry is accessed and sent with just a few standard commands as is normally done by the user, and dialer 2 receives the entire address entry and ignores virtually everything but the primary phone number to be dialed. To beam an address entry from a first Palm III® to a second Palm III®, both Palms are turned on and their IR ports (on top) are pointed toward one another. The address book of the first Palm is opened, and the desired address entry is selected. The "MENU" button is then selected with the Palm writing stylus (or finger), and "Beam Address" is selected from a drop-down menu that appears. Alternately, the first Palm can be previously set up to automatically "beam" a selected entry whenever the stylus is dragged across the screen bottom to top. With either method, the first Palm then "searches" for the second Palm by sending out IR signals according to the IrDA protocol. When the second Palm detects these signals, it signals back with an identification of itself and indicating it is ready to receive the data. After the appropriate "handshaking" signals are exchanged to set up the IR data link between the two Palms, the address entry is sent from the first Palm to the second, and the IR data link is terminated. The first thing seen on the screen of the second Palm is a message that the particular address entry has been received. The user of the second Palm is then prompted to either accept the address into the address book of the second Palm, or discard it. Speed-dialing with dialer 2 works much the same way as above, except the second Palm is replaced by dialer 2, and no further input is required (depending on setup configuration of dialer 2) after the address entry (i.e. phone number) is selected on the first Palm and the stylus is dragged across the screen. Depending on the setup configuration of dialer 2. the primary phone number of the address entry is dialed immediately if the phone is off-hook, is dialed as soon as the phone is taken off hook, or when button 20 is depressed. Thus, with dialer 2 it is possible to dial a selected phone number simply by dragging the stylus across the screen rather than manually dialing the 7, 10, 1 1 or more digits manually on the telephone keypad while looking at both the Palm screen and the phone keypad. Each address entry in the address book of a Palm III® PDA can accept up to five phone numbers in standard phone number fields within the address entry. Any one of these five numbers can be designated or redesignated at any time as the primary phone number to be displayed on the Palm's address book phone number list. In the preferred embodiment, it is this primary phone number that is dialed when the address entry is beamed to dialer 2. This primary phone number is preceded with a "PREF" designation in the vCard data. The other address fields are ignored (except for with setup entries as described below). Any non-numeric digits other than the letter X is also parsed out, such as spaces, parenthesis, hyphens, periods, slashes, and other letters and characters. The letter X (capital or small case) is used to designate phone extensions as will be later described. With this parsing scheme, phone numbers already entered into a user's address book in virtually any format can be dialed with dialer 2 without the need to re-enter the phone numbers in the address book in a particular format required by the dialer. The PDA or other IR device (hereinafter referred to in this section as just PDA for brevity) is also used to program the setup configuration of dialer 2, and can also receive error descriptions generated by dialer 2. Since the PDA's sophisticated display screen and text input capabilities are utilized, dialer 2 can easily handle these setup and error functions without having to have anything more built-in than just a single pushbutton 20 for input and one or more LED's 22-32 for output. Both of the setup and error functions are handled as a typical address entry IR transmission. The setup information is created on the PDA and sent to dialer 2, while the error information is created within dialer 2 and sent to the PDA. For example, an error message can be sent to the PDA as an "address entry" with the error description listed in the "notes" field of the address entry. For the setup entry, an unusual person or company name not likely to be found in any PDA address book can be used to designate a setup configuration "address entry." Various standard fields in this entry (such as first name, last name, title, company, address, city, state, zip code, country, phone numbers, custom fields, note field, etc.) can be designated for different setup parameters. When dialer 2 receives such a setup entry, it is programmed to recognize it as such. Rather than dial the primary phone number of such an entry, microprocessor 40 uses the designated fields to properly configure the settings of dialer 2. In the preferred embodiment, there are seven setup fields as follows: FIELD NO. DESCRIPTION OF SETTING 1 Local area code 2 Must an area code always be dialed? 3 Must a 1 be dialed before a 10 digit no.? 4 Pre-dial digit(s) 5 Post-dial digit(s) 6 Immediate/off-hook or button press dialing 7 Literal or "smart" mode dialing Setup field number 1 allows dialer 2 to know what area code it is currently dialing from. Setup field number 2 allows dialer 2 to know whether it is dialing in a region that requires that the area code always be dialed, even when calling local numbers within the same area code. Setup field number 3 allows dialer 2 to know whether or not a 1 must be dialed before every 10 digit number. Setup filed number 4 allows dialer 2 to dial pre-dial digits before a phone number, such as 9 for an outside line from an office PBX, an 8 for an outside line at a hotel, an international dialing code when dialing from outside the country, or a phone company access number for dialing through another carrier. Setup field number 5 allows post-dial digits to be dialed, such as a phone charge card number (automatic phone menu system digits, such as for voice mailbox access or automatic information delivery systems are better entered as an extension in the PDA address entry for the number being dialed, as will be described later.) Setup field number 6 permits the user to have dialer 2 dial a number as soon as the phone goes off-hook (i.e. immediately if the phone is already off-hook), or wait until the user depresses button 20. Finally, setup field 7 lets the user decide whether phone numbers are dialed literally as they are found in the address book entry after parsing, or whether dialer 2 uses an algorithm described below in conjunction with setup fields 1-3 to determine whether each particular phone number is properly formatted. When dialer 2 is in "smart" mode, the most common types of incorrectly formatted phone numbers are detected and automatically formatted correctly before dialing. For example, if a phone number within the local area code is listed in a PDA address book with the area code and 10 or 11 digit dialing of same area code numbers is not permitted in that particular area code, dialer 2 will remove the area code before dialing. Similarly, a 1 preceding an 800 number is added or removed as required before dialing. Note that fields 1-3 must be entered first before the smart mode can be work properly. The default settings for the setup fields in the preferred embodiment are: l)blank; 2)no; 3)yes; 4)blank; 5)blank; 6)off-hook mode; and 7)smart mode. This allows dialer 2 to be used straight out of the box if desired with moderate success in most areas before the setup fields are configured. Alternatively, dialer 2 may be completely disabled until a valid setup configuration is loaded, and smart mode may be disabled until fields 1-3 are entered. Referring now to Figs. 2A through 2F. a flow chart of the operation of dialer 2 is shown. (Reference numerals 2-42 represent hardware shown in Fig. 1 , and reference numerals 60-158 represent process steps shown in Figs. 2A-2F.) The five major subdivisions of operation are the standby (for receive or redial) phase comprising steps 60-76 shown in Fig. 2A, the receive phase comprising steps 78-96 shown in Fig. 2B, the phone number manipulation phase comprising steps 98-126 shown in Figs. 2C & 2D, the error detection phase comprising steps 128-140 shown in Fig. 2E, and the dialing phase comprising steps 142-158 shown in Figs. 2E & 2F. Referring to Fig. 2A. the standby for receive or redial phase is shown. In step 60 dialer 2 is connected to a phone line and/or switched on. and does a typical internal check and initialization of the circuitry. Power LED 22 is illuminated in step 61 and remains lit as long as dialer 2 has power. Dialer 2 then cycles repeatedly through steps 62, 74 and 76 until either button 20 is depressed or an IR signal transmitted by a PDA is picked up. If a button press is detected in step 62, dialing LED 32 is illuminated in step 64 for a predetermined period of time (preferably 3 seconds), and the phone number remaining in memory from the last number dialed is dialed again in step 66. If the phone is not off-hook at this point, operation passes back to step 74 and cycles through steps 62, 74 and 76 again. If the phone is off hook, operation cycles repeatedly through steps 68, 70 and 72 until either the phone goes on-hook or button 20 is pressed again. If a button press is detected in step 70, the phone extension number, if any, associated with the last number dialed and stored in the buffer is then dialed. This number in the buffer can be repeated dialed if desired each time button 20 is pressed. Once an off-hook condition is no longer detected in step 68, operation of dialer 2 reverts back to waiting for a redial request at step 62 or receipt of an IR signal with steps 74 and 76. If an IR signal is detected in step 76, operation of dialer 2 proceeds to the receive phase. Referring to Fig. 2B, the receive phase will be described. Once an IR signal from a PDA is received, dialer 2 in step 78 sends back a signal to the PDA indicating its presence and establishes an IR data link with the PDA as previously described above. Once the link is established, dialer 2 receives the information, as depicted by step 80. and stores the information in memory chip 42 and/or begins to process the information with microprocessor 40. Once all of the data is received, the IR data link with the PDA is terminated. In step 82, microprocessor 40 looks to see if the information is in the form expected (i.e. in the form of a vCard address entry from a PDA, etc.) Preferably, microprocessor 40 is programmed to recognize and establish IR links only with devices of the type it expects to receive data from, but such devices may still send data that is not in the required format, such as a vCalendar entry from a PDA datebook application. A parity check can also be done in step 82 if desired, or can be done as part of the receiving data step 80. If an incorrect format or corrupted data is sent, error LED 26 is illuminated for 10 seconds as shown in step 84. Additionally, an error message may be generated by dialer 2 if desired, and sent back to the PDA as shown by step 86. This requires dialer 2 to act as a "primary station" under IrDA standards and establish an IR data link by sending out a signal, waiting for a reply from the PDA, performing the necessary handshaking, and sending the error information in the form of an address entry (vCard), as previously described. Operation would then revert back to the standby phase shown in Fig. 2A. If the format of the data is found to be O.K. in step 82. microprocessor 40 checks in step 88 to see if the address entry is a setup entry (as previously described), or a regular address entry. If found to be a setup entry, the appropriate fields are stored in memory in step 90, and LED 28 is illuminated for 10 seconds in step 92. If the address entry is not a setup entry, the previous phone number is cleared from memory and the previous extension number is cleared from the buffer in step 94, in preparation for loading the current phone number into memory in step 96. (The term "buffer" is used herein to describe a portion of memory that is different than the memory portions in microprocessor 40 or memory chip 42 designated to store the phone number to be dialed, the processing instructions, the setup configuration settings, the complete vCard address entry information, and the like.) In step 96 the primary phone number is taken from the address entry just received and any non-numeric digits other than the letter X are parsed out, as previously described. The phone number is then stored in a predetermined portion of memory. Referring to Fig. 2C, the phone number manipulation phase will be described. In step 98. setup field #7 is looked at to see if it specifies literal or "smart mode" dialing. If literal dialing is specified, the manipulation phase shown in Figs. 2C and 2D is skipped, and the operation of dialer 2 proceeds to the first error detection step, step 128, shown in Fig. 2E. If literal dialing is not specified in step 98, the phone number in memory is checked in step 100 to see if it includes an X. If an X is found, it is removed in step 102. and all digits following it are also removed from the phone number to be dialed and placed in the buffer, to be dialed as an extension. Thus if the phone number field in the PDA address entry included something like "Ext. 123", "ext 123", or "xl23", the extension digits 123 will be placed in the buffer. If no X is found in step 100, step 102 is unnecessary and is skipped as shown. Referring to Figs. 2C and 2D, step 104 determines whether there are more than 7 digits in the number to be dialed. If not, step 106 determines whether an area code must always be dialed, even for a 7-digit number, as specified by setup field #2. If not, operation proceeds to step 128 shown in Fig. 2E. If so, the local area code is added to the number in step 1 10, as provided by setup field #1. Then steps 122 and 126 add a 1 before the number if needed, as specified by setup field #3. and operation proceeds to step 128. If more than 7 digits are found in step 104, steps 108 and 112 determine if the first digit is a 0 or 1, respectively. If the first digit is either a 0 or 1, step 114 determines whether the second digit is a 0 or 1. If so, the number is likely an international dialing code or special number string, and is left intact as operation proceeds to step 128. If the second digit is neither 0 or 1. the first digit (a 0 or a 1) is removed as an erroneous or unneeded digit in step 1 16 and operation proceeds to step 1 18. If the first digit is found to be neither a 0 or 1 in steps 108 and 1 12, then operation proceeds directly to step 1 18. Step 118 determines whether the first three digits (which are now known not to start with a 0 or 1 ) match the local area code specified by setup field #1. If the first three digits are different, operation proceeds to steps 122 and 126 which add a 1 before the number if needed, as specified by setup field #3, and operation proceeds to step 128. If the first three digits of the number are not different than the local area code in step 1 18. step 120 determines whether an area code needs to be dialed, as specified by setup field #2. If yes, operation proceeds to steps 122. 126 and 128 as previously described. If no, the local area code is removed in step 124. and operation proceeds to step 128. Referring to Fig. 2E, the error detection phase of the preferred embodiment will be described. Steps 128 through 136 determine if any one of five specific error conditions exist. If so, memory LED 30 is illuminated in a continuously flashing mode in step 140 to indicate a number has been stored in memory, but a potential problem may exist. If none of the five error conditions are found, the memory LED 30 is illuminated in a constant mode in step 138. In either case, operation will continue to the dialing phase (which starts with step 142). When LED 30 is flashing, it is up to the user to decide whether to cancel the dialing of the number. This is done by depressing pushbutton 20 when the phone is on-hook, or going quickly from off-hook to on-hook, depending on which dialing method is set in setup field #6. Step 128 checks for the first of the five potential error conditions by determining if there is an X in the number. If smart mode has been chosen in setup field #7, any X's would have been removed in step 102. However, if literal mode were chosen in this setup field, the smart mode steps including step 102 would have been bypassed by step 98. In this event, any X's existing in the original phone number of the PDA address entry and any trailing numeric digits will remain in the number stored in memory (not in the buffer), causing memory LED 30 to flash. Step 130 will cause memory LED 30 to flash if the number to be dialed starts with a 0. Steps 132 and 134 work in conjunction to indicate a potential error if the phone number starts with a 1 but is not eleven digits long, or is eleven digits long and does not start with a 1. Finally, step 136 indicates a potential error if the phone number is other than a 7, 10, or 1 1 digit number. If desired, processing steps could be added to send this particular error information to the PDA via an IR link as described above. Referring to Figs. 2E and 2F. the dialing phase of the preferred embodiment will be described. Step 142 determines whether immediate/off-hook mode has been selected in setup field #6, or if button 20 must instead be pressed before the phone number is dialed. If the immediate mode has not been selected, operation proceeds to step 146 and holds there waiting for button 20 to be depressed. If the immediate mode has been selected, operation proceeds to step 144 and holds there waiting until the phone line goes off-hook (if it is not already off-hook.) As soon as button 20 is depressed in step 146 or an off-hook condition is present in step 144, whichever of the two paths applies, memory LED 30 is extinguished in step 148, and dialing LED 32 is illuminated for 3 seconds in step 150 while the number is being dialed in step 152. Any X's in the number that have been passed through with literal dialing are ignored (but any digits trailing an X are dialed.) Also, any pre-dialing and/or post-dialing digits as specified by setup fields #4 and 5, respectively, are also dialed with the phone number. After the phone number has been dialed in step 152, step 154 determines when the phone line is no longer off-hook (including if it has never gone off-hook for dialing, such as to cancel a number in memory.) When this occurs, operation of dialer 2 returns to the top of the standby for receive or redial phase (step 62) as shown in Fig. 2 A, and the entire operation cycle repeats as described above. If the phone line is still off-hook in step 154, operation cycles through steps 156 and/or 158 until an off-hook status is no longer sensed by step 154. During this time, if button 20 is depressed in step 156, the extension number stored in the buffer is dialed in step 158 (this may be done multiple times.) Steps 150 through 158 are analogous to steps 64 through 72. Preferably, any time that dialer 2 has power the circuitry should be constantly checking the phone line for an off-hook condition, and light LED 24 whenever the line is off-hook. If desired, the above flow of operation can be modified to allow multiple phone numbers to be dialed during a single phone call. This could be useful for setting up conference calls, dialing credit card numbers, or menu selection codes when it is not desirable to use the predialing, postdialing, or extension number features described above for these operations. This could be accomplished by allowing subsequent address entries to be received from the PDA when the phone line is still off hook after dialing a first number. Alternatively, separate and parallel memory addresses could be setup to allow multiple phone numbers to be downloaded into dialer 2 before a telephone call is placed. The subsequent phone numbers could be accessed by subsequent pushes of button 20, or additional pushbuttons could be added. A particular character or characters could be chosen to represent a pause of a predetermined length of time between dialing digits to facilitate more complex dialing procedures. This (these) character(s) would be retained along with X's in parsing step 96, and should be chosen to be uncommon characters to avoid undesired pauses during normal dialing. A set of steps could be added to the "smart" dialing mode to decode vanity numbers. For instance, if an 800 area code were detected, and the following 7 digits were letters rather than numbers, the letters could be converted to numbers (e.g. 800 DIALME2 would be converted to 800 342-5632.) Alternatively, a setup field could be dedicated to enable such a feature to be turned on to decode vanity numbers, whether they were an 800 number or not. In an alternative embodiment, the feature of uploadable Caller ID information from the dialer to the PDA can easily be added to dialer 2. Since the hardware and functionality of dialer 2 as described above already have dialer 2 connected to the phone line and able to initiate an IR or RF data link between the dialer and the PDA (see descriptions above relative to sending error messages to the PDA), it is only a matter of adding the proper programming to microprocessor 40 to integrate this feature in dialer 2. Such uploading of Caller ID information saves the PDA user considerable time entering this information manually with a PDA input application, such as Graffiti® in the Palm Computing® Platform. To enable dialer 2 to have the feature of Caller ID uploading, microprocessor 40 is programmed to sense when the phone line dialer 2 is connected to is ringing. When the line is ringing the Caller ID information available on the line is retrieved and stored into memory. Preferably, multiple calls can be separately stored in memory. The information from each call is formatted in a standard address book entry form (i.e. vCard). In other words, any available information is separated into fields such as first name, last name, company name, phone number, address, city, state, zip code, etc. The time and date of the call can be ignored or put into a "notes" or "custom" field. Some information which may not be available, such as city, state, and zip code can be added by using the available information in conjunction with a look-up table stored in memory chip 42. For instance, by looking up the area code and/or prefix of the Caller ID phone number, the city can be determined. If this process yields several cities rather than a unique city, all of the possible cities can be included and identified with parenthesis, a question mark or the like, allowing the PDA user to delete all but the correct city if and when it is learned. An extra LED can be added to indicate when Caller ID information is stored in memory, and can indicate the number of calls in memory by flashing that same number of times in a repetitive cycle. Push button 20 can be used to initiate an upload of information, or an additional button or several buttons can be added for this purpose. Preferably, each call is uploaded in a separate address book entry. When the upload process is initiated, dialer 2 sends out an IR or RF signal indicating it is looking for a PDA to link up with. When the PDA is turned on and within range ofdialer 2. it receives those signals and signals back that it is ready to receive. After the standard handshaking signals are exchanged, the address book entry containing the Caller ID of a received call is transmitted to the PDA, and the link is terminated. A message window will then typically appear in the PDA screen identifying the name of the caller and asking whether the address entry should be stored in the address book or discarded. After choosing one of these options, the user can then press button 20 again to upload another address entry stored in the dialer, if any. Those skilled in the art will appreciate that a microprocessor with additional features and/or a memory chip with more capacity (and/or additional LED(s) and/or button(s) as described above) may need to be used when the Caller ID uploading feature is added to dialer 2. A liquid crystal display screen or the like can be added to the dialer to allow caller information to be viewed before the user decides whether to upload it, without having to also use a standard, stand alone Caller ID display unit. The circuitry of dialer 2 can be configured to allow the dialing and/or Caller ID features to be utilized by either of two phone lines plugged into input phone jack 14 (with a single 4-conductor plug.) For example, whichever of the two lines goes off- hook first would be used to dial the phone number on in step 152 shown in Fig. 2F. Similarly, the dialer could retrieve Caller ID information off of either phone line, and even record which phone line the call came in on, if desired. At a minimum, it is preferable that a second phone line at least be passed through the dialer between jacks 14 and 16 to allow an attached telephone to connect to them both. Dialer 2 preferably uses analog tones (DTMF) to speed-dial the phone numbers sent to it by a PDA. Since many office phone systems (i.e. digital PBX's) recognize only proprietary digital signals sent to them by the phone and do not return a standard analog dial tone or off-hook signal to the phone, dialer 2 as described above may not work with such systems. In another alternative embodiment, the dialer can be constructed similar to a "digital adapter" that plugs inline with the coiled cord between the handset and the telephone, rather than between the telephone and the wall jack. Most all digital telephones will then pass the analog dial tones from the dialer through to the PBX for dialing. Alternatively, dialer 2 can be plugged into an off-the-shelf digital adapter which in turn plugs into the handset cord. Referring to Figs. 5a and 5b, a flowchart showing operation of an alternative embodiment is shown. This embodiment is similar to that shown in Figs. 2a-2f. but is somewhat simplified to produce a smaller code size, and it takes advantage of the "sleep" mode of the National Semiconductor microprocessor listed above. The sleep mode arrangement shown allows the dialer to remain in a low power consumption mode when not in use to extend the life of the batteries, but does not require any extra steps for the user to wake up the dialer. The transceiver is always on and ready to detect an incoming IR (or RF) transmission. If such should occur, the detected signal is used to wake up the microcontroller from a dormant state. The microcontroller then tries to establish a communication link with the transmitting device using the IrDA Lite communication protocol. If that process succeeds both LED colors (amber) are illuminated; if it fails, then only the red LED is illuminated and the microcontroller after a short interval reverts to its dormant state. If , however, the microcontroller detects that the data transmitted was a vCard containing a valid telephone number (or area code), then the green LED is illuminated, and the digits representing the number are stored as eight bit binary numbers in battery-backed RAM which is an integral part of the microcontroller. The microcontroller is enabled for "dialing" when the "off-hook" condition is sensed. This is accomplished by detecting an appreciable telephone line (loop) current flowing through the telephone interface circuit. Dialing is initiated automatically after a suitable delay. Alternatively, the device can be programmed by the user to postpone dialing until signaled to do so by the pressing of a single push button. The dialing process consists of modulating the on-hook telephone line current with a series of dual simultaneous audio tones which represent the digits being dialed in accordance with the applicable FCC Telephone Regulations (Part 68) and the TIA/CIA-470 Standard. The transistor modulator is electrically driven by a DAC that derives its input from a microcontroller output port. Low battery condition by sensed by the MAX6377 battery status monitor. The microcontroller monitors the status of the MAX6377 whenever it has established a new communication link. If the battery is low, the LEDs are alternately flashed red and green for a brief period. This modality of response makes it more likely that the user is present to observe the alarm rather than uselessly flashing the high current LEDs every time there is some stray IR pick-up from irrelevant sources. In order to maximize battery life, the dialer is designed to be compliant with the Low Power version of the IrDA Communication Protocol Specification. During sleep mode, it is envisioned that the dialer will not draw more than 100 microamperes from its battery power supply. During the data acquisition phase shown in Fig. 5a, the dialer tries to set up a IR communication link. It expects to be communicating with an IrDA compliant PDA such a Palm or Handspring Visor handheld. If it is unable to do this it shuts down and waits for the next IR incident (or hook switch or push button closure). If a link is successfully established it then examines the incoming data stream and tries to find the main phone number field in a vCard file marked with "PREF". If successful it stores it in RAM in one of several places. A three digit long number is recognized as the local area code and stored accordingly. Longer numbers, e.g., 10 or 7 digits, are stored as the main phone number. Preliminary to the process of parsing the number, all extraneous separator characters are stripped away as is the "one" prefix, should there be one. Finally the vCard main number can be used to program the dialer to enter a mode whereby it will automatically dial the stored phone when the phone is taken off-hook. This is accomplished by means of a pre-determined symbol(s) inserted in place of an actual (main) phone number. The dialer sets an Auto Dial flag if it recognizes the symbol or clears the flag if it finds a disable symbol instead. (In the latter case dialing is initiated by means of the push button.) In the dialing mode (Fig. 5b), the microcontroller in the dialer produces dual tone sequences that are used to modulate the telephone line current and generate the dialing signals. Also decisions are made whether to use an area code (and the one prefix) or not based on whether the user had previously stored the local area code in the dialer. If the user has programmed it, the dialing sequence can be entered into automatically after a number is downloaded provided, of course, the phone is off-hook or taken off hook soon after the downloading has occurred. If the user elects not to place the phone off hook in a timely way then future dialing must be initiated by means of the push button. Referring to Figs. 6a and 6b, other embodiments of the inventive dialer will be described. Specifications and technical details regarding the emerging "Bluetooth" wireless standard can be found at www. bluetooth.com. However, as of the filing date of this application, details of the first few mobile devices employing Bluetooth communication capabilities are just starting to be unveiled. Accordingly, exact details of how the above dialer can be constructed to communicate with such mobile devices are unclear. It is expected, however, that PDA's and other mobile devices that will be coming to market will function in a very similar manner as described above for IR when exchanging information by RF, such as vCards. People of ordinary skill in the art can modify the dialer embodiments taught herein to communicate with new mobile devices by RF instead of (or in addition to) IR by following the published RF specifications instead of the IR specifications. The RF link will preferably be initiated by the mobile device without the need for add-on application software by using the functionality that will be built into the mobile device. The dialer can receive a phone number (preferably by vCard) from a mobile device and dial it just as described above, the only real difference being that the information is transmitted by RF instead of IR. Fig. 6a shows a mobile device communicating with the dialer by IR (depicted by waves) and/or by RF (depicted by lightning bolt), and the dialer connected in series with an ordinary phone to a dial-up telephone network, as previously described. Referring to Fig. 6b, another embodiment is shown wherein the dialer described above is built into a telephone. Such an arrangement provides the same or increased functionality as that previously described at a reduced total cost and size since the phone and dialer would share a common enclosure, circuit board, processor, power source, phone jack, etc. Additional features could include the ability to store multiple phone numbers in the phone. Such a phone would be programmed and dialed similar to a conventional phone having speed dialing features, except the numbers would be beamed to the phone instead of being manually entered. Additionally, a name could be extracted from each vCard beamed to the phone for display on an LCD screen or screens in association with the corresponding phone number or push button. As previously stated, the mobile device depicted in Figs. 6a and 6b can a PDA, a cell phone, a laptop/notebook computer, or any other mobile device that can store and communicate a vCard or other information block having a phone number via IR or RF. The above descriptions and drawings are for illustrative purposes only, and are not exhaustive of possible alternate embodiments of the invention. It is to be understood that the present invention is not limited to the embodiments described above and illustrated herein, but encompasses any and all variations falling within the scope of the appended claims and their equivalents.

Claims: WHAT IS CLAIMED IS: 1. An electronic device comprising: means for directly wiring the device to a land-based telephone line; means for generating DTMF dialing tones and transmitting the dialing tones through the wiring means to a telephone line; means for receiving a predetermined telephone number to be dialed from a mobile unit by an infrared link; means for controlling the device, wherein the controlling means permits a user to cause a predetermined telephone number to be dialed by the generating and transmitting means without any physical interaction between a user and the device; and means for housing the wiring means, the generating and transmitting means, the receiving means, and the controlling means together in a fixed location. 2. An electronic device as recited in claim 1, further comprising means for sensing when a telephone co-wired to a telephone line is off-hook, and wherein the controlling means enables the generating and transmitting means responsive to the sensing means. 3. An electronic device as recited in claim 1, further comprising means for transmitting signals back to a mobile unit by an infrared link, the receiving means, the transmitting means, and the controlling means cooperating to emulate a personal digital assistant receiving an electronic business card. 4. An electronic device as recited in claim 1 , wherein the controlling means includes means for entering a sleep mode after a predetermined amount of time to conserve power, and wherein the sleep means awakens the controlling means responsive to the receiving means detecting infrared activity. 5. A telephone dialing system comprising: a mobile unit having means for storing a plurality of names, addresses and telephone numbers therein; means for wirelessly communicating with other mobile units to send and receive predetermined groups of information selected from the names, addresses and telephone numbers; means for selecting a telephone number for dialing; means for initiating a sequence to transmit the selected telephone number through the communicating means to a fixed unit for dialing; a fixed unit having means for connecting to a land-based telephone line; means for generating DTMF dialing tones and transmitting the dialing tones through the connecting means to a telephone line; means for wirelessly receiving the selected telephone number from the mobile unit; and means for controlling the fixed unit, wherein dialing of the selected telephone number by the generating and transmitting means of the fixed unit can be initiated by the initiating means of the mobile unit rather than by the fixed unit, and wherein telephone voice signals are not communicated between the mobile unit and the fixed unit. 6. A telephone dialing system as recited in claim 5, wherein the fixed unit further includes means for sensing when a telephone co-connected to a telephone line is off-hook, and wherein the controlling means enables the generating and transmitting means responsive to the sensing means. 7. A telephone dialing system as recited in claim 5, wherein the wireless communicating means of the mobile unit and the wireless receiving means of the fixed unit cooperate to establish a two-way wireless link between the mobile unit and the fixed unit for transferring an entire electronic business card including the selected telephone number to be dialed from the mobile unit to the fixed unit. 8. A telephone dialing system as recited in claim 5, wherein the controlling means of the fixed unit includes means for entering a sleep mode after a predetermined amount of time to conserve power, and wherein the sleep means awakens the controlling means when activity in the wireless receiving means is detected. 9. A telephone dialing system as recited in claim 5, wherein the wireless communicating means of the mobile unit and the wireless receiving means of the fixed unit each include infrared transceivers. 10. A telephone dialing system as recited in claim 5, wherein the wireless communicating means of the mobile unit and the wireless receiving means of the fixed unit each include radio transceivers. 1 1. A telephone dialing system as recited in claim 10, wherein the wireless communicating means of the mobile unit and the wireless receiving means of the fixed unit are compatible with a Bluetooth standard. 12. A telephone dialing system as recited in claim 5, further comprising means for operating the storing means, communicating means, selecting means, and initiating means of the mobile unit, wherein the operating means consists of a standard operating system preexisting on the mobile unit, and does not comprise add-on application software. 13. A telephone dialing system as recited in claim 5, wherein the fixed unit further comprises means for producing a ringing sound, means for placing a telephone line in an off-hook condition, means for manually dialing telephone numbers, and means for converting voice acoustics into electrical signals and vice versa. 14. A telephone dialing system as recited in claim 5, wherein the fixed unit does not comprise means for producing a ringing sound or means for converting voice acoustics into electrical signals and vice versa.

Inventors: LIMBACH DOUGLAS C, LIMBACH, DOUGLAS, C.
Applicants: LIMBACH DOUGLAS C, LIMBACH, DOUGLAS, C.
Application year: 2000
Main classification: H04M
IPC codes: H04M1