Wireless smart phone

Description of equivalent WO 9750222 A1

Wireless Smart Phone

Background of the Invention

1. Field of the In vention

The present invention relates to a telephone device. More particularly, the present invention relates to a telephone device configured for use on a wireless or cellular network. Still more particularly, the present invention relates to a telephone device that includes a computer system that enables the telephone device to perform data processing functions.

2. Related Art

Telephone communication is an integral part of the business and personal lives of most individuals in society today. With the advent of wireless or cellular telephones, many individuals carry a telephone on their person or have a telephone in their car. However, performing tasks with such a conventional telephone requires that a call be placed to a service provider to perform such tasks. The types of tasks or functions that the telephone can perform are thus limited to the services offered by a service provider. For example, the Sprint Spectrum^SM Service provides an answering machine service. However, to retrieve the messages from the answering machine, a call must be placed to the service provider. Further, the speed or efficiency of performing these functions is dependent upon the service provider, and service bottle-necks can occur.

Many individuals also routinely carry a calculator to perform various types of calculations. For example, a real estate agent would normally have a calculator to perform some calculations regarding the price or interest rates for purchase of a home. A real estate agent would also routinely carry a telephone in order to maintain contact with buyers and sellers. Some individuals routinely carry a personal recorder or dictating machine so that recordings or notes can be made at any time. Some individuals also routinely require access to a device for sending and receiving facsimile messages. However, no single device is available that allows a user to make and receive telephone calls, use a calculator, make recordings on a recorder, and send and receive facsimiles. Therefore, there is a need in the art for a single device that is capable of providing telephone communication, as well as performing various other functions or tasks routinely required by an individual.

Summary of the Invention

In one embodiment, the present invention is a telephone device that includes a connecting circuit for connecting the telephone device to a network to enable it to receive and initiate telephone calls over the network. The telephone device also includes a computer system for controlling the telephone device to allow a user to perform data processing functions. The computer system can include a processor, data means for transmitting and receiving data over the network, and a memory device for storing computer program logic or software that is used to control the processor. The telephone device includes means for accepting input from a user; the input is implemented through user interface interrupt vectors that enable the processor to operate the telephone device to perform data processing functions selected by the user. An on-hook status message can be provided to the network so that telephone calls can be received while the telephone device is in the off-line mode. The telephone device can also include an answering device for playing an outgoing message when an incoming telephone call is not answered after a predetermined number of rings. The telephone device can also be configured with a recorder for recording an audible message, and a playback device for playing the audible message.

In a further embodiment of the present invention, the telephone device is equipped with calculating means to configure the telephone device to function as a calculator. The telephone device can also be equipped with facsimile means for receiving and transmitting facsimile messages over the network. The telephone device may further include macro means for defining an invocable sequence of telephone buttons.

In yet a further embodiment of the present invention, a method for controlling operation of a telephone device is provided in order to install telephone device processing software. The method of controlling operation for performing installation includes: establishing a connection between the telephone device and a software provider over a network; downloading computer program logic from the software provider into the telephone device for controlling a processor; and installing user interface interrupt vectors in a memory device coupled to the processor. The user interface interrupt vectors are used to enable appropriate processing which is associated to corresponding user interface telephone key operation. The user interface interrupt vectors are used in configuring the telephone device to perform data processing functions selected by a user.

In yet a further embodiment of the present invention, a method for processing of a telephone call by a telephone device is provided. This process includes: determining whether the telephone device is in an off-line mode; answering the telephone call if the telephone device is in the off-line mode; and ringing a ringer if the telephone device is not in the off-line mode. Upon answering the telephone call, when in the off-line mode, a facsimile is processed if a facsimile tone is detected. An answering device sequence is initiated if a facsimile tone is not detected. Upon ringing a ringer, if the telephone device is not in the off-line mode, a received call processing sequence is initiated if the telephone call is not answered after a predetermined number of rings.

In yet a further embodiment of the present invention, a method for controlling operation of a telephone device is provided that includes: receiving a telephone button sequence that initiates an off-line mode that allows a user to perform data processing functions; and configuring the telephone device to perform data processing functions selected by the user. An on-hook status message can be sent to a telephone network switch so that telephone calls can be received while the telephone device is in an off-line mode. The data processing functions can include recorder functions to record a new recording, to play a recording, to delete a record corresponding to a recording, or to browse through a stored arrangement or index table of recordings. The data processing functions can also include facsimile functions to send a facsimile. The facsimile sent may be a facsimile previously received by the telephone device, or it may be a speech recording.

Features and Advantages

It is a feature of the present invention that the telephone device operates in an off-line mode that allows a user to perform off-line functions. It is a further feature that telephone calls can be received and processed while the telephone device is in off-line mode.

It is a further feature of the present invention that functionality can be updated or added to the telephone device via software downloaded over a telephone network from a software provider.

It is yet a further feature of the present invention that the telephone device performs the function of an answering device, with incoming messages recorded and stored on the telephone device itself. This eliminates the need to make a separate call to a service provider to review or retrieve recorded messages.

It is yet a further feature of the present invention that the telephone device operates as a recorder in the off-line mode to allow a user to make recordings. It is a further feature of the present invention that it operates as a recorder in the on¬ line mode to allow a user to record one or both sides of a telephone call. It is yet a further feature of the present invention that the telephone device provides facsimile or data receipt and transmission.

It is still a further feature of the present invention that the telephone device can be configured to function as a calculator. It is a further feature that the telephone device can play any previously saved recordings (recorded or answer device messages) in off-line mode, or play to one or both sides of a telephone call.

It is an advantage of the present invention that all recordings, including incoming answering machine recordings, are stored on the telephone device itself.

All recordings can be reviewed using only the telephone device, without having to make a call to a service provider.

It is a further advantage of the present invention that one device can perform a multitude of functions, including, for example, initiating and receiving telephone calls, as well as calculator, recorder, facsimile, and answering device functions.

It is yet a further advantage of the present invention that facsimile messages can be received or transmitted while a telephone call is in progress.

It is yet a further advantage of the present invention that personalized macros can be defined to automate pressing of telephone buttons to automatically navigate through customer service or automatic response unit menus.

Brief Description of the Drawings

The present invention is described with reference to the accompanying drawings. In the drawings, like reference numbers indicate identical or functionally similar elements. Additionally, the left-most digit(s) of a reference number identifies the drawing in which the reference number first appears.

FIG. 1 shows a telephone device of the present invention configured to download software;

FIG. 2 shows one embodiment of a schematic for the telephone device of the present invention;

FIG. 3 shows a flow diagram for downloading software to the telephone device of the present invention; FIG. 4 shows a flow diagram for operating the telephone device of the present invention in an on-line mode;

FIG. 5 shows a flow diagram for placing the telephone device of the present invention in an off-line mode; FIG. 6 shows a flow diagram for receiving a call from a switch;

FIG. 7 shows a flow diagram for monitoring the selection by a user of off¬ line functions;

FIGS.8A through 8C show flow diagrams for configuring the telephone device of the present invention to function as a calculator; FIGS. 9A and 9B show flow diagrams for configuring the telephone device of the present invention to function as a recorder;

FIGS. 10A through IOC show flow diagrams for configuring the telephone device of the present invention to function as a facsimile transmitting and receiving device; FIG. 11 shows a flow diagram for specifying an answering outgoing message;

FIG. 12 shows a flow diagram for configuring the telephone device of the present invention to function as an answering device to record a message; and

FIGS. 13A through 13F show flow diagrams for configuring the telephone device to store and execute user-defined sequences of keystrokes.

Detailed Description of the Embodiments

1. Overview

The telephone device of the present invention is configured to operate as a wireless telephone device for receiving and initiating telephone calls over a network. Such a network can be a digital or analog network, such as a cellular telephone network made available by a network provider. The telephone device of the present invention also contains a computer system that enables the telephone device to perform data processing functions, including functions in an off-line mode. Technology is producing smaller and faster parts. It is possible to manufacture data processing systems into small devices, such as a telephone device. Telephone calls can be received while the telephone device of the present invention is in off-line mode. Such data processing functions can include, for example, calculator, recorder, facsimile, and answering device functions. A further function which is operated at any time (on-line or off-line mode) includes a macro function that enables an invocable sequence of telephone buttons to be defined. The invocable sequence can be defined by the user.

To accomplish the data processing functions, the telephone device of the present invention is preferably configured with a processor, one or more memory devices, and data means for transmitting and receiving data over the network. The processor is controlled by computer program logic or software that is stored in a memory device. Software can be downloaded via the network to the telephone device of the present invention by dialing in to a software provider. This enables the software to be updated, and to add additional functionality to the telephone device. When configured to operate as a recorder, hot keys are provided so that the user can toggle record mode during a call, or in the off-line mode. Other recorder functions, as discussed below, operate only in the off-line mode. When configured as an answering device, the telephone device of the present invention answers incoming calls while the telephone is in the off-line mode, or if the telephone call is not answered in a predetermined number of rings. The telephone device of the present invention also functions as a facsimile device. For in-bound facsimile messages, the telephone device functions similar to an answering device, but facsimile processing is automatically initiated when the facsimile tone is detected. Previously received facsimile messages or voice recordings can be transmitted out as a facsimile message. The telephone device of the present invention can also be configured to operate as a calculator in the off-line mode. A hot key, for example the pound (#) prefix, can be used to enter the calculator mode. In an alternate embodiment of the present invention, a hot key allows a user to enter the calculator mode during a telephone call, to allow both parties to hear the results of a particular calculation.

2. Description of the Telephone Device

FIG. 1 shows a telephone device of the present invention which will also be referred to herein as a Smart Phone. The telephone device is configured as a handset 100 that includes an antenna 102, a keypad 104, a speaker 106, and a microphone 108. Alternatively, handset 100 could also include a display for displaying alphanumeric characters, or graphics, to a user. Internal to handset 100 is a computer system 110 that includes a processor 112 having a central processing unit (CPU) 114 and a main memory 116. A modem 119 is included for transmitting and receiving data over the network. A direct access storage device (DASD) 118 or equivalent secondary memory capable of long term non¬ volatile storage, such as a hard drive, is provided. DASD 118 can store computer program logic or software, as well as other data generated through operation of the telephone device. As shown in FIG. 1 , software 122 can be downloaded to handset 100 from a software provider 120 over the network.

One embodiment of a schematic for the telephone device of the present invention is shown in FIG. 2. Central processing unit (CPU) 114 is connected to a digital bus 214. Digital bus 214 is a communication bus to which the various components shown in the schematic of FIG. 2 are connected. Three memory or storage devices are connected to digital bus 214. The first memory or storage device is DASD 118. The second memory or storage device is a random access memory (RAM) 218. The third memory or storage device is a read only memory

(ROM) 216. Computer program logic or software is stored in DASD 118, and/or RAM 218, and/or ROM 216. Such computer programs, when executed, enable computer system 110 to perform the features of the present invention as discussed herein. In particular, the computer programs, when executed, enable CPU 114 to perform the features of the present invention. Accordingly, such computer programs or software represent controllers of computer system 110.

The telephone device of the present invention includes a connecting circuit for connecting the telephone device to a network to enable the telephone device to receive and initiate telephone calls over the network. In the preferred embodiment, the connection to the network is a wireless one, such as in a cellular phone system. It would be apparent to one skilled in the relevant art that the phone connection could alternatively be a wire-line connection.

As shown in FIG. 2, radio frequency (RF) signals are received by antenna 102. A circulator 202 is provided to prevent mixing of RF signals going out with RF signals coming in on antenna 102. Radio frequency signals received by antenna 102, denoted by reference numeral 290 in FIG. 2, are input to a receiver 260. Receiver 260 converts RF signal 290 to an analog signal carried on a receive analog line 261. The receive analog signal on receive analog line 261 is input to speaker 106. In like manner, an analog signal carried on a transmit analog line 251 is input from microphone 108 to a transmitter 250. Transmitter 250 converts the transmit analog signal from transmit analog line 251 to RF out signal 280 which is transmitted via antenna 102.

As shown in FIG. 2, keypad 104 is connected to digital bus 214 via a keypad matrix interface 204. Keypad matrix interface 204 monitors for pressing of the telephone buttons on keypad 104 by the user. Keypad matrix interface 204 is not enabled unless the telephone device is off-hook, or the telephone device is in an off-line mode to be discussed further below. When keypad matrix interface 204 determines that telephone buttons on keypad 104 have been pressed by the user, the sequence of pressed telephone buttons is sent to CPU 114. This is accomplished through the use of an interrupt request, identified in FIG. 2 as IRQ on a line 205 connecting keypad matrix interface 204 to digital bus 214. CPU 114 processes the sequence of keys sent to it by keypad matrix interface 204 and maps the telephone button sequence to the command or function selected by the user. The connecting circuit of the telephone device also includes a tone detector 222 connected to digital bus 214. Tone detector 222 is tapped into the receive analog signal of receive analog line 261 at a tap 263. Tone detector 222 monitors the receive analog signal on receive analog line 261 to detect a facsimile tone to determine if the receive signal corresponds to an incoming facsimile or a telephone call. Tone detector 222 is particularly useful in the embodiment where transmitter 250 and receiver 260 are shared between modem 119 and other telephone processes.

A signal detector 228 is connected to digital bus 214 to receive the analog signal of receive analog line 261 at a tap 264. Signal detector 228 detects a unique identifier, CPU 114 instructs a ringer 224 to ring indicating that a telephone call is being sent to the telephone device. While ringer 224 is ringing, CPU 114 monitors for receipt of an off-hook detection from an on/off hook detector 226. On/off hook detector 226 sends an off-hook message to CPU 114 if the phone is picked up by the user. The off-hook message is sent to CPU via an interrupt, noted in FIG. 2 as IRQ on a line 227 connecting on/off hook detector

226 to digital bus 214. Signal detector 228 also detects when incoming RF signal 290 has terminated, such as when the other party has hung up. An alternate embodiment may eliminate tone detector 222 by performing tone detection as part of processing with signal detector 228. A tone/signal generator 229 is connected to digital bus 214 to transmit an analog signal onto transmit analog line 251 at a tap 253. Tone/signal generator 229 is used to generate a tone/signal that is transmitted as RF by transmitter 250. The tone/signal generated by tone/signal generator 229 is used to dial digits of a telephone number, to terminate a telephone session, and to change the status from off-hook to on-hook to enable the telephone device to receive another call.

In order to enable a user to hear their own voice in speaker 106, a sidetone connection is provided from microphone 108 to speaker 106. The voice signal from the telephone user is dampened, and mixed with the signal being received from the other party. To do so, a tap 255 is made into transmit analog line 251.

The sidetone signal is then dampened through element 208 and sent through a switch 206 to receive the analog signal of receive analog line 261 at a tap 268. In this manner, a user listening into speaker 106 will hear both their own voice as well as the voice of the party to whom they are speaking. Amplifiers and filters necessary to achieve proper mixing of the signals have been omitted for clarity, and would be readily apparent to one skilled in the relevant arts.

In order to make recordings, the telephone device of the present invention is equipped with an analog-to-digital (A/D) converter 242 that is connected to digital bus 214. A/D converter 242 is used to convert analog signals to digital signals that can be stored or recorded on DASD 118 or RAM 218. DASD 118 and RAM 218 thus function as recorders of audible messages. To record a message generated by the user, the user speaks into microphone 108. This analog signal is accessed at a tap 257 in the transmit analog signal of transmit analog line 251. The tapped signal is then sent from tap 257 through a switch 241 to A/D

242 through a tap 243. To record a party other than the user, or both the user and a telephone-connected party, a tap 265 is provided to receive the analog signal of receive analog line 261. The tapped signal is sent via a switch 240 and tap 243 to A/D converter 242. Thus, CPU 114 operation of switch 240 and switch 241 enable off-line recording for the recording of one or both sides of a telephone call. The telephone device of the present invention can also play messages that have been recorded. To do so, a digital-to-analog (D/A) converter 244 is provided. To play a recording that is heard by the user through speaker 106, the signal is sent from D/A 244 through a tap 247 and a switch 246 into receive analog signal 261 at a tap 267. The tapped signal is then sent to speaker 106 so that it can be heard by the user. To enable a party other than the user to hear the played recording, the signal is sent from D/A converter 244 through tap 247 and a switch 245 to transmit the analog signal on transmit analog line 251 at a tap 254. The signal is then transmitted to the other party by transmitter 250. A clock 220 is connected to digital bus 214. Clock 220 is used to provide a date and time identifier for the various recordings made by the telephone device of the present invention. A battery (not shown) ensures that clock 220 continues to operate.

To facilitate sending and receiving of data, such as computer program logic or software, and facsimile messages, modem 119 is provided. Modem 119 is connected to digital bus 214 via a modem interface 270. Modem interface 270 functions as a data interface between digital bus 214 and modem 119. Alternatively, modem 119 could be hard wired to digital bus 214. Modem interface 270 is connected on a transmitter side of modem 119 to a modulator module 235. Modulator module 235 is connected to a transmitter module 236 and a transmitter synthesizer 237. Transmitter module 236 is connected to an RF out line 231. RF out line 231 connects via a switch 232 to RF out signal 280 at a tap 252. Data to be transmitted out of the telephone device via modem 119 is retrieved from one or more of the memory or storage devices and sent via digital bus 214 to modem interface 270. The data to be sent is then transmitted from modem interface 270 into the transmitter side of modem 119 where it is converted to an RF signal.

Modem 119 also includes a receive side that has a demodulator module 238 that is also connected to modem interface 270. A receive module 239 and a receive synthesizer 230 are connected to demodulator module 238. RF signals to be received by modem 119 are accessed at tap 262 in RF in signal 290. This RF signal is sent via a switch 234 to an RF in line 233 connected to receive module 239. The receive side of modem 119 converts the incoming RF signal into digital data that is sent via modem interface 270 to digital bus 214 for storage on one or more of the memory storage devices.

In the embodiment shown in FIG. 2, modem 119 uses a transmitter and receiver separate from transmitter 250 and receiver 260. In the preferred embodiment, transmitter module 236 of modem 119 operates at a frequency different from the operating frequency of transmitter 250. Likewise, receiver module 239 of modem 119 operates at a frequency different from the operating frequency of receiver 260. This allows for simultaneous use of the telephone device to transmit and receive messages via modem 119 while on a telephone call using transmitter 250 and receiver 260. Consequently, a user can send or receive a facsimile message while on a telephone call. To implement this feature, modem 119 is preferably configured as shown in FIG. 2, between circulator 202 and transmitter 250/receiver 260 used for telephone calls.

In an alternate embodiment, modem 119 can be configured to use transmitter 250 and receiver 260. In yet another embodiment, a separate modem is not provided, and modem functionality is provided by software. In such an embodiment, transmitter 250 and receiver 260 are used to transmit and receive facsimile messages. Consequently, such an embodiment does not allow facsimile messages to be transmitted or received while a telephone call is in progress. However, such an embodiment may be advantageous because of reduced cost and reduced size of the telephone device. In the embodiment shown in FIG. 2, CPU 114 provides standard bus control over the devices connected to digital bus 214. It is to be understood that when the switches shown in FIG. 2 are closed, the switch is in an "on" state. When the switches shown in FIG. 2 are open, the switch is in an "off state. All switches are controlled by CPU 114 through digital bus 214 (connection of switches to digital bus 214 not shown). The state of the various switches will now be described for operation of the telephone device. All switches are assumed to be open, except as indicated in the following descriptions.

When the telephone device is powered and ready to receive a call, the switches shown in FIG. 2 are open, i.e., in an off state. Signal detector 228 is in a monitoring mode, monitoring for its unique identifier to lock onto the appropriate RF signal. When signal detector 228 detects the unique identifier, the signal is locked and CPU 114 causes ringer 224 to begin ringing. While ringer 224 is ringing, CPU 114 is waiting for an off-hook interrupt request from on/off hook detector 226 indicating that the phone has been picked up. If an off-hook interrupt request is not detected in a predetermined number of rings, a received call processing sequence will be initiated. The call is answered and an outgoing message is retrieved from DASD 118. The digital file corresponding to the outgoing message is sent to D/A converter 244 which converts the outgoing message to an analog signal. Switch 245 is closed, and the analog outgoing message is sent to transmitter 250 where it is converted to an RF signal that is transmitted out to the party on the other end of the telephone call. Switch 256 is open to assure no noise is mixed with the outgoing message. In a preferred embodiment, switch 246 remains open while switch 245 is closed to play the outgoing message to the other party. Alternatively, switch 246 could be closed at the same time that switch 245 is closed. By closing switch 246, the outgoing message would be played through speaker 106 at the same time it was being transmitted to the party on the other end of the line. Likewise, switch 266 can be open to assure no incoming signals are transmitted to speaker 106.

The outgoing message preferably concludes with a "beep" that prompts the person at the other end of the line to leave a message. Once the beep is issued, switch 245 is opened which turns this switch off. D/A converter 244 is also turned off. Switch 240 is then opened and A/D converter 242 is turned on. The message to be recorded is received as the receive analog signal on receive analog line 261 and routed to A/D converter 242 through switch 240. The analog signal is then converted by A/D converter 242 into a digital file that is recorded on DASD 118 or RAM 218. Preferably, the recording continues for a predetermined and configurable amount of time. The recording is cut off after a set amount of time (e.g., 30 seconds or 45 seconds) to preserve disk space. To cut off recording, switch 240 is opened. A signal is generated by tone/signal generator 229 to terminate the telephone call, and place the telephone device on- hook to enable it to receive another telephone call. Switch 266 can be open to assure no incoming signals are transmitted to speaker 106.

When a call is answered by a user, the user picks up before the specified number of rings which places the telephone device off-hook. Switch 266 is closed so that the received signal can be heard on speaker 106. Switches 256 and

206 are then closed substantially simultaneously. In this manner, bi-directional analog signals are sent through microphone 108 and speaker 106 to the person at the other end of the telephone call. The user of the telephone device of the present invention can hear not only what is being said by the party at the other end of the telephone call, but also what they are saying as well. The telephone call can be terminated either by the user of the telephone device of the present invention, or the party at the other end of the telephone call. If the other party terminates the call, signal detector 228 detects that the received signal has been terminated, indicating that the other party has hung up. Alternatively, the user of the telephone device of the present invention can terminate the telephone call by putting the telephone device on-hook. Tone/signal generator 229 then generates a tone signal that terminates the telephone call. Once the telephone call is terminated by either party, the telephone device is in an on-hook status, and the switches are then placed in an open state. As explained more fully in Section 3 below, the telephone device of the present invention can be placed in an off-line mode that allows a user to perform off-line functions. To ensure that telephone calls can be received while the telephone device is in off-line mode, the network must think that the telephone device is on-hook, and ready to receive a call. Once handset 100 is picked up by the user to perform off-line functions, the network thinks that a call is going to be placed and identifies the telephone device as being off-hook. Therefore, a signal is sent to the network to indicate that the telephone device has been hung up, even though it has not and will be used in an off-line mode. An on-hook status message is provided to the network so that the network thinks the telephone device is on-hook so that the telephone device can receive telephone calls while in the off-line mode.

A user of the telephone device of the present invention can make a recording using the off-line recorder functions. When the user selects this feature, switch 241 is closed, and A/D converter 242 is turned on. The user speaks into microphone 108 and the analog signal, accessed at tap 257, is transmitted to A/D converter 242 where it is converted into a digitized file. The digitized file is then transmitted via digital bus 214 to either RAM 218 or DASD 118. RAM 218 is used to buffer or queue recorded files which are then archived on DASD 118. When recording is finished, A/D converter 242 is stopped and switch 241 is opened. The recorded file is archived on DASD 118 using a unique file name.

A recording can also be made while a telephone call is in progress. It is possible to record not only the user of the telephone device of the present invention, but also the connected party on the other end of the telephone call.

While a telephone call is in progress, switches 256, 206, and 266 are closed. To record both sides of a telephone call in progress, switch 240 and switch 241 are both closed. By closing switch 240, the connected party is being recorded. By closing switch 241, the user of the telephone device that is speaking into microphone 108 is being recorded.

The off-line recorder functions of the present invention also allow a user to play a recording which has previously been made. The user identifies the recording to be played by selecting and entering an index number. The recording to be played is identified by a record in an index table that includes the index number. Once a recording to be played has been identified by the user, switch 246 is closed. The selected recording file to be played is transferred from DASD 118 via digital bus 214 to D/A converter 244 where it is converted to an analog signal. The analog signal is then sent through switch 246 so that the recording is played on speaker 106. If during an actual telephone call (switches 256, 206. and 266 are closed) switch 245 is closed in addition to switch 246, the recording being played can be heard through speaker 106 as well as by the connected party. The recording being played is transmitted to speaker 106 by closing switch 246.

The recording being played is transmitted to the connected party through switch 245.

In the embodiment shown in FIG. 2, modem 119 has its own transmitter and receiver that are operating on frequencies different from transmitter 250 and receiver 260 used for telephone calls. In such an embodiment, switch 234 is closed at all times to be monitoring for an incoming RF signal with the appropriate unique identifier. Switch 232 is closed appropriately during times of modem 119 transmitting. For example, switch 234 remains closed to monitor receipt of an incoming facsimile message. Switch 232 is closed only when a facsimile message is actively being transmitted out of modem 119 or communications protocol is being managed.

The telephone device of the present invention can be configured to function as a calculator in the off-line mode. In a preferred embodiment, the calculator functions are controlled by software that is contained in DASD 118. When the calculator function is selected by the user in off-line mode, this software, if not already in memory, is loaded into RAM 218. Switch 246 is closed so that speaker 106 can be used for the calculator function. For example, instruction messages are provided over speaker 106 to the user. Additionally, the operations being performed, the result of such operations, and confirmation messages may also be pronounced to the user over speaker 106. The appropriate information is sent from CPU 114 via digital bus 214 to D/A converter 244. The analog signal is then sent via switch 246 to speaker 106. 3. Method of Operation of the Telephone Device

To achieve a reduced product cost, and to describe what would otherwise be unobvious processing, FIG. 3 and all subsequent figures assume that modem functionality is integrated using the same transmitter 250 and receiver 260 as other telephone device processes.

Operation of the telephone device of the present invention is controlled by CPU 114. Computer program logic or software is used to control CPU 114. In a preferred embodiment, ROM 216 includes a minimal operating system that is used to load and initialize software into the telephone device of the present invention. A flow diagram for downloading software to the telephone device of the present invention is illustrated in FIG. 3. The process shown in FIG. 3 may be used to initially configure the telephone device with software, or to provide periodic updates or software refresh to the telephone device. To do a software download, the phone is picked up and taken off-hook. In a step 302, a session is established with a service, such as software provider 120. The session is established with the service by dialing a number such as a 1-800 number or a local number. The service can be an automatic response unit (ARU), or a voice response unit (VRU). In a preferred embodiment, CPU 114 instructs modem 119 to establish the session with the service. Modem 119 then dials the correct number for connecting to the service, and controls all of the handshake signals that are required. In an embodiment without a separate modem, CPU 114 would directly control establishing the session with the service.

In a step 304, software 122 is downloaded to the telephone device of the present invention. The software download is a data transfer from software provider 120 into the telephone device. In a preferred embodiment, once the modem connection is established, the software is downloaded immediately without any menu prompting. The downloaded software is stored on DASD 118. In doing so, user interface interrupt vectors (UIIV) are installed, as indicated in a step 306. The user interface interrupt vectors are used in correlating particular additional functions with certain key invocations on the telephone device. Once the software download is completed, the session is terminated, as indicated in a step 308.

The software download of FIG. 3 must be performed at least once to equip the telephone device of the present invention with its complete functionality.

Particularly, the software download of FIG. 3 is used to configure the telephone device with all functions. The software download of FIG. 3 can be repeated to provide updates or refresh of the software contained in the telephone device. The software download of FIG. 3 can also be used to add additional functionality to the telephone device.

Each key on keypad 104 has an associated user interface interrupt vector. Additionally, predefined sequences of keys on keypad 104, referred to herein as a macro or macro sequence, has an associated user interface interrupt vector. The interrupt vector is a list of memory addresses which point to terminate and stay resident (TSR) software functions. A certain sequence maps to particular TSR functions by way of the specified interrupt vector entry. The user interface interrupt vector is a function assigned to the particular key or sequence of keys. The user interface interrupt vector includes the memory address where that function is resident. User interface interrupt vectors ensure that when a particular key or macro sequence is pressed, the associated process or function is executed first. This allows the keys on keypad 104 to provide functionality beyond the DTMF tone associated with each of these keys. For example, as explained below with respect to FIG. 5, the telephone device of the present invention can operate in an off-line mode. To put the phone in the off-line mode, a user presses a predetermined button sequence or macro sequence, for example, "***." When

"***" is pressed by the user, the associated button interrupt vector ensures that the "***" macro sequence is executed before the DTMF (Dual Tone Multi Frequency) tone associated with the "*" key is generated.

The telephone device of the present invention can be operated in an on-line mode as indicated in FIG. 4. In the on-line mode, the telephone device is off-hook, and a dial tone is delivered, as indicated in a step 402. In a step 404, on-line telephone call functions are performed such as dialing digits. The on-line mode is terminated by hanging up the phone as illustrated in a step 406.

The telephone device of the present invention can also be operated in an off-line mode. A flow diagram for placing the telephone device of the present invention in off-line mode is shown in FIG. 5. In a step 502, the telephone device is taken off-hook. The user then presses a predetermined button sequence for initiating the off-line mode, as indicated in a step 504. As noted above, this predetermined button or macro sequence for initiating off-line mode can be, for example, "***.^*' To ensure that a telephone call can still be received by the telephone device while in off-line mode, an on-hook status message is sent to the network or a cellular switch, as indicated in a step 506. In this manner, the cellular switch or server of the network thinks that the telephone device of the present invention is hung up or on-hook. In reality, the telephone device is off- hook during off-line mode, but the network thinks it is on-hook to ensure that telephone calls are still sent by the network to the telephone device during off-line mode.

The off-line mode allows a user to perform off-line functions, as indicated in a step 508. As explained more fully below, such functions can include, for example, calculator, recorder, facsimile, and answering machine functions. A further function, operated in on-line or off-line mode, includes a macro function that enables an invocable sequence of telephone buttons to be defined by the user. When the user is finished performing off-line functions, the user puts the phone on-hook, as indicated in a step 510. In a step 512, the telephone device resets for subsequent on-line telephone operation.

A flow diagram for receiving a call from a switch is illustrated in FIG. 6. FIG. 6 assumes an embodiment such that modem 119 shares transmitter 250 and receiver 260. When the switch has a call for the telephone device of the present invention, the switch determines whether or not the telephone device is on or off- hook, as indicated in a step 602. A decision is made in a step 604 whether the telephone device is off-hook. If the telephone device is off-hook, then busy signal processing is provided as indicated in a step 606 and the process stops in a step 608. If the telephone device is not off-hook, then the switch transmits the call through to the telephone device as indicated in a step 610. In a decision step 612, it is determined whether the telephone device is in an off-line mode. If the telephone device is in off-line mode, then the call is answered and a received call processing sequence is initiated, as indicated in a step 614. In a decision step 616, tone detector 222 determines whether a facsimile tone is present for the call. If a facsimile tone is detected, then a facsimile processing sequence is initiated by way of flow chart connector 5000. The facsimile processing sequence is illustrated in FIG. IOC. If a facsimile tone is not detected in the call, an answering device sequence is initiated by way of flow chart connector 3000. The answering device sequence is illustrated in FIG. 12. Note that in an embodiment of the telephone device wherein modem 119 operates on separate frequencies from that of receiver 260 and transmitter 250, i.e., modem 119 has its own receiver and transmitter, then decision step 616 would not be needed to separately detect a facsimile tone.

Referring back to decision step 612, if the telephone device is not in the off-line mode, then the ringer begins ringing as illustrated in a step 618. In a decision step 620, it is determined whether the user answers in a predetermined number N of rings. If the telephone call is not answered after the predetermined number of rings, received call processing sequence_, indicated by step 614 is initiated. If the user does answer the telephone call within the predetermined number of rings, when the user picks up, the user may hear a facsimile tone. If a facsimile tone is detected in a step 622, then the user presses a hot-key to initiate facsimile takeover, as indicated in a step 624. The user can then hang up, as shown in a step 626, and the facsimile processing sequence (FIG. 10C) is automatically executed. When the user hangs up in step 626, the call is not terminated. Background processing of the facsimile processing sequence continues. However, it is important that the user hot-key for facsimile takeover in step 624 before hanging the telephone up in step 626. If the user hangs up before hot-keying for facsimile takeover, then the call will be terminated before the facsimile is processed.

Returning to decision step 622, if the user does not detect a facsimile tone, then normal call processing of the telephone call continues, as indicated in a step

628. Such normal call processing is in the on-line mode illustrated in FIG. 4.

A flow diagram for monitoring the selection by a user of off-line functions is illustrated in FIG. 7, referred to herein as the main off-line monitoring loop. The off-line mode is initiated in a step 702. As noted in step 702, the off-line mode is terminated when the user hangs up the telephone device. In a step 704, an off-line mode variable is set. The off-line mode variable is a boolean variable, or a register that can be monitored. This variable indicates whether the telephone device is in the off-line mode. It is to be understood that all " VAR" variables shown in the flow diagrams are persistent variables that retain their current value until subsequently changed. As noted in step 704, the off-line mode variable can also be used to illuminate an indicator light on the telephone device to assist the user. In a step 706, the telephone device is waiting for user input or selection of the off-line function to be used. If the calculator functions are selected in a decision step 708, then processing continues to the calculator function sequence by way of flow chart connector 8000. The calculator function sequence is illustrated in FIG. 8A. If the user selects recorder functions as illustrated in a decision step 710, then processing continues to the recorder function sequence by way of flow chart connector 1000. The recorder function sequence is illustrated in FIG. 9A. If the user selects facsimile functions as illustrated in a decision step 712, then the facsimile function sequence is initiated by way of flow chart connector 2000. The facsimile function sequence is illustrated in FIG. 10A. If the user selects specifying the answering outgoing message function as illustrated in a decision step 714, then the outgoing message sequence is initiated by way of flow chart connector 6000. The outgoing message sequence is illustrated in FIG. 1 1. After performing the selected functions, or not recognizing a pre-defined key sequence, processing returns to step 706 of FIG. 7 by way of flow chart connector 4000 to wait for further user input. Processing is terminated when the user exits the off-line mode by hanging up the telephone device.

FIGS. 8A-8C illustrate flow diagrams used in the calculator function sequence. With reference to FIG. 8A, a flow diagram is illustrated for monitoring the duration of a key press. The duration of the key press is an element of a preferred embodiment of operation of the calculator function. The meaning of a particular key during the calculator function depends upon whether the key was pressed for a minimal press duration or a long press duration. The process of identifying the meaning of a key as a function of the duration of the key press is disclosed in co-pending application entitled "System and Method for Transmitting Data and Commands Using a Telephone," application number 08/672,186, filed on June 27, 1996 (Atty. Docket: RIC-96-009; 1575.0840000), the entirety of which is incorporated herein by reference. The foregoing application also includes a preferred embodiment of carrying out the calculator function of the present invention.

Arriving at a step 802 implies the telephone device has entered a calculator mode. In step 802, the variables used by the calculator function are initialized. The Work Area variable is analogous to the display area of a conventional calculator. The Binary Operator variable is a Boolean variable that indicates whether a binary operation is in progress. A Binary Operation always requires two terms, for example, add, subtract, multiply and divide. The Binary Operator variable is set to false in step 802. The Operator variable contains the most recent operator that has been entered by the user. In step 802, the Operator variable is set to the operation equal. The History List variable is used to allow the results of a calculation to be annotated or pronounced back to the user. This is also useful in providing calculation with confirmation to the user. In step 802, the History List is set to empty. In a step 804, the Memory Cell is initialized, i.e., the Memory Cell variable is set to 0. The Memory Cell provides a memory area that can be used to store the information or results contained in the Work Area. In the embodiment shown in FIG. 8A, only one Memory Cell is illustrated. However, it is to be understood that a plurality of Memory Cells could be used. In a step 806, the user is prompted with calculator instructions. Such prompting is done through speaker 106. An alternate embodiment may prompt through a display provided on handset 100. The user can hot-key out of the instructions to go immediately to a step 808.

In step 808, the telephone device waits for a telephone button pressed by the user. In a step 810, the start time of the button press is saved. Release of the button is waited for in a step 812. In a step 814, the wait time once the button is released is saved. In a step 816, the duration of the key press is calculated by subtracting end time from start time. In a step 818, an entry is placed into a queue. The entry includes both the button that was pressed (button identifier), along with the button press duration calculated in step 816. Processing then continues at wait step 808. FIG. 8B illustrates a flow diagram for a logical processing sequence associated with the calculator function. In a step 820, the next entry is retrieved from the queue identified in step 818. Access to the queue is preferably controlled by semaphore processing. Access may be blocked until there is something in the queue. This is identified in step 820 as an implicit wait. A preferred embodiment for carrying out step 820 is to retrieve the next queue entry, and match that queue entry to a translation table. The translation table maps the button identifier and button press duration (queue entries) to a defined semantic or interpreted message. The best match in the translation table for the queue entry is located. A default can be used if no match is found. The translation table is preferably maintained as a data table that includes four column entries for each row: (1) button pressed; (2) minimum duration; (3) maximum duration; and (4) interpreted message. The queue entry is processed in accordance with the interpreted message from the translation table, and the process returns to get the next queue entry. Table 1 below is one example of a translation table. The lengths of durations Dl, D2, and D3 are implementation dependent. Preferably, duration Dl is less than duration D2, which is less than duration D3. Accordingly, the semantics in Table 1 essentially have either a short duration (between Dl and D2) or a long duration (between D2 and D3). However, the present invention is designed to accommodate any number of semantics for any particular key, and any number of duration ranges. Preferably, semantics that translate to digits have short durations. Semantics that translate to commands (other than the Quit Command and the decimal point) have long durations.

<img file="WO9750222A1_D0001.tif" />

<img file="WO9750222A1_D0002.tif" />

Table 1

In a step 822, a New Number variable is set to false. The New Number variable is only true when there is a number in a Number Buffer that is ready for use, and needed in a calculation. A decision step 824 monitors whether the user wants to quit the calculator function. If the user elects to quit in decision step 824, the processing continues to step 706 of FIG. 7 by way of flow chart connector 4000. Calculator mode is exited upon return to step 706.

In a step 826, processor 112 interprets the current entry by reference to the translation table (see Table 1, above). In particular, processor 112 searches through the translation table until it finds a row that matches the current entry's key and duration. The current entry is then translated as defined by the semantic represented by the matching row.

In a step 827, processor 112 determines whether the interpreted (translated) current entry is equal to a digit or a period (decimal point). If the interpreted current entry is not equal to a digit or period, then a step 828 is performed (discussed below). Otherwise, a step 830 is performed.

In step 830, processor 112 appends the translated digit or decimal point into the Number Buffer. The Number Buffer is used to hold a number that is being formed by the user. In a step 832, processor 112 determines whether there are multiple decimal points in the Number Buffer. If there are not multiple decimal points in the Number Buffer, then control returns to step 820. Otherwise, a step 834 is performed. In step 834, processor 112 clears the Number Buffer.

In a step 836, an audible message is provided to the user, informing the user that the number being formed was in error (since it had more than one decimal point). In one embodiment, processor 112 further informs the user that the number being formed has been cleared, and that the user should re-enter the number. Control then returns to step 820.

If processor 112 determined in step 827 that the interpreted current entry was not equal to a digit or a decimal point, then step 828 is performed.

In step 828, processor 112 determines whether the interpreted current entry is equal to a calculator-related operator, such as a unary operator, a binary operator, a memory operator, clear, equals, equals with confirmation, etc. If the interpreted current entry is not an operator, then processor 112 assumes that the interpreted current entry is either equal to some other meaning defined in the translation table, or equal to a no-op. A no-op implies that a hit was not found in the translation table and the input is therefore ignored. In either case, processor 112 appropriately processes the command (step 829), and returns to step 820.

If processor 112 determines in step 828 that the interpreted current entry is equal to a calculator-related operator, then a step 838 is performed.

In step 838, processor 112 determines whether the user has previously begun entering a new number for use in a current calculation. Processor 112 performs step 838 by determining whether the Number Buffer is cleared. If the

Number Buffer is cleared, then the user has not begun entering a number, and step 846 is performed (discussed below). If the Number Buffer is not cleared, then the user has previously begun to enter a number, and step 840 is performed.

In step 840, processor 112 converts the number in the Number Buffer to a real number using well known techniques. Processor 112 sets an Input variable equal to this real number. This real number represents an operand to the current calculation, for example 978.32. Processor 112 then clears the Number Buffer.

In a step 842, processor 112 sets the New Number variable equal to true, indicating that the user has entered a number for use in the current calculation. Processing then continues at 8C, as illustrated in FIG. 8C. Upon completion of the processing shown in FIG. 8C, control passes to step 846.

Step 846 is also performed if, in step 838, processor 112 determined that the user had not previously begun entering a new number for use in the current calculation. In step 846, processor 112 sets the Input variable equal to the command or operator as determined by step 826.

Processing then continues at 8C, illustrated in FIG. 8C. Upon completion of the processing shown in FIG. 8C, control returns to step 820.

A flow diagram for processing numbers and operators entered by the user is illustrated in FIG. 8C. In a step 848, processor 112 determines whether the user has entered a new number for use in a current calculation by determining whether the New Number variable is equal to true. If the user has not entered a new number, then step 850 is performed (discussed below). Otherwise, a step 849 is performed.

In step 849, processor 112 appends one or more codes to the History List. These codes represent the real number stored in the Input variable. If these codes are sent to the speaker 106, then speaker 106 is caused to audibly annunciate this real number.

In a step 851, processor 112 determines whether the current calculation involves a pending binary operation. Processor 112 performs step 851 by determining whether the Binary Operator variable is equal to true. If the Binary

Operator variable is not equal to true, then processor 112 in a step 858 sets the Work Area variable equal to the real number in the Input variable, and sets the New Number variable equal to false. Control then returns to the flowchart shown in FIG. 8B. If processor 112 determines in step 851 that the Binary Operator variable is equal to true, then a step 853 is performed. In step 853, processor 112 performs the binary operation indicated by the Operator variable on the real number in the Work Area variable, and the real number in the Input variable. Processor 112 stores the result in the Work Area variable. In a step 856, processor 112 sets the

Binary Operator variable equal to false. Control then returns to the flowchart shown in FIG. 8B.

If, in step 848, processor 112 determined that the user had not previously entered a number for use in the current calculation, then a step 850 is performed. In step 850, processor 112 determines whether the following is true: (1 ) a binary operation is currently being performed (by reference to the Binary Operator variable); and (2) the most recent command entered by the user as stored in the Input variable is not a Retrieve From Memory operation. If these two conditions are true, then the user has improperly formed a calculation. This is the case when the user has requested a binary operation, but has provided only a single number for use in the binary operation.

Accordingly, if these two conditions are true, then processor 112 in a step 852 audibly conveys an error message to the user. Control then returns to the flowchart shown in FIG. 8B. If, in step 850, processor 112 determines that these two conditions are not both true, then a step 854 is performed.

In step 854, processor 112 determines whether the translated current entry

(as stored in the Input variable) is a binary operator command, such as the multiplication command. If the translated current entry is not a binary operator command, then a step 862 is performed (described below). Otherwise, a step 855 is performed.

In step 855, processor 112 sets the Operator variable equal to the value of the Input variable (that is, processor 112 sets the Operator variable equal to the binary operator command represented by the translated current entry). ln a step 857, processor 112 sets the Binary Operator variable equal to true.

In a step 860, processor 112 appends one or more codes to the History List. These codes represent the binary operation command stored in the Operator variable. If these codes are sent to speaker 106, then speaker 106 is caused to audibly annunciate this binary operation. For example, if the Operator variable stores the addition operator, then these codes when sent to speaker 106 causes speaker 106 to audibly annunciate the word "plus."

Control then returns to the flowchart shown in FIG. 8B. If, in step 854, processor 112 determined that the translated current entry is not a binary operator command, then step 862 is performed. In step 862, processor 112 determines whether the translated current entry (as stored in the Input variable) is a unary operator, such as the 1/x command. If the translated current entry is not a unary operator, then a step 872 is performed (described below). Otherwise, a step 864 is performed.

In step 864, processor 112 performs error checking. The actual error checking performed by processor 112 is implementation dependent, and depends on the unary operations that are supported by processor 112. In the embodiment being described, processor 112 in step 864 determines whether the following conditions are true: (1 ) the Work Area variable stores zero; and (2) the translated current entry is the 1/x unary command. If both these conditions are true, then processor 112 in a step 866 audibly conveys a divide-by-zero error message to the user. Control then returns to the flowchart shown in FIG. 8B.

If both these conditions are determined in step 864 to not be true, then a step 868 is performed. In step 868, processor 112 applies the unary operator indicated by the translated current entry to the real number stored in the Work Area variable. Processor 112 stores die result in the Work Area variable.

In a step 870, processor 112 appends one or more codes to the History

List. These codes represent the unary operation command represented by the translated current entry. If these codes are sent to speaker 106, then speaker 106 is caused to audibly annunciate this unary operation. Control then returns to the flowchart shown in FIG. 8B.

If, in step 862, processor 112 determined that the translated current entry is not a unary operator, then a step 872 is performed. In step 872, processor 112 determines whether the translated current entry (as stored in the Input variable) is equal to the equals command. If the translated current entry is not equal to the equals command, then a step 876 is performed (described below). Otherwise, a step 874 is performed.

In step 874, processor 112 commands speaker 106 to audibly annunciate (i.e., annotate) to the user the contents of the Work Area variable. Processor 112 performs step 874 by transmitting to speaker 106 one or more codes that represent the real number stored in the Work Area variable. Control then returns to the flowchart shown in FIG. 8B.

If, in step 872, processor 112 determined that the translated current entry was not equal to the equals command, then step 876 is performed. In step 876, processor 112 determines whether the translated current entry (as stored in the Input variable) is equal to the equals with confirmation command. If the translated current entry is not equal to the equals with confirmation command, then a step 880 is performed (described below). Otherwise, a step 878 is performed.

In step 878, processor 112 commands speaker 106 to audibly annunciate the status of the current calculation. Processor 112 performs step 878 by transferring the contents of the History List to speaker 106 to audibly annunciate the word "equals" by transferring appropriate code(s) to speaker 106. Then a step 874 is performed, wherein speaker 106 is commanded to audibly annunciate the contents of the Work Area variable (described above). Control then returns to the flowchart shown in FIG. 8B.

If, in step 876, processor 112 determined that the translated current entry (as stored in the Input variable) is not equal to the equals with confirmation command, then step 880 is performed. In step 880, processor 112 determines whether the translated current entry (as stored in the Input variable) is equal to the set memory cell command. If the translated current entry is not equal to the set memory cell command, then a step 884 is performed (described below). Otherwise, a step 882 is performed. In step 882, processor 112 sets the Memory Cell equal to the value of the

Work Area variable. Control then returns to the flowchart shown in FIG. 8B.

If, in step 880, processor 112 determined that the translated current entry (as stored in the Input variable) is not equal to the set memory cell command, then step 884 is performed. In step 884, processor 112 determines whether the translated current entry (as stored in the Input variable) is equal to the retrieve memory cell command. If the translated current entry is not equal to the retrieve memory cell command, then a step 895 is performed. Otherwise, a step 886 is performed.

In step 886, processor 112 appends to the History List one or more codes representing the real number stored in the Memory Cell. These codes, if sent to

Speaker 106, cause speaker 106 to audibly annunciate this real number.

In a step 888, processor 112 determines whether the current calculation involves a binary operation. Processor 112 performs step 888 by determining whether the Binary Operator variable is equal to true. If the Binary Operator variable is not equal to true, then processor 112 in a step 894 sets the Work Area variable equal to the real number in the Memory Cell. Control then returns to the flowchart shown in FIG. 8B.

If processor 112 determines in step 888 that the Binary Operator variable is equal to true, then a step 890 is performed. In step 890, processor 112 performs the binary operation indicated by the Operator variable on the real number in the

Work Area variable and the real number in the Memory Cell. Processor 112 stores the result in the Work Area variable. In a step 892, processor 112 sets the Binary Operator variable equal to false. Control then returns to the flowchart shown in FIG. 8B. If, in step 884, processor 112 determined that the translated current entry is not equal to the retrieve memory cell operation, then step 895 is performed. In step 895, processor 112 determines whether the translated current entry (as stored in the Input variable) is equal to the clear work command. If the translated current entry is not equal to the clear work command, then control returns to the flowchart shown in FIG. 8B. Otherwise, processor 112 sets the Work Area variable to zero, sets the Binary Operator variable to false, sets the Operator variable to the equals command, empties the History List, and clears the Number Buffer, as shown in a step 897. In a step 899, processor 112 provides a ready greeting. Control then returns to the flowchart shown in FIG. 8B.

In a particularly preferred embodiment, the duration of a key press is used to identify the particular calculator function to be performed. Alternatively, multiple buttons may be used to indicate a particular function. For example, an asterisk or star followed by a digit may imply the add or addition binary operator.

Sequences of prefix buttons can map to a particular function or definition so that the telephone device of the present invention can be enabled with many types of calculator operations.

FIG. 9A illustrates a flow diagram for the recorder function sequence. In a step 902, the user is prompted with the recorder functions. Upon encounter of step 902, the telephone device has entered a recorder mode. Such prompting can be done by playing the prompt through speaker 106. Alternatively, such prompting could be done by displaying the instructions or menu on a display provided on handset 100. In a step 904, the telephone device waits for user input. If the user elects to turn the record mode on, as indicated in a decision step 906, then processing continues at a decision step 908. In decision step 908, it is determined whether a record variable has already been set to on. If the record variable has already been set to on, processing returns to wait step 904. If the record variable has not been set to on, then the record variable is set to on in a step 910. In a step 912, recorder usage is secured. In a preferred embodiment, recorder usage is secured through the use of semaphore processing. Such a semaphore gives exclusive rights to use the recorder to one process or function at a time. The semaphore blocks access to the recorder by the other processes or functions until the process using the device has completed. Once the semaphore has granted access to the recorder, thereby securing recorder usage, the recorder is started in a step 914. Once the recorder is started, processing returns to wait step 904. The foregoing sequence provides for making a recording while the telephone device is in the off-line mode or in the on-line mode. As noted above in Section 2, the recorder can be turned on in the on-line mode while a telephone call is in progress. In the preferred embodiment of the present invention, a recording can be made while in the on-line mode or in the off-line mode. A hot¬ key is provided to allow the user to initiate recording while in the on-line mode during a telephone call, or in the off-line mode. If the user selects turning the record mode off in a decision step 916, then processing continues at a decision step 918. In decision step 918, it is determined whether the record variable is on. If the record variable is not on, i.e., it is off, then processing returns to wait step 904. Since the record variable is not on, this indicates that the record mode is already off. Returning to decision step 918, if the record variable is on, then the record variable is turned off in a step 920. The recorder is stopped in a step 922. A date/time register is accessed in a step 924. Date and time information is provided to the date/time register by clock 220.

In a step 926, a four field record is inserted into an index table that corresponds to the new recording that has just been made. An exemplary index table is illustrated in Table 2 below. <img file="WO9750222A1_D0003.tif" />

Table 2

The first field is an index number or reference enumeration value. As explained more fully below, the index number assigned to the outgoing message (OGM) for the answering device is always one. All other recordings are assigned an index number of two through N. The second field in the index table record is a data type. The data type can either be facsimile or recording. The recording data type is assigned to any type of recording that is made, for example, a recording made by the user of the telephone device while in the off-line mode, or a recording of a telephone conversation that is recorded while the telephone device is in the on-line mode. A recording data type is also assigned to a message that is recorded in response to the answering machine outgoing message. A facsimile data type is assigned to a facsimile message that is received by the telephone device of the present invention. The third field is a date and time identifier that identifies the date and time at which the recording was created, or the date and time at which the facsimile was received. The fourth field is a fully qualified and unique path name for the location at which the recording or facsimile is stored. The recordings and facsimile messages are stored on DASD 118 under unique file names. The record in the index table provides a map or identifier to locate a particular recording or facsimile message. Step 926 provides an interface to recorder operation which is shown in FIG. 9B. Once the record corresponding to the new recording is inserted into the index table in step 926, recorder usage is released in a step 928. In the preferred embodiment, the release of recorder usage is controlled by semaphore processing. Processing then continues at wait step 904. In a manner similar to that for returning the recorder on, the user can turn the recorder off at any time by executing a hot-key. Record mode on and record mode off are available to access in both on-line mode and off-line mode via a hot¬ key. This allows the user of the telephone device of the present invention to access the recorder at any time. The recorder functions which appear below decision step 930 in FIG. 9A are only available to the user in off-line mode, and during periods where recording is not active. Therefore, decision step 930 ensures that the record variable is not on, i.e., is off, when processing continues below decision step 930. In decision step 930, if the record variable is still on, then processing returns to wait step 904. If the record variable is not on, i.e., the record variable is off and the recorder is off, then processing continues at decision step 932. The telephone device cannot be in record mode to operate the functions identified below decision step 930.

Decision step 932 allows a user to delete an index table entry or index table record. In a step 934, the user is prompted to enter the index number of the record or entry to be deleted from the index table. In a step 936, it is determined whether the index number entered by the user is valid. To be valid, the index number must not be number one, and it must exist. If the index number entered by the user is not valid, then an error tone is provided in a step 938 and processing returns to wait step 904. If the index number is valid as determined in step 936, then the file corresponding to the index table entry (index number) is deleted in a step 940. The file deleted in step 940 is the file that contains the data itself for the recording or facsimile that corresponds to the index number entered by the user. The corresponding record in the index table is deleted from the index table in a step 942. The index table entries or records are then re- enumerated for index numbers ranging from two to N in a step 944. The outgoing message for the answering device function is assigned an index number equal to one and therefore is not affected by the re-enumeration of step 944. A successful completion tone is provided to the user in a step 946 to indicate that the index table entry selected by the user has been successfully deleted.

Processing then returns to wait step 904.

A user can also browse the information that has been stored in the index table, as indicated in a decision step 948. To browse the index table, the next index table entry starting with one is retrieved in a step 950. If all index table entries have been processed, as indicated in a decision step 952, then a successful completion tone is provided to the user in a step 954. Processing then continues at wait step 904.

Returning to decision step 952, if all index table entries have not been processed, then the next index table entry that has been retrieved in step 950 is annotated in a step 956. The index number, data type, and date and time identifier included in the record retrieved from the index table are annotated for the user. Such annotation can be accomplished by pronouncing the index number, data type, and date and time identifier to the user through speaker 106. Alternatively, such annotation can be accomplished by displaying the index number, data type, and date and time identifier on a display included in handset

100. An index table entry having a facsimile data type cannot be played back to the user through speaker 106. Therefore, in a decision step 958, it must be determined whether the data type of the retrieved record is facsimile. If the data type is not facsimile, then processing continues at a step 964. In step 964, the recording file is played for the user through speaker 106.

Thereafter, a decision step 966 is used to allow a user to hot-key out of playing the entire recording file. Decision step 966 is used to monitor whether the user has entered a key to hot-key out of playing the recording file, for example, the pound key (#). If the user has selected the pound key, then processing will return from decision step 966 to step 950 to get the next index table entry. If in decision step 966 the user did not opt to terminate play in step 964, then decision step 960 is used to monitor whether the user wants to exit or quit the browse function. The user can do so by hot-keying out of the browse function at any time by selecting a predetermined key, such as the asterisk (*) or star key. If the user has hit the star key, then in decision step 960 processing will return to step 904. If the user has not hot-keyed out of the browse function, then in a decision step 962, it is determined whether the data type currently processed is facsimile. If the data type is not facsimile, then processing returns to step 964 to continue playing the recording file. Steps 966 and 960 are decisions based on monitoring which occurs in step 964.

In decision step 962, if the data type is facsimile, then processing returns to step 950 to get the next index table entry. Referring back to step 958, if the data type is facsimile, processing continues to step 960.

A decision step 968 allows a user to play a recording that corresponds to an index number selected by the user. In a step 970, the user is prompted to enter an index number that corresponds to the recording that the user wishes to be played. In a step 972, it is determined whether or not the index number entered by the user is valid. For example, to be a valid index number to play a recording, the index number must exist and must not correspond to a facsimile data type. If the index number is not valid, e.g., corresponds to a facsimile message, then an error tone is provided to the user in a step 974. Processing then continues at wait step 904.

Returning to decision step 972, if the index number entered by the user is valid, then the file corresponding to this index number is played for the user in a step 976. To carry out step 976, the digitized file corresponding to the recording is retrieved, converted to an analog signal by D/A converter 244, and the analog signal is played out through speaker 106 to be heard by the user. A decision step 978 is used to monitor whether the user wants to hot-key out of playing the entire recording. If the user enters the hot-key (pound key), or playing of the recording is complete, then processing returns to wait step 904. Otherwise, playing of the recording continues until the user either hot-keys out or playing of the recording is complete.

A decision step 980 allows a user to select a restate options function. If the restate options function is selected in decision step 980, then processing continues at step 902 to prompt the user with recorder functions. If the user elects to quit or exit from recorder functions in a step 982, then processing continues back to step 706 in FIG. 7 by way of low chart connector 4000.

FIG. 9B illustrates a flow diagram for implementing step 914 to start the recorder. In a step 990, a unique file name is generated on one or more of the storage or memory devices of the telephone device. The steps for generating a unique file name on a storage device would be readily apparent to one of skill in the relevant art and have been omitted for brevity. In a step 992, the sound to be recorded is saved as samples to a digitized file. In a preferred embodiment, the recorder operates at a configurable sampling rate. The sampling rate determines the number of samples per second that are taken. The more samples that are taken per second increases the quality of the recording. The sampling rate can be made configurable by storing the sampling rate in a register accessible by the computer program logic.

In a step 994, the recording samples are stored in the file having the unique file name generated in step 990. In operation, steps 992 and 994 occur simultaneously.

To stop the recorder, the recorder is interrupted (for example, maximum record time elapsed) and input/output is completed, as indicated in a step 996. FIG. 10A illustrates a flow diagram for the facsimile function sequence. In a step 1002, the user is prompted with the facsimile functions. Such prompting can be done by playing the prompt through speaker 106. Alternatively, such prompting could be done by displaying the instructions or menu on a display provided on handset 100. In a step 1004, the telephone device waits for user input. If the user selects to set up a page header, as indicated in a decision step 1006, then processing continues at a step 1008. In step 1008, the user specifies a fixed-length header upon prompting with the current header setting. For example, to enter this heading, pressing a number followed by the pound (#) key will indicate a numeric character. Pressing the star (*) key followed by a pound key will indicate a blank. In order to identify alphabetic characters, one preferred embodiment would use the following scenario. The first entry would indicate the key, and the second entry would indicate the letter on the particular key that was to be used. For example, the sequence "21 " would indicate an "a" (key 2, first letter), the sequence "22" would indicate a "B" (key 2, second letter), and the sequence "23" would indicate a "C" (key 2, third letter). A "Z" would be indicated by "01. " Key sequence " * * " would indicate the end of the input, and "##" would keep the current setting. In a step 1010, a static header variable is set to the string just entered. A static variable is a persistent variable that keeps its value until modified again. Processing then continues at wait step 1004. In a decision step 1012, the user can elect to set up a "TO" field. The user specifies a fixed length "TO" field upon prompting with the current "TO" field setting. The same type of key sequence would be used to identify the string for the "TO" field as was described above for the fixed-length header in step 1008. In a step 1016, a static "TO" variable is set for the string that is entered. Processing then continues at wait step 1004.

Similarly, the user can elect to set up a "FROM" field, as indicated in a decision step 1018. The user specifies a fixed-length "FROM" field upon prompting with the current "FROM" field setting. The same type of key processing is used as was described above for steps 1014 and 1008. In a step 1022, a static "FROM" variable is set to the string that has been entered.

Processing then continues at wait step 1004.

The matter or information to be sent can be specified by the user, as indicated in a decision step 1024. If the user elects to specify the matter to be sent in decision step 1024, the user specifies an index number upon prompting with the current setting of the matter to be sent in a step 1026. The index number must be a valid entry in the index table. In a decision step 1028, it is determined whether the index number entered by the user is valid. For example, an index number is valid if it exists. If the index number is not valid as determined in decision step 1028, then an error tone is provided to the user in a step 1030. Processing then continues at wait step 1004.

Returning to decision step 1028, if the index number entered by the user is valid, a static index variable is set to the entered index number in a step 1032. Processing then continues at wait step 1004. In a decision step 1034, the user can elect to specify a target telephone number to which the facsimile is to be sent. If the user elects to specify the target telephone number in step 1034, then the user enters the digits of the target telephone number in a step 1036. Preferably, in step 1036, the user is prompted with the current setting of the target telephone number. In a step 1038, a static target variable is set to the telephone number entered by the user in step 1036. Processing then continues at wait step 1004. In a decision step 1040, the user can elect to actually send the facsimile.

If the user elects to send the facsimile in decision step 1040, processing continues at a decision step 1042. In decision step 1042, it is determined whether a target number has been specified by the user. If a target number has not been specified by the user, then an error tone is provided to the user in step 1030. Processing then continues at wait step 1004.

Returning to decision step 1042, if the target number has been specified by the user, then the header will be formatted for the start of every page in a step 1044. The static header variable from step 1010 is used. In a step 1046, the telephone device of the present invention will actually make the call. In a decision step 1048, it is determined whether the call made in step 1046 has been completed to a facsimile tone. If the call has completed to a facsimile tone, then the formatted first page will be transmitted as indicated in a step 1050. Step 1050 transmits the title information page using the TO variable, the FROM variable, and the target variable established in steps 1016, 1022, and 1038, respectively. In a decision step 1052, it is determined whether the index variable that corresponds to the index number of an entry in the index table entered by the user references a facsimile. If the index variable does point to a facsimile, then the stored facsimile will be transmitted in a step 1054 and the connection will be terminated. A successful completion tone will then be provided to the user in a step 1062. Processing continues at step 706 in FIG. 7 by way of flow chart connector 4000.

If the index variable entered by the user points to a facsimile, as indicated in decision step 1052, then a stored facsimile is transmitted in step 1054. Thus, the telephone devise of the present invention can be used to forward a facsimile previously received.

Returning to decision step 1052, if the index variable does not point to a facsimile, then processing continues at the translator and formatter sequence shown in FIG. 10B by way of flow chart connector 7000. At the conclusion of the translator and formatter sequence, a successful completion tone is provided to the user in step 1062 and processing continues at step 706 in FIG. 7 by way of flow chart connector 4000.

The translator and formatter sequence is illustrated in FIG. 10B. In a step 1070, the translator thread and the formatter thread are spawned. This results in a parallel sequence of processing. In a step 1072, a digital recording is converted to textual words, and the words are placed into a transmit queue in first-in-first- out (FIFO) order. In a decision step 1074, it is determined whether conversion of the complete recording has been done. Steps 1072 and 1074 occur in conjunction with each other. If complete conversion of the recording has not been done, then processing returns to step 1072. If conversion of the recording is complete, then the translator thread is terminated in a step 1076 and the translator thread stops.

The conversion from speech to text can be carried out in the following manner. The analog signal has already been converted to a digital signal by analog-to-digital converter 242. The digitized information is already stored either in RAM 218 or DASD 118. Computer program logic or software converts the stored digital information to text strings (step 1072). Computer program logic or software for converting the digitized information into the text string is commercially available. Such software includes "DragonDictate" offered by Dragon Systems, Inc. Another commercially available speech-to-text conversion package is "Voice Type Dictation System" offered by IBM. Alternatively, the speech-to-text conversion could be carried out using a single chip that includes the appropriate software contained on the chip itself.

The formatter thread is operating in parallel with the translator thread. In a step 1078 of the formatter thread, the next line of words is retrieved from the transmit queue. As indicated in step 1078, the formatter thread may retrieve words from the queue as they become available, but waits until an entire line of words is available. Processing leaves step 1078 for either a completed line, or no other words are in the queue and the translator thread has already completed. In a decision step 1080, it is determined whether the translator thread has terminated, and whether there are no more words in the transmit queue.

In decision step 1080, if the translator thread has not terminated, or there are more words in the transmit queue, then processing continues at a decision step 1086. In decision step 1086, it is determined whether the current formatted page has been completed. Decision step 1086 determines whether the number of lines that are needed to go on a particular facsimile page are ready. If the page is complete, then the page is transmitted in a step 1088. The next page is then prepared for in a step 1090, and processing returns to the beginning of the formatter thread at step 1078. As lines are gathered according to a page width, they are converted to scan lines for transmission. In decision step 1080, if the translator thread has terminated, and there are no more words in the transmit queue, then the last formatted page of the facsimile is transmitted and the connection is terminated in a step 1082. The formatter thread is then terminated in a step 1084 and processing returns to step 1062 of FIG. 10A. The translator and formatter threads provide two independent and simultaneous threads of processing. This ensures that the transmission of a facsimile message by the telephone device of the present invention is not hung up or slowed down by the conversion process. Conversion of the recording into textual words and the transmission of the facsimile message are occurring simultaneously. In one embodiment of the present invention, the textual words of the facsimile message are played over speaker 106 to help identify any conversion errors while the facsimile message is being transmitted. Preferably, the textual words of the facsimile message are not played over speaker 106. Referring back to FIG. 1 OA, in a decision step 1058, the user can elect to restate options. If the user elects to restate options, then processing continues at step 1002 to prompt the user with facsimile functions. If the user elects to quit the facsimile functions in a decision step 1060, then processing continues at step 706 in FIG. 7 by way of flow chart connector 4000. Otherwise, processing continues at step 1004 to wait for user input.

FIG. 10C illustrates a flow diagram for the facsimile processing sequence. In a step 1092, a unique file name is generated on one or more of the storage or memory devices of the telephone device. The steps for generating a unique file name on a storage device would be readily apparent to one of skill in the relevant art and have been omitted for brevity. In a step 1094, the digitized facsimile message is received, such as through modem 119, and stored under the unique file name generated in step 1092. In a step 1096, the four-field record is inserted into the index table to identify the recorded facsimile message. In a manner similar to recordings, the first field is an index number of two through N. The second field is a data type of facsimile. The third field is the date and time at which the facsimile was received. The fourth field is the unique file (and path) name for the stored facsimile message. In a step 1098, the connection is terminated.

The outgoing message (OGM) sequence is illustrated in FIG. 1 1. In a decision step 1102, it is determined whether or not the recorder is currently in use. If the recorder is in use, then a device unavailable message is provided to the user in a step 1104. The device unavailable message informs the user that the device (recorder) required to perform a selected function is not currently available to perform that function. In one embodiment, the device unavailable message is provided as a preprogrammed message in the telephone device. In an alternative embodiment, the user can record a personalized device unavailable message that is referenced through the index table. Processing then continues at step 706 in FIG. 7 by way of flow chart connector 4000. If the recorder is currently in use, then the user cannot at this time record or specify the outgoing message.

Returning to decision step 1102, if the recorder is not currently in use, then the usage of the recorder is secured in a step 1106. Preferably, the recorder is secured using the recorder semaphore processing discussed above. In a step 1108, the user is prompted to provide the outgoing message. In a preferred embodiment, such prompting will include playing of the existing outgoing message if there is one. After the prompt, the recorder will be started for a predetermined time of N seconds in a step 1110. Step 1110 will execute the start recorder sequence illustrated in FIG. 9B. As such, a unique file name will be generated for the outgoing message. Index number one is reserved for the outgoing message. In a step 1112, the outgoing message that has been recorded will be entered into the index table using an index number of one. In a step 1114, the recorder is freed or released using the recorder semaphore processing.

Processing then continues at step 706 in FIG. 7 by way of flow chart connector 4000.

The answering device sequence is illustrated in FIG. 12. In a decision step 1202, it is determined whether or not the recorder is currently in use. If the recorder is in use, then a device unavailable message such as that described above is provided to the caller in a step 1204. The telephone call is then terminated in a step 1206. This stops the answering device sequence. If the recorder is currently in use, such as by the user in the off-line mode, then the recorder cannot be simultaneously used to record an incoming message. Returning to decision step 1202, if the recorder is not currently in use, then the usage of the recorder is secured in a step 1208. Preferably, the recorder is secured using the recorder semaphore processing discussed above. In a step 1210, the outgoing message, referenced by the index table entry index number one, is played to the person on the other end of the telephone call. In a step 1212, a prompt tone, such as a "beep", is provided. The recorder is started for a predetermined time of N seconds in a step 1214. Step 1214 will execute the start recorder sequence illustrated in FIG. 9B. As such, a unique file name will be generated for the incoming message. An index table entry or record will be inserted into the index table for the incoming message in a step 1216. In a step

1218, the call is terminated. Finally, in a step 1220, the recorder is freed or released using the recorder semaphore processing. The answering device sequence will then terminate.

The telephone device of the present invention includes a macro function that enables an invocable sequence of telephone buttons to be defined. The macro functionality is available in on-line or off-line mode, and operates independently of any other processing. FIGS. 13A-13F show flow diagrams for configuring the telephone device to store and execute user-defined sequences of keystrokes or macros. The macros of the present invention can be referenced through button assignments or voice command assignments. Voice command assignments are converted to the equivalent strings when used in the present invention. The macro function of the present invention relieves a user from interfacing with an automated telephone service when the service menus and sequence of keystrokes are well known by the user. For example, the macros of the present invention allow a user to traverse menus in order to sample music, place orders, or inquire as to stock trades. Likewise, telephone mail or automatic response units provide menus from which a user navigates by pressing telephone buttons for options and selections. Customized macros can be defined for those voice-mail systems routinely accessed by the user. A particularly preferred method of implementing macros using a telephone device is contained in copending application entitled Automated Telephone Service Interface, application number 08/721,408, filed September 26, 1996 (Atty. Docket: RIC-96-008A; 1575.0930001), which is a continuation-in-part of application number 08/673,813, filed June 27, 1996 (now provisional application number 60/031 ,100), the entirety of both of the foregoing applications is incorporated herein by reference.

In accordance with the present invention, a local library of macros is maintained on one or more of the storage or memory devices of the telephone device. This local library is maintained, for example, as a macro table of entries that includes the following fields: MACRO; INVOKE-TYPE; INVOCATION; and VOICE-RECORDING. An exemplary macro table is illustrated in Table 3 below.

<img file="WO9750222A1_D0004.tif" />

Table 3

The MACRO field is an ordered list of three field records. The first field record in the MACRO field is a button type. The button type can be immediate or wait. For a button type of immediate, the DTMF tones corresponding to the telephone buttons in the macro sequence are issued immediately, one after the other when playing the macro. For a button type of wait, the DTMF tones corresponding to the telephone buttons are issued with a predetermined time delay between DTMF tones, once the signal level at the source (other end of the telephone call) indicates it is ready for the next key. This process is described in more detail below with respect to FIG. 13B. The selection of immediate button type or wait button type is preferably done through the duration of the key press of a predetermined key. The process of identifying the meaning of a key as a function of the duration of the key press is disclosed in copending application entitled "System and Method for Transmitting Data and Commands Using a Telephone," application number 08/672,186, filed on June 27, 1996 (Atty. Docket: RIC-96-009; 1575.0840000) referred to above. The second field record in the MACRO field is the button itself. The third field record in the MACRO field is the time since press of the previous entry.

The INVOKE-TYPE field determines whether the macro will be invoked by a voice command or a button command. The INVOCATION field indicates the actual button used to invoke the macro if it has an invoke type of button. The

INVOCATION field could also be a text string that corresponds to the voice command used to invoke the macro. The final field is a voice recorded description of the macro itself.

FIG. 13A illustrates the primary flow diagram used to configure the telephone device of the present invention to store and execute user-defined sequences of keystrokes or macros. The macros of the present invention can be used to access a service or to traverse menus, such as in an automatic response unit. The process starts in a step 1302. In a step 1304, the dial tone is delivered to the telephone device of the present invention. In a step 1306, a macro record mode variable is set to off indicating that no macro is currently being recorded.

In a step 1308, a button press by the user is monitored. In a decision step 1310, it is determined whether any monitored button has been pressed by the user. If a monitored button has been pressed by the user, then processing continues to a decision step 1312. In decision step 1312, it is determined whether the macro record mode variable is set to on, thereby determining whether a macro is currently being recorded. If a macro is currently being recorded, as determined in decision step 1312, then processing continues at a step 1314. In step 1314, the button pressed by the user is appropriately saved to a record buffer. The record buffer (also called a macro buffer) stores MACRO records in the MACRO field shown above in Table 3. It is here, in step 1314, that the button type, immediate or wait, is determined. The duration of the key press is passed from step 1308 to step 1314. Processing then continues at a decision step 1316. Returning to decision step 1312, if a macro is not currently being recorded, then processing also continues at decision step 1316. Returning to decision step 1310, if a monitored button was not pressed (e.g., telephone connection terminated by hanging up), then step 1310 also continues at step 1316. Thus, step 1308 flows to step 1310 for buttons pressed and telephone on-hook status. Step 1314 traps telephone device user activity to a macro for subsequent use ("macro recording"). Steps 1316, 1320, 1346, 1356, 1358, 1360, 1362, and 1364 determine the meaning of user input. In the preferred embodiment, a command sequence is identified by a command prefix followed by a unique button, for example, the asterisk button '*' followed by the one button ' 1 ' indicates the command to turn the record mode on. Thus, the asterisk '*' can be a command prefix for identifying all commands (*1, *2, *3, etc.). A prefix may also be formed by multiple buttons to prevent interfering with menus. One embodiment may define special command buttons on an extended keypad for commands. Yet another embodiment may use button press durations to distinguish between commands.

In the preferred embodiment of a button command prefix (e.g., *), the prefix is queued up for recognition of commands at steps 1316, 1320, 1346, 1356, 1358, and 1360. Obvious queuing of a prefix is assumed in FIG. 7A so focus remains on primary processing.

In decision step 1316, it is determined whether the user has selected to record a macro. In decision step 1316, it is also determined whether or not the macro record mode is active. If the user has selected to record a macro, and the telephone device is not currently in the macro record mode, then the macro record mode is turned on in a step 1318 by setting the record mode variable to ON. Processing then returns to button press monitoring step 1308. Note that trapping only occurs if the macro record mode variable is set to ON.

Returning to decision step 1316, if the user has not selected to record a macro, then in a decision step 1320 it is determined whether the user has selected to save a macro. In decision step 1320, it is also determined whether or not the macro record mode is active, thereby denoting that a macro was in the process of being saved. It should be noted that in decision steps 1346, 1356, 1358, and 1360, it is insured that for each selected function, the telephone device is not in the macro record mode. In the preferred embodiment, the functions indicated by steps 1346, 1356, 1358, and 1360 cannot be performed if the telephone device is in the macro record mode. In an alternate embodiment, the telephone device of the present invention would provide an error tone if the user had selected one of the foregoing functions while the telephone device was in the macro record mode. Returning to decision step 1320, if it is determined that the user selected to save the macro, then macro record mode is turned off in a step 1322. The record buffer, referred to in step 1314 above, now contains the particular telephone buttons of the macro sequence, as well as the telephone buttons corresponding to the save command sequence. In a step 1324, the save command sequence information is removed from the record buffer. This insures that the save command sequence does not get saved as part of the macro itself. In a step 1326, the user is prompted with a tone to indicate that the invocation must be set. In a step 1328, the user enters the particular invocation to be used. The invocation can be a button, or buttons, to invoke the macro. Alternatively, the invocation can be a special button or button sequence that indicates use of a voice command. If a voice command is used as the invocation, then delimiters are used to turn the recorder on and off during recording of the voice invocation. In a decision step 1330, it is determined whether the invocation type will be by voice (e.g., user entered '#'). If the invocation is not by voice (e.g., user entered '5'), then processing continues at a step 1332 where the user is prompted for a description of the macro. In a step 1334, the user specifies a description of the macro. In a step 1336, the entry is then saved to one or more of the storage or memory devices of the telephone device, i.e., in a local macro library. In a step 1338, the record buffer is cleared, and processing continues at button press monitoring step 1308. Step 1336 will overwrite a local library entry if the invocation type and reference matches an existing entry. Therefore, the macro referenced by the voiced string "health benefits" refers to only one macro. Likewise, the macro referenced by the command sequence *35 refers to only one macro referenced by the button 5 (*3 is command sequence for invocation by button(s)).

Returning to decision step 1330, if the invocation type is by voice, then the invocation voice is converted to a text string in a step 1340. The conversion from voice to text string can be carried out in a manner similar to that discussed above with respect to converting speech to text in FIG. 10B. Step 1340 allows user specified delimiters to turn voice record on and off. In a decision step 1342, it is determined whether the text string is empty, or is a null string (i.e., nothing recorded). If the text string is a null string, then an error tone is provided to the user in a step 1344. Processing then continues at button press monitoring step 1308. Returning to decision step 1342, if the text string is not a null string (i.e., something was recorded), then processing continues at step 1332, described above. The sequence of steps selected by decision step 1320 as described above allows a macro to be saved for future reference by a convenient recall method, command sequence, or voice command.

If, in step 1320, it is determined that the user did not elect to save a macro, then a decision step 1346 is performed. In decision step 1346, the user can select to invoke a macro. In decision step 1346, it is determined if the user selected to invoke a macro by buttons. If invoking a macro by buttons was selected, then in a step 1348, the local library of button invocable macros that are stored on the storage or memory devices of the telephone device are accessed by the specified command sequence buttons. In a decision step 1350, it is determined whether the macro selected by the user is found. If the macro is found, then in a step 1354 a macro variable is set to the macro field in the entry found. Processing then continues to FIG. 13B, described below, by way of flowchart connector 13B. Returning to decision step 1350, if the selected macro is not found in the local library, then an error tone is provided to the user in a step 1352. Processing then returns to button press monitoring step 1308.

Returning to step 1346, if the user did not elect to invoke a macro, then a step 1356 is performed. It is determined in decision step 1356 whether the user selected to invoke a macro by voice. If the user selects this option, then processing continues to FIG. 13C, described below, by way of flowchart connector 13C. If in step 1356 the user did not invoke a macro by voice, then a step 1358 is performed. It is determined in decision step 1358 whether the user selected a browse macro function. If the user selected the browse macro function, processing continues to FIG. 13D, described below, by way of flowchart connector 13D. If the user in step 1358 did not elect the browse macro function, then a step 1360 is performed. It is determined in decision step 1360 whether the user selected to delete a macro. If the macro delete function was selected by the user, processing continues to FIG. 13E, described below, by way of flowchart connector 13E. Otherwise, step 1360 proceeds to a step 1362.

As discussed previously, the processes accessed by decision steps 1316, 1320, 1346, 1356, 1358, and 1360 (identified as X in FIG. 13 A) are used to capture telephone buttons that are entered subsequent to a predetermined command prefix. If a button other than a command prefix is entered as determined by step 1362 (also shown as Y in FIG. 13A), then processing continues to FIG. 13F, described below, by way of flowchart connector 13F. Otherwise, step 1362 proceeds to a step 1364. Note that a command sequence would prevent encounter of step 1362. Finally, it is determined in decision step 1364 whether the call is terminated. If the call was terminated (e.g., phone hung up) by the user, then in a step 1366, the call is terminated, as is the macro function sequence. For example, hanging up in the middle of recording a macro will flush the record buffer and quit processing. If the phone has not been hung up by the user, then processing continues from step 1364 to monitor for a button press by the user in step 1308.

A flow diagram for executing a macro is illustrated in FIG. 13B. In a step 1368, the next button record is retrieved from the macro variable. First encounter of step 1368, from step 1354, retrieves the first button record in the macro variable. In a decision step 1370, it is determined whether all button records have been obtained. If all records have been obtained, then the user is provided with a macro completion tone in a step 1372. Processing then returns to button monitoring step 1308 in FIG. 13A by way of flowchart connector 13 A. The tone provided in step 1372 indicates completion of macro processing. This allows a user to be doing other things or to multi-task while waiting for the telephone device of the present invention to automatically navigate to the selected point in a service menu. The user simply waits for the audible alert.

Returning to decision step 1370, if all records have not been obtained, processing continues to a decision step 1374. In decision step 1374, it is determined if the button type is immediate. If the button type is immediate, then the DTMF signal that corresponds to the button in the record will be transmitted in a step 1376. Processing will then continue at step 1368 to get the next button record from the macro variable. Returning to decision step 1374, if the button type is not immediate, i.e., the button type is wait, then the process of isochronous expansion occurs. The isochronous expansion begins by waiting in a step 1378 according to the elapsed time saved in the button record. For a button type of wait, a predetermined or preprogrammed amount of time elapses between sending of DTMF signals that correspond to the telephone buttons in the macro sequence. Once the predetermined time has elapsed, then processing continues at step 1380 to wait until the decibel or signal level of a received signal (receive analog signal 261 or a digital signal) indicates that the service is ready to receive the next DTMF signal in the macro sequence. Once the signal or decibel level has dropped below a threshold (X decibels), then the DTMF signal that corresponds to the button in the record is transmitted in step 1376. The next button from the macro record is then obtained in step 1368.

A macro may be composed as a mixture of immediate and wait buttons. The decibel threshold used by step 1380 is preferably configurable by a user. A flow diagram for invoking a macro by voice is illustrated in FIG. 13C.

In a step 1382, the user is prompted for the voice command to invoke the macro. In a step 1384, the user enters the delimited voice command. In a step 1386, the voice is then converted to a text string, in a manner similar to that described above. The local library (voice invoked macros) stored on a memory or storage device of the present invention is then accessed in a step 1388 to find the string identified in step 1386. If the macro for the text string is found, as determined in a decision step 1390, then in a step 1392, the macro variable is set to the macro field from the library entry found. The macro is then executed by the flowchart shown in FIG. 13B, described above, by way of the flowchart connector 13B. Returning to decision step 1390, if the matching macro is not found, then an error tone is provided to the user in a step 1394. Processing then continues back to step 1308 shown in FIG. 13A by way of flowchart connector 13 A.

FIG. 13D illustrates a flow diagram for browsing macros. In a step 1301, the user is provided with a message that explains how to hot-key out of the browse macro function. In the embodiment shown in FIG. 13D, the only way to exit the browse macro function is to hit the identified hot key. The hot key can be selected at any time to exit the browse macro function. In a step 1303, the next entry in the macro library is retrieved. First encounter of step 1308 from step 1301 retrieves the first library entry. If all macro library entries have been retrieved as determined in a decision step 1305, then the user is provided with an entries exhausted message in a step 1307. Processing then returns to the main loop shown in FIG. 13A by way of flowchart connector 13 A.

Returning to decision step 1305, if all macro library entries have not been retrieved, then the description is played of the retrieved macro library entry in a step 1309. Step 1309 plays the recording or annotates the text string. The user is then prompted in a step 1311 for whether the user wants to hear the invocation for this macro library entry. If the user does want to hear the invocation, as determined in a decision step 1313, then processing continues to a decision step 1315. In decision step 1315, it is determined whether the invocation type is a voice command. If the invocation type is not a voice command, indicating that it is a button command, then the button (or buttons) is annotated to the user in a step 1317. A tone is then provided to the user to indicate the end of the entry output in a step 1321. Processing then continues to step 1303 to get the next macro library entry. Returning to decision step 1315, if the invocation type is a voice command, then the string is annotated to the user in a step 1319. The tone indicating the end of entry output is then provided to the user in step 1321, and processing returns to step 1303.

Returning to step 1313, if the user opted to not hear the invocation sequence, then step 1313 proceeds to step 1321 for tone output, and processing returns to step 1303.

FIG. 13E illustrates a flow diagram for deleting a macro. In a step 1323, the user is prompted with a tone for the invocation type, i.e., voice or button. Deleting a macro by its voice command, or by its button reference, is determined by the type of delete command captured by step 1360 of FIG. 13 A. In a step

1325, the user enters the invocation according to the delete command determined at step 1360. In step 1325, the user speaks the voice command for a voice command macro or otherwise enters the button reference. In a step 1327, an attempt is made to retrieve the entry from the local macro library of the telephone device of the present invention. Step 1327 is carried out in accordance with the type of invocation for the macro sequence. For example, if the macro is a voice command macro, then the voice string from step 1325 is searched in step 1327 to find the particular macro. Step 1325 converts the voice to a text string in preparation for the search. In a decision step 1329, it is determined whether the macro has been found. If the macro has not been found, then an error tone is provided to the user in a step 1331. Processing then returns to the button monitor step 1308 in FIG. 13A by way of flowchart connector 13A.

Returning to decision step 1329, if the macro is found, then it is deleted in a step 1333. A successful tone is provided to the user in a step 1335. Processing then continues to step 1308 of the main loop shown in FIG. 13A by way of flowchart connector 13 A.

FIG. 13F illustrates a flow diagram for transmitting DTMF signals for appropriate buttons, for example dialing digits on menu option selections of an automated service. In a step 1337, transmission of the DTMF signal corresponding to the button that has been entered is transmitted. Processing then continues to step 1308 in FIG. 13A by way of flowchart connector 13 A.

4. Conclusion

While various embodiments of the present invention have been described above, it should be understood that they have been presented by way of example only, and not limitation. For example, additional functions can be added to the telephone device by using the software downloading feature of the present invention. The telephone device of the present invention may be configured with a display to facilitate interfacing with the user. The telephone device of the present invention may also be configured with removable storage or memory devices to facilitate interfacing the telephone device with a computer. The telephone device of the present invention may be called to retrieve recorded messages to facilitate remote access by the user. Thus, the breadth and scope of the present invention should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.