WO1994011983A2 - Data burst system for a telephone network - Google Patents

Abstract

A system and method for transmitting data bursts across a telephone network. The present invention allows voice and data transfer during a single telephone connection. Voice communication during data transfer does not corrupt or terminate the transfer. The present invention includes an interface device for encoding and decoding DTMF tones into data. Caller information can be selectively transferred by a telephone user to the called person.

Description

DATA BURST SYSTEM FOR A TELEPHONE NETWORK

Microfiche Appendix

A microfiche appendix containing computer source code is attached. The microfiche appendix comprises two (2) sheets of microfiche having 113 frames, including one title frame.

The microfiche appendix contains material which is subject to copyright protection. The copyright owner has no objection to the reproduction of such material, as it appears in the files of the Patent and Trademark Office, but otherwise reserves all copyright rights whatsoever.

Background of the Invention Field of the Invention

The present invention generally relates to data transmission and, more specifically, to a system for transmission of data between two computers over a telephone line, using a protocol based on standard DTMF tones. Background of the Technology

It is often desired to send data from a user's computer or workstation to another computer or to receive data from another computer at the user's computer. This communication is ideally desired in real-time, over a wide area, and with a diverse set of computer platforms. This type of data exchange is usually performed by use of standard modems over the telephone network. However, real-time communications with modems is complex and requires both sides to have modem equipment and the proper settings. The user must know both the transmit and receive modem settings before transmitting. With a modem, a user cannot use a single telephone line for voice and data communications simultaneously. The user, for example, would terminate a voice communication before being able to transmit data. Modems also do not associate contextual information with the transferred file. The ability to send and receive files is established but there is no ability to understand and interpret the information sent. In many cases, the amount of data to be communicated small, which ,can be considered a data burst or set. communication, a modem has an overhead or burden of a lo setup time relative to a data burst to be transmitted. Sin the modem setup time is on the order of 5 to 15 seconds, a the data burst may be of a similar or shorter duration, method of data communication eliminating the modem setup ti is desirable. The need of a modem for data communication o a telephone line can be eliminated by using an existing commo standard, Dual Tone Multi Frequency (DTMF) codes or tones, fo transmission. For short data sets, eliminating the modem an using DTMF codes for transmission leads to a faster effectiv data transfer rate.

During a telephone conversation, one person may ask th other party for their address, title, facsimile (fax) number or other information normally contained on a business card Business card information can be considered a small data se suitable for DTMF tone transfer from one computer to another It is desired to be able to transfer this information to th requestor as quickly and accurately as possible, preferably t an easily indexed location such as a computer database Limitations of prior methods include the following: mailin the information takes too long; facsimile only works if bot parties have fax machines, but the information still needs t be entered into the computer; and speech over the telephon may lead to misspelling or other mistakes. In addition, i would be advantageous to transfer the data during the middl of a voice conversation, for example, after the first part desires to place an order from the second party. The secon party sends a data burst containing his address or possibl some pricing information. The first party may send a dat burst in response ordering a particular model number. Then, the voice conversation could resume until the call is ende with closing remarks. Communicating short messages from computer to computer among coworkers or others in a Centrex or private branc exchange (PBX) environment is important in the business world. Group scheduling and meeting reminders are just two instances of electronic-.mail (E-mail) type messages. However, to use standard E-mail software, the user must have cables installed for a local area network (LAN) or a wide area network (WAN) , along with the costly network operating software (OS) . A way to communicate short messages for those businesses or organizations not having a regular LAN or WAN network is greatly desired.

A way of identifying a telephone caller before picking up the receiver, or otherwise answering, is important for many people. They may want to find a file or other information about the caller, or they may not want to answer the call. One potential means that is being introduced by the telephone companies is the use of Caller-ID. However, Caller-ID only provides the telephone number of the caller and no additional information. Many people could all be using the same telephone number, e.g., a company number, so automatic determination of the caller's name is not possible. Other systems provide a database of previous callers that is indexed after the call is answered and the name of the caller ascertained. The user would type in the name or part of the name to retrieve other information about the caller that has been prestored in the database. This type of system does not allow the user to avoid answering the telephone call depending on who is calling. Also, only prestored information is available. A means for providing a plurality of identification about the caller, including a call history, before answering the call is greatly desired.

In an office environment, a receptionist may announce a caller and ask the destination party or transferee whether the call should be transferred. An improved system would allow a call to be transferred in-context wherein the transferee will know who is calling and other information about the caller before the call is accepted and take appropriate action based on this knowledge. The call can then be refused, transferred to another person or back to the receptionist to take a message, or answered. Such a system that has little or no human intervention would have great utility in the busines world.

A telephone assistance apparatus for the hearin impaired, including a tone decoder responsive to DTMF outpu of a telephone receiver, is disclosed by Fowler, et al . , (U.S Patent No. 4,608,457) . The decoder converts the DTMF outpu into a digital binary code corresponding to the ke combinations depressed by a sender on the sender's telephon equipped with a DTMF generator (Touch Tone type telephone) A letter, numeral, punctuation mark, or one of severa possible words are sent by two keystrokes on the sender' telephone keypad.

Such a system includes a number of significan limitations. The sender must either have a table or char defining the keystroke combinations, or must be told by th hearing impaired person of the 58 recognized keystrok combinations. The process of sending a message or data i slow because the sender manually generates the keystrok combinations. Also, the DTMF encoded data transfer i unidirectional; the hearing impaired person communicates b voice only.

A data transmission system for interfacing with telephone line is disclosed by Brule, et al. , (U.S. Patent No.

4,937,853) . The system is used for entering bar code dat into a remote computer by standard DTMF telephone tones. A interactive telephone calling network interfaced with th remote computer sends a voice menu to the user. The use enters an identification number and passcode by either usin bar code data, the system keypad, or the keypad of an optional telephone. Thereafter, data is entered by use of a bar code reader. This data is converted to ASCII characters by the system, which are then subsequently converted to DTMF tones for transmission. The system has a tone receiver for receiving information from the remote computer for display on a LCD display to communicate with the user when the telephone is not provided. The system does not allow both voice and data communication by the user in one connection. The data must be converted to bar code format sometime before th telephone call is initiated or the data must be keyed in on character at a time on the user's keypad.

To facilitate the creation of a data message befor initiating a telephone call, a prior device uses a keyboard t enter the message into the device. A portable terminal use for brief queries to a database on a large central compute using a telephone for communication over the telephone networ is disclosed by Dayton, et al. , (U.S. Patent No. 4,799,254) Message characters are typed on the keyboard, digitally code and stored in memory. After a dial-up connection to th computer, the stored message is converted to a code usin unique pairs of standard DTMF tones provided by a ton generator to a speaker connected to a telephone mouthpiece. The computer responds to the user either by recorded o synthetic speech to a telephone earpiece or by DTMF tones t an optional microphone connected to the earpiece. The DTM tones are converted in the terminal to digital codes fo storage in memory and later display on a eight-character LC display. The telephone at the user end is not used fo outgoing voice since the telephone line at the destination is connected to the central computer. Therefore, both voice and data communication in a single connection cannot be accomplished. Thus while the preceding patents discuss converting barcode data, telephone keypad keystrokes, or stored ASCII data to DTMF codes for transmission on a telephone network to a remote central computer or a telecommunications device for the hearing impaired, none of the patents addresses having both voice communication and data bursts together during a single telephone connection. Prior patents do not address having a tone encoder/decoder combination to carry out a conversation and data exchange between two people.

Consequently there is a need for a system that permits wide area communication using telephone lines and DTMF data encoding for a data burst in combination with voice over a single telephone connection. Such a system should accommodate users on a wide variety of computer platforms, as well permitting data bursts in either direction between two use or both directions in a serial fashion. Such a system shoul also be inexpensive and easy to install and use.

Summary of the Invention The above-mentioned needs are satisfied by the presen invention which includes a system and method for sending dat bursts or messages across a telephone line between compute users.

Brief Description of the Drawings Figure 1 is a system level block diagram of a presentl preferred embodiment of the present invention showing sending workstation, a first destination workstation, and second optional destination workstation;

Figure 2 is a functional diagram showing the hierarchy o the software for a send process or operation that is execute in a workstation of Figure 1;

Figure 3a is a block diagram showing the main component of the DTMF interface device of Figure 1;

Figure 3b is a schematic diagram of the DTMF interfac device of Figure 1;

Figure 4 is a flowchart of a user interface layer o shell that is shown in Figure 2; Figure 5 is a flowchart of the STARTDATA function o

Figure 4; ₍

Figure 6 is a flowchart of the SENDDATA function o Figure 4;

Figure 7 is a flowchart of the ENDDATA function of Figure 4;

Figure 8 is a flowchart of the BEGINBOXDATA function of Figure 5;

Figure 9 is a flowchart of the BOXDATA function of Figure 6; Figure 10 is a flowchart of the ENDBOXDATA function of

Figure 7;

Figure 11 is a flowchart of a TOOLS LAYER-RECEIVE process that runs on the system of Figure 1 as shown in Figure 2 ;

Figure 12_„ is a flowchart of the TELCALLBACK function o Figure 11;

Figures 13a and 13b are a flowchart of a Business Car Transfer function shown in Figure 2, and which is stored an executed in the data burst system shown in Figure 1;

Figure 14 is an example of a screen display presented to a user when the telephone module is first activated as a part of the function shown in Figure 13; Figure 15 is an example of a screen display illustrating information for an outgoing call on line 1 as presented by the function shown in Figure 13;

Figure 16 is an example of a screen display presented to a user when the Phone Menu is opened as performed by the function shown in Figure 13 ;

Figure 17 is an example of a screen display illustrating information selected for a Business Card Transfer as performed by the function shown in Figure 13;

Figure 18 is an example of a screen display presented to a user when the received burst already exists in a database as presented by the function shown in Figure 13 ;

Figure 19 is an example of a screen display presented to a user when the received burst does not exist in the database as presented by the function shown in Figure 13 ; and Figure 20 is an example of a screen display presented to a user after a toggle to View Original has been done presented by the function shown in Figure 13.

Detailed Description of the Preferred Embodiment The following detailed description of the preferred embodiments presents a description of certain specific embodiments to assist in understanding the claims. However, the present invention can be embodied in a multitude of different ways as defined and covered by the claims. Reference is now made to the drawings wherein like numerals refer to like parts throughout . I . System Overview

The data burst system of the present invention include means to communicate short bursts of information over the mos ubiquitous network in the world, the telephone network Current network technology often requires specific hardwar for each workstation, special wiring between stations an complex protocols to transmit data. The present system use the telephone network to transmit data encoded into dual ton multi frequency (DTMF) signals and then decode the signal into standard ASCII characters for interpretation b application software. The means by which the data i interpreted and the applications that use this data ar described hereinbelow.

Each workstation is equipped with a DTMF Interfac Device, also referred to herein as the network device, tha integrates the telephone with the workstation. The networ device can control such telephone operations as dialing, taking the telephone line off hook and reading the DTMF codes entered by the user. In addition, the network device monitors telephone status, e.g., off hook, ringing, connected, and so forth, and also communicates with the workstation via a RS232 serial connection, a well-known standard in the computer and communication technologies, and data burst protocol to be described hereinbelow. The network device can determine the noise on a telephone line and reduce the time in between DTMF codes to speed up transmission, and it can control the volume of the lines. Also, the network device has the ability to convert DTMF codes to ASCII and vice versa.

Figure 1 is a block diagram illustrating an exemplary data burst system 100. The system 100 includes at least two computers or workstations 110a, 110b, and shown with a third optional workstation 110c which, for instance, may be IBM PC compatible computers, each having a processor that is at a minimum an Intel 80386 class microprocessor, and a memory (not shown) . Additionally, each of the workstations 110 includes a plurality of input/output (I/O) devices. For example, each of the workstations 110, as specifically shown at the workstation 110a, connects to a video display 112, a pointe device such as a track ball or mouse 114, a keyboard 116 an a secondary storage device such as a disk drive 118. I should be noted that, although the following description i provided as if a message sender, or user (not shown) , operate the workstation 110a via the input/output devices 112-118, users also employ the workstations 110b and 110c which are also understood to communicate with similar input/output devices. Of course, any number of workstations 110 may be provided in the system 100.

A DTMF Interface Device 120a (also referred to as box or interface box) is connected to workstation 110a at a communications port (not shown) via a RS232 serial interface. The device 120a also connects to a telephone 122a and a signal line connecting to a telephone jack 124a. Workstation 110b connects via a RS232 serial interface to a DTMF Interface device 120b. Device 120b also connects to a telephone 122b and a signal line connecting to a telephone jack 124b. Similarly, workstation 110c connects via a RS232 serial interface to a DTMF Interface device 120c. Device 120c also connects to a telephone 122c and a signal line connecting to a telephone central office wall jack 124c.

The system 100 thus comprises a plurality of data burst subsystems wherein each subsystem can transmit/receive voice and data signals. Each subsystem may also be referred to herein as a "databurst system" .

Some workstations may be at remote locations from each other as illustrated in Figure 1. The workstations at remote locations are connected via telephone lines, which are typically not directly wired, but instead are switched via a switching network such as a public telephone network 126.

Figure 2 illustrates a software hierarchy for the presently preferred workstation on 110. The software hierarchy carries out the data burst send and receive processes. A set of integrated application software running under a unified application system shell environment, referred to hereinafter as a shell 142, both initiates and interprets the transmitted data. The shell 142 preferably operates i conjunction with a windows environment 140 such as Windows 3. licensed by Microsoft. The integrated application softwar includes modules, e.g., telephone module 144, with associate submodules or functions, e.g., Business Card Transfer 146.

The shell 142 allows for easy upgrades of the data burs system by installing drop-in modules or applications. Onc installed, the shell 142 automatically adds that module to list of icons that appear on the left side of every shel window presented on the video display 112 (Figure 1) . In th presently preferred system 100, database (not shown) is to th shell module 142 using an object oriented accessible filin system. In the presently preferred embodiment, the databas utilized is db_VISTA available from Raima Corporation, whic is a relational database that supports variable lengt records.

The workstation module software 144 is divided into three layers to facilitate ease of use of the telephone 122 an isolate the applications from the host system or workstation 110. These layers include a tools layer 150, a manager layer 148, and an application layer 146, which is also called a user interface (UI) . The first two layers are frequently referred to as tools and manager, respectively. The tools layer 150 communicates directly with the device 120 (Figure 1) by use of a serial connection. Using serial connections provides for easy migration to a variety of platforms, e.g., Macintosh^®, Sun^®, and IBM PC. The responsibility of the tools layer 150 is to communicate with the hardware directly using the commands and protocols of the hardware. The manager layer 148 interprets the communication with the device 120 and informs the module 144 of changes in status. The separation of a manager layer from the tools layer permits the swapping out of the tools module and hardware, while maintaining a consistent, common application program interface (API) for the User Interface regardless of hardware type. The user interface layer 146 provides a graphical interface for the user to easily accomplish the data transfers. For example, consider workstation 110a as the origi workstation, device 120a as the origin device, workstatio 110b as the destination workstation, and device 120b as th destination device. (Of course, a message transfer in th reverse direction is equally possible.) The user interfac 146 initiates data transmission, while the manager layer 148 breaks the data into manageable packets and downloads the dat to the device 120a (Figure 1) via the tools layer 150. The device 120a places the data in an envelope or packet, describes the type of transfer and its checksum, and then converts each ASCII byte to two DTMF codes. The data is then transmitted to the destination device 120b via the telephone lines and decoded to ASCII data. The destination device 120b uploads the data to the destination host workstation 110b, where its manager recombines the packets and passes the information to the module 144. At every transmission or conversion, a checksum is provided to verify data integrity. If an error is detected, a not acknowledge (NACK) is passed back to the originator along with information on where the error occurred. If the data is successfully sent, a single acknowledge (ACK) is transmitted back to the originator.

Figure 3a is a block diagram of the major circuits and their interconnection for the DTMF Interface device 120

(Figure 1) . Figure 1 illustrates device 120 with one telephone 122 and one telephone line connected to the wall jack 124, device 120 but includes connections for a telephone line 1 380, a telephone 1 122, a telephone 2 384, and a telephone line 2 386. A user of the system 100 may optionally choose to use either one or two telephones, e.g., 122a and 122a' and one or two lines per device 120. For example, the user could have one telephone and two lines. The device 120 can even be operated without a telephone, but the user is then limited to speakerphone rather than handset conversations.

Line 1 380 interconnects a wall jack 124a to a telephone line interface 1 402, while line 2 386 interconnects another wall jack 124a' to a telephone line interface 2 404.

Telephone 1 122 connects through a switch 405, controlled by the workstation 110 connected to the device 120, to eithe a telephone interface 1 406 (normal mode) or to a power suppl 414 (local mode) . Telephone 2 122' connects through a switc 407, also controlled by the workstation connected to th device 120, to either a telephone interface 2 408 (norma mode) or to the power supply 414 (local mode) . As blocks 402 406 and 410 are substantially the same as blocks 404, 408 an 412, only the circuitry with respect to telephone 1 122 wil now be described. The telephone line interface 402 utilizes a "loop start type interface circuit that is well known in the telephon technology. This circuit generates at least 20 ma of loo current needed by the telephone company to detect an off-hoo condition of the telephone handset and respond with a dial tone. The telephone line interface 402 provides adequat filtering and protection from lightning and voltage spikes. The telephone line interface 402 sends and receives audio signals, which include Touch Tones or DTMF tones ™ , on an audio path bidirectionally with the telephone interface 406 and with a tone circuit 1 410. The telephone line interface 402 also generates a ring signal on a ring signal line to a microprocessor complex 420.

The telephone interface 406 has two modes of operation as follows: (1) Normal mode which is default even in the event of power loss to the network device 120. Normal mode just passes the telephone signals through to the bidirectional audio path with the tone circuit 410.

(2) Local mode in which the network device 120 is powering the external telephone 122 through the power supply 414. The external telephone 122 is treated just like a microphone and speaker to the audio circuits, and thus can be routed in or out of the device 120 as desired using an audio path to an audio switch 418. In local mode, the phone 122 will not ring. This is useful in the case where the device 120 first analyzes Caller Identification (ID) information, if present, after the first ring of a telephone call and notifies the phone module 144 (Figure 2) before the user hears th phone ring.

In either mode, the microprocessor complex 420 monitor the state of the telephone handset for on or off hoo condition via handset signal lines from the telephon interface 406. This information is passed on to the telephon module 144 in the workstation 110, which takes further action The device 120 has two independent tone circuits channel 410 and 412. Each tone circuit is physically tied to it respective telephone line 380, 386 and wall jack 124, 124' . The tone circuit 410 has three main functions:

(1) DTMF (Dual Tone Multi-Frequency) Transmission

(2) DTMF Receiver

(3) Call Process Filter The transmission section is capable of generating all 16 standard DTMF tone pairs with low distortion and hig accuracy. All frequencies are derived from a 3.58 Mhz crystal . The sinusoidal waveforms for the individual tones are digitally synthesized using programmable dividers an switched capacitor digital-to-analog converters.

The well known DTMF tones include two sinusoidal signals simultaneously transmitted. One signal is selected from a group of four high frequencies, and the other signal from a group of four low frequencies. The duration of the two frequency signal (burst) is 40 milliseconds (mS) while an intersignal or pause duration is 30 mS +/-10 mS. The standard signal plus pause interval for Autodialers, Central Office applications and also the device 120 default is 51 mS +/- lmS . The pause duration is software adjustable from 20 mS to 200 mS with a 'S' register command (ATSll=n) . On a quiet telephone line, both dialing and data bursts show a speed improvement by adjusting this register value.

The telephone keypad numbers 0 to 9, symbols "*" and "#", and the letters "A", "B", "C", "D" are represented by pairs of simultaneously transmitted signals of the frequencies (in Hertz) indicated in Table 1. These values are the standard DTMF tones used by the telephone companies .

The DTMF receiver section of the tone circuit 41 includes a tone chip that converts incoming DTMF tones into 10 digital format. The digital data is sent or received on multi-signal digital path connected to the microprocesso complex 420. DTMF data (0-9, *, #, A, B, C) is converted t 8-bit digital data and vice versa, as indicated in Table 2.

15

TABLE 2 DTMF to 8 Bit Data

20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Second D 1 2 3 4 5 6 7 8 9 0 * # A B C Digits

First

25 D 00 01 02 03 04 05 06 07 08 09

1 10 11 12 13 14 15 16 17 18 19

2 20 21 22 23 24 25 26 27 28 29

3 30 31 32 33 34 35 36 37 38 39

4 40 41 42 43 44 45 46 47 48 49 30 5 50 51 52 53 54 55 56 57 58 59

6 60 61 62 63 64 65 66 67 68 69

7 70 71 72 73 74 75 76 77 78 79

8 80 81 82 83 84 85 86 87 88 89

9 90 91 92 93 94 95 96 97 98 99 5 0 aO al a2 a3 a4 a5 a6 a7 a8 a9

* bO bl b2 b3 b4 b5 b6 b7 b8 b9

# cO cl c2 c3 c4 c5 c6 c7 c8 c9 A dO dl d2 d3 d4 d5 d6 d7 d8 d9 B eO el e2 e3 e4 e5 e6 e7 e8 e9 0 C fO fl f2 f3 f4 f5 f6 f7 f8 f9

7 of the 8 Bits (128 of 256) are used for standard ASCII, e.g., Digits "4" "1" = ASCII "A", 5 Digits "7" "c" = Hexadecimal 7f = ASCII "DEL" An extended Telephone Keypad is utilized for complete 1 of 16 DTMF codes.

The call process filter section of the tone circuit 410 helps the microprocessor complex 420 discriminate and count useful tones of interest:

Dial Tone 350 Hz continuous

Audible Ring 440 Hz 2 Sec. on / 4 Sec. off

Busy 440 Hz 0.5 Sec. burst

The power supply 414 is an UL/CSA approved 11-13 VAC,

1 amp supply which powers the internal circuits. The following signals are internally generated:

-35 to -40 VDC for powering telephone handsets 12 VDC for speakerphone and some analog circuits

5 VDC for microprocessor circuits +/-8 VDC for serial communications -2 VDC for audio amplifiers

The audio switch 418 includes bidirectional audio path connections to a speakerphone 424, an audio in/out block 428, the telephone handset 122 through the telephone interface 406, the telephone line 380 through the telephone interface 406 and telephone line interface 402, and a one-way connection to a caller identification (ID) circuit 430. The audio switch 418 also includes a digital bidirectional path to the microprocessor complex 420.

An 8 x 8 crossbar switch (not shown) is utilized by the audio switch 418. The phone lines 380, 386 are treated as having separate in and out lines. The telephone handsets 122, 122' are treated as having separate in and out lines. The speakerphone 424 has a separate in and out line. The audio block 428 has both 2-channel in and out lines. The Caller ID circuit 430 has only an in line. All the above combinations, other than Caller ID, are negotiated by the telephone module 144 (Figure 2) as the main routing mechanism. Any input to any output is possible. The 8 x 8 crossbar switch is illustrated by the matrix of Table 3. The letters A, B, -C, and D represent features of the present embodiment of the invention which are, respectively, music on hold, silence during hold, device conference connect lines, and speakerphone outgoing call. Of course, other features may be possible.

Spkrphone Out D D where columns are defined as follows :

0 = Speakerphone In

1 = Audio Out 1

2 = Audio Out 2

3 = Tel Line In 1 4 = Tel Line In 2

5 = Handset In 1

6 = Handset In 2

7 = Caller ID

The microprocessor complex 420 utilizes a traditional 65C02 8-bit microprocessor design with 8K RAM, 8K Flash ROM, a versatile interface adapter (VIA) 6522 chip including two 16-bit timers and 20 lines of input/output (I/O) , and an address decode 74HC138 chip running at 1.84 Mhz bus speed.

The control flow of the complex 420 includes polling and interrupt mechanisms. The microprocessor complex 420 also includes a communications port 422 having two asynchronous communication interface adapter (ACIA) 6551 chips and a RS232 interface MAX232 chip available from Maxim Integrated

Products, that connects to the workstation 110 (Figure 1) and optionally to another device 120. The device 120 to device 120 connection allows the AT+LINK command to be used for device to device communication. In an another embodiment, the component£τ of the microprocessor complex 420 may be combined together in one semi-custom package.

The operation of the 65C02 microprocessor is controlled by a program written in assembly language. Some of this code is listed in the attached Microfiche Appendix with sections titled "const.src", "kernal .src" , and "MAIN.src". One skilled in the technology will recognize that the operation of the device 120 can be controlled by a number of different processors, languages and circuitries.

Caller ID or Caller Number Delivery (CND) is a feature in a General Switched Telephone Network (GSTN) . This service is provided by the telephone company and allows called customers to receive a calling party' s number during the ring cycle. The device 120 has one receiving circuit that it shares between the two lines. Characteristics of Caller ID include:

Characteristic Description

Link Type Simplex, two wire Transmission scheme Analog, phase-coherent FSK

Logical 1 (mark) 1200 +/-12 Hz

Logical 0 (space) 2200 +/-22 Hz

Transmission Rate 1200 Bps

A sequence of steps for Caller ID (CID) follow using line 2 as an example. The workstation 120 causes the switch 407 to be at the position shown in Figure 3a, which sets the telephone handset 122' in Local mode. Local mode allows Caller ID operation. The device 120 senses an incoming ring on line 2 and switches the CID circuit 430 to receive signals from line 2. The device 120 reads the CID data and then resets the CID switch setting back to Normal mode. The device 120 sends the CID information to the telephone module 144 (Figure 2) for further action. The telephone module 144 then sends a command to switch the telephone handset 122' to Normal mode. The audio in/out block 428 has two-channel audio inputs and two-channel audio outputs to pass audio signals to and from the phone lines . In a simple i plementation of the block 428, an external music source could be used for music on hold. Also, computer generated sound bites can be placed on the phone lines via block 428. Recording phone conversations is also made possible by line level ready analog signals at block 428.

In another embodiment, a SOUND BLASTER™ by Creative Labs, Inc., sound card product is utilized with the device 120 to implement a digital answering machine.

In yet another embodiment, with the addition of a daughter board 432, the device 120 becomes Fax/Data/Voice ready without the need of the sound card unless simultaneous

Fax and Digital voice recording is required. The daughter board 432 is a small printed circuit board (PCB) which plugs into the DTMF Interface device 120. The daughter board is a co-processor design which memory maps into the device 120.

Unlike Centrex conference, two line conference establishes connection with a minimum of two external parties and essentially hooks them together with the Audio Switch

418. The main advantage over 2-line telephones with conference features is the ability to adjust incoming and outgoing volume levels on both lines.

The DTMF Interface device 120, as directed by the telephone module 144, is always monitoring Touch Tone information. In it simplest form, device 120 could be used for an order entry or voice prompting system. The next level of complexity assumes two shell users are active in this mode with a robust protocol, error correction and high speed tones or, in the present invention, short pauses between tones provides a Data Exchange Vehicle. While this Data Exchange Vehicle could be compared to a low speed modem, the device 120 provides more capability.

Internal to the tone circuit 410 is a decoder which employs digital counting techniques to determine the frequencies of the incoming tones, and verify that they correspond to a standard DTMF frequency. An averaging algorithm protects against tone simulation by extraneous signals (such as voice) , while tolerating small deviations in frequency. The algorithm provides an optimum combination of immunity to talkoff with tolerance to interfering frequencies (third tones) and noise.

An example of data flow through the device 120 using workstation 110a (Figure 1) as the origin and workstation 110b as the destination follows. The RS232 links between the workstations 110 and devices 120 carry digital data at 9600 bps. The telephone network 126 is a voice grade telephone line - analog link. The workstation 110a sends a packet of ASCII data with a variable length to a maximum of 512 bytes in the presently preferred embodiment. This includes length of data, data, checksum and terminator.

The DTMF Interface device 120a receives this ASCII data and places it into its RAM buffer in the microprocessor complex 420 and starts the conversion process to an analog signal in the tone circuit 410 or 412. This analog signal is a digitally synthesized sinusoidal waveform converted using switched capacitor digital-to-analog converters, and is conforming to one of 16 standard DTMF tone pairs. The device 120a begins transmitting this analog, data to device 120b. Due to the possibility of telephone line noise, length, and echo, the transmission speed typically varies from 100 to 180 bits per second. Both amplitude and duration are variables in the analog data and are software correctable. The DTMF Interface device 120b then receives the incoming analog data. The high and low tone-pairs are separated by applying the DTMF signal to the inputs of two sixth-order switched bandpass filters in the tone circuit 410 or 412. The tone circuit decoder then determines the frequency by employing digital counting techniques which yield data that is further processed and packetized to 9600 bps ASCII data suitable for passing on to the workstation 110b. This process can go in either direction.

Figure 3b is a schematic diagram of the DTMF interface device 120 shown in Figure 1 and 3a. Table 4 is a list of components corresponding with the schematic diagram of Figure 3b. TABLE 4

II. Data Burst Protocol This section describes the software interface between the DTMF Interface device 120 (Figure 1) and the shell software. Wherever possible, the device 120 emulates a Hayes > compatible modem.

A. Device to Workstation Commands

The general format of a command from the device 120 to the workstation 110 in the presently preferred embodiment is as follows:

\ DLE I Message ID j Length j Data [ Checksum ] Where:

Field and length of Field Description Data-Link Escape (DLE) (8 bits) Hex value 10 MessagelD (8 bits) Specifies Message type and Phone Line number Message type (5 Most Significant bits) Line number (3 Least Significant bits) Length (16 bits) Specifies the length of the data plus checksum

Data (n bytes) The body of data

Checksum (8 bits) An 8 bit checksum

The checksum is calculated by taking the sum of the ASCII values of the data and then exclusive-ORing (XOR) the sum with the value OxFF. The XOR boolean operator is well-known in the computer technology.

To preserve space, this format is violated when the message type is Status. In this case, the Length field is replaced with the Status word, and the Data and Checksum fields are not used.

1. Message Types

The following is the list of Message types and their values : Description

Device Status

Link Upload Request

Burst Detected

DTMF Data in Buffer

Automatic Number ID

Burst Error

Burst successfully transmitted

Link Error

Link successfully transmitted

The bit assignments for the Status bytes and their definitions are:

FIRST BYTE

The phone is ringing

The handset is off hook

The Line is Busy

The Line has a Dial Tone

The Line is Dialing out

There are Characters in the DTMF Buffer

The Line is off Hook

The Device has detected an error

SECOND BYTE

Bit 0 : Link Request A Link has been requested

Bit 1 Link Active Link is active Bit 2 Burst Request A Burst is Requested Bit 3 Burst Active Burst is Active Bit 4 Connection Connection Detected

After Dial Bit 5: Time-out Either no connection detected after ringing stops or no dial tone detected after off-hook Bit 6 : Unused

Bit 7: Unused

The Status message will be sent whenever a change in state occurs for any status or following an ATZ command (described below) .

B. Workstation to Device Command Set

In the presently preferred embodiment the following standard HAYES AT Commands are supported. All commands must end with the Carriage Return (OxOD) character.

Command Description ATD Dialing ATDT Tone Dialing ATDP Pulse Dialing

Dialing Modifiers T Tone P Pulse

W Wait for Dial Tone. If dial tone is not sensed within 15 seconds, the call is terminated and the Device returns to command mode. , Pause for the number of seconds stored in Register 8. Default is 2 seconds. ! Flash

0-9#* A-D Tones ATHO On Hook ATH1 Off Hook ATIO Product ID ATI1 ROM Checksum ATI3 Software Revision Level

ATZ Reset Device, forces a Status Message

ATS8=n Set Register 8 - Delay time in seconds.

Default is 2 seconds. ATSll=n Set Register 11 - Time between DTMF codes in msec. Default is 95 msec. ATX3 Don't wait for Dial Tone before dialing

Note: This will cause the Device to not wait for dial tone before initiating the call, but all dial modifiers are still in effect. ATX4 Wait for Dial Tone before dialing

(default) ATA Answer ATLn Speaker Volume Control where n is in the range of 0 to 15.

In addition the device 120 supports these added, device specific commands: AT+DTMF This command will be given when the host sees the DTMF bit set in the Status byte. When given, the Device uploads all characters in its DTMF buffer using the DTMF Data Message. The Device will insert a Carriage Return (OxOD) character into its DTMF buffer when it detects the handset going on hook. The Device will maintain at least a 256 byte buffer per telephone line. As the buffer fills, the oldest characters will be overwritten. AT+LSn This command sets the phone line. Valid values are 1 and 2. Any commands given after this command will apply to the set line. The Device powers up in a Line 1 setting.

AT+BURSTnn c This command initiates the sending of a packet of data (DTMF codes) . nn specifies the length of the data plus checksum (the first n indicates the high byte and second n indicates the lowbyte) , d is the data and c is the checksum.

AT+LINKnndc This command initiates a link between two attached Devices. nn indicates the length of the send data plus checksum (the first n indicates the high byte and second n indicates the low byte) , d is the data and c is the checksum.

AT+BRESEND This command is a signal from the shell that the destination workstation did not get a valid packet, probably due to a checksum error. This command prompts the destination Device to send a message to the origin Device on the other end.

AT+BCONFIRMc This command is a signal from the shell that the destination Device received a valid packet, confirmed by a ^■ proper checksum. This command prompts the destination Device to send a message to the origin Device on the other end. c is the checksum. AT+M(x) (y) (1/0)Matrix command (x) + (y) specify index into the matrix of Table 3. A (1) establishes the connection while a (0) breaks the connection.

ATP11 Enter local mode, Line 1.

ATP10 Enter normal mode, Line 1.

ATP21 Enter local mode, Line 2.

ATP20 Enter normal mode, Line 2. Some examples of the matrix commands are as follows: Hold - music on hold; Connect Lines - conference call; and Speaker Phone - use speaker phone voice. The device 120 responds to every AT command, except ATD and ATZ, with a text string indicating the result of the command. "Error" indicates that the device 120 was unable to parse or execute the command. For data burst transfer, a checksum error or the lack of a device 120 at the other end of the line triggers a sending of a "BurstError" DLE message to the origin host. "BurstReceived" DLE message indicates a successful execution of the data burst transfer.

Ill. Data Burst Function The data burst function will now be more fully explained by reference to Figures 4-12. Referring now to Figure 4, the User Interface (UI) layer will be described in a send process. This layer interfaces the application software with hardware/software that is used to implement the data burst function. The flow shown in Figure 4 is a general or generic user interface. A specific use of the data burst transfer protocol, implemented in the UI layer, namely, the Business Card Transfer application, will be described in conjunction with Figure 13. The burst function begins at a start state 402 and moves to "startdata" function 404, which is at the manager layer 148 (Figure 2) . The call to the function 404 initiates a send of a data burst. Function 404 will be more fully discussed in conjunction with Figure 5 hereinbelow. Upon return from function 404, a test is made at a decision state 406 to determine if a burst error flag was set in function 404. A burst error indicates a fatal problem that causes a discontinuation of the send process. If so, the burst function moves to a state 408 wherein the application software will either abort the send or restart the send operation depending on the application. If there is no burst error, as determined by state 406, the burst function moves on to state 410 wherein a four byte tag and a stream of data are composed or made into a packet to be sent by the "senddata" function 412, which is at the manager layer. The tag is used to uniquely identify the type of information contained in the packet. The function 412 actually sends the data burst in a subpacket that is up to 512 bytes in size, which may or may not account for the entire packet size . Function 412 will be more fully described in conjunction with Figure 6.

Upon return from function 412, a test is made at a decision state 414 to determine if burst error was set in function 412. If so, the burst function moves to a state 408 wherein the application software will either abort or restart the send operation depending on the application. Note that upon receipt of a burst error message, an "enddata" function 422, described hereinbelow, does not need to be called. If there is no burst error, as determined by state 414, the burst function moves on to a decision state 416 wherein a determination of whether all the data of the current data packet has been sent. For example, the total data packet size may be 678 bytes, but only 512 bytes are sent in a subpacket at one time, so after the first send, 166 bytes still need to be sent.

In the Electronic Business Card feature of the present invention, a packet is defined as one database attribute relevant to a person, e.g., a business street address, or in other words, a group of data sent under the same tag or header. Therefore, when the data packet is not complete as determined by state 416, the burst function moves to state , 418 wherein the next packet is accessed in preparation for the next call to the senddata function 412.

If one entire data packet has been sent, as determined by state 416, the burst function proceeds to a decision state 420 to determine if the application software has another packet to send. Most applications will send a plurality of data packets in one data burst. If the last data packet has not been sent, the burst function loops back to state 410 to compose the next data packet. However, if the last packet has been sent, as determined by state 420, the burst function moves to the "enddata" function 422, which is at the manager layer. The call to the function 422 signals completion of one or more data bursts. Function 422 will be more fully discussed in conjunction with Figure 7 hereinbelow.

Upon return from function 422, a test is made at a decision state 424 to determine if burst error was set in function 422. If so, the burst function moves to a state 408 wherein the application software will either abort the send or restart the send operation depending on the application. If there is no burst error, as determined by state 424, the burst function moves on to an end state 426 and the user can again initiate a data burst.

To prevent the UI from freezing up during the process, calls to the "senddata" function 412 take place within a Window routine, which is message/interrupt driven. The Manager and Tools endeavor to return control to the UI layer as quickly as they can. During a data burst, functions for the line being used are disabled with the exception of a few, e.g., hang up or flash.

Referring now to Figure 5, the "startdata" function 404 of the manager layer shown in Figure 4 will be described. Function 404 initiates the sending of data bursts and verifies the path from a origin workstation to a destination workstation as shown in Figure 1. For example, workstation 110a may be the origin workstation and workstation 110b may be the destination workstation. The burst function begins at a start state 440 and moves to a "beginboxdata" function 442, which is at the tools layer. Function 442 creates a beginning packet in a format such that the DTMF Interface device 120 can begin transmission or respond. Function 442 will be explained more fully in conjunction with Figure 8.

Upon return from the function 442, the burst function determines at a decision state 444 whether the function 442 returned any errors, e.g., no response by the DTMF Interface device 120 or a timeout. State 444 also includes a call to a function named "check2sum" that calculates and verifies the checksum sent with the current packet. The checksum is as previously described hereinabove. If an error is detected by state 444, the burst function proceeds to a decision state 446 wherein a determination is made whether a predetermined threshold number of errors has been reached. The manager layer keeps track of the number of errors in a static variable within the manager. The number of errors is cleared after each successful send of a packet to the destination host. If the number of errors in the static variable reaches the threshold number, a burst error flag is set and reported back at state 448 to the user interface (UI) layer (Figure 4) and control is returned to the UI layer through a return state 450. If the preset maximum errors have not been reached as determined by state 446, the burst function loops back to state 442 to try sending the beginning packet again. If there are no transmission errors as determined by state 444, the burst function advances to state 452 and initiates the dispatch of the packet from the origin DTMF Interface device 120a as shown in Figure 1 to the destination device 120b. The packet is sent via DTMF codes including a single byte at the end indicating checksum. At state 454, the destination device 120b receives the packet. Then at a decision state 456, a determination is made by the device 120b whether the checksum is correct. This state includes a call to the substantial equivalent of the "check2sum" function, mentioned earlier, that calculates and verifies the checksum sent with the current packet. If the checksum is not correct at state 456, the destination interface device 120b returns an error at state 458 and the burst function moves back to state 446 to check if the preset error threshold has been reached. However, if the checksum is correct at state 456, the packet is sent from the destination device 120b to the destination workstation or host 110b at state 460. Then, at a decision state 462, a determination is made whether the checksum at the destination workstation 100b is correct, including a call to the "check2sum" function, mentioned earlier. If the checksum is not correct at state 462, the destination interface device 120b returns an error to the originating device 120a and thence to the originating host 110a at state 458 and the burst function moves back to state 446 to check if the preset error threshold has been reached. However, if the checksum is correct at state 462, a burst success message is sent by the destination device 120b to the originating device 120a and thence to the originating host 110a and a return is done at state 450. The burst success message is a confirmation to the originating workstation 110a of the successful sending of a packet. Until this message is received by the UI, subsequent calls to the "senddata" function 412 are not made.

The states 444 through 464 form a common set of steps that are also utilized in the functions 412 and 422. The description for these steps will not be repeated, but reference will be made back to states 444 to 464.

Referring now to Figure 6, the manager layer "senddata" function 412 shown in Figure 4 will be described. Function 412 sends a data burst from the origin workstation 110a to the destination workstation 110b as shown in Figure 1. The burst function begins at a start state 480 and moves to a state 482 wherein a check is made for valid data length and a valid pointer to the data buffer. Then at state 484, a determination is made whether the data packet needs to be split up. This determination is actually part of a "splitdata" function 486. If the data length is greater than 512 bytes, the function 486 splits the burst packet into a piece small enough to send and stores the remainder in a dynamic-length buffer "rbcur". A dynamic length buffer does not have a fixed length assigned for it, but is dynamically allocated.

However, if the data length is not greater than 512 bytes, the burst function moves to "check2sum" function 488. Function 488 calculates a one-byte simple data packet checksum by adding the ASCII value of all characters in the string and then XORing the sum with the value OxFF. In this specific instance of the "check2sum" function 488, the verification step is not done. Upon return from function 488, the burst function proceeds to state 490 wherein the current data packet being sent is buffered in a dynamic- length buffer "bcur" in case a resend operation is necessary. Resend will be more fully discussed hereinbelow.

Then the burst function moves to a "boxdata" function 492, which is at the tools layer. Function 492 transforms the data packet into a packet with a format that the DTMF Interface device 120 can understand. Function 492 will be explained more fully in conjunction with Figure 9. Upon return from the function 492, the burst function moves to decision state 494. States 494 through 514 are essentially the same as the states 444 through 464 of Figure 5. Therefore, to avoid redundancy, the description for these steps will not be repeated, but reference is made back to states 444 to 464. The return to the user interface layer (Figure 4) is at state 500. Referring now to Figure 7, the manager layer "enddata" function 422 shown in Figure 4 will be described. Function 422 signals completion of the sending of packets from the origin workstation 110a to the destination workstation 110b as shown in Figure 1. The burst function begins at a start state 530 and moves to a "endboxdata" function 532, which is at the tools layer. Function 532 creates an ending packet in a format that the DTMF Interface device 120 can understand. Function 532 will be explained more fully in conjunction with Figure 10. Upon return from the function 532, the burst function moves to decision state 534. States 534 through 554 are essentially the same as the states 444 through 464 of Figure 5. Therefore, to avoid redundancy, the description for these steps will not be repeated, but reference is made back to states 444 to 464. The return to the user interface layer (Figure 4) is at state 540.

Referring now to Figure 8, the tools layer "beginboxdata" function 442 shown in Figure 5 will be described. Function 442 sends an initial subpacket across the DTMF Interface device 120 (Figure 1) to signal that subsequent subpackets will be coming across the line. The burst function begins at a start state 570 and moves to a state 572 wherein a beginning packet is created in an AT+BURST format . This packet has the two length bytes equal to 2 in binary format, a beginning marker <cntrl-Q>, and the appropriate checksum. At state 574, this packet is sent to the origin DTMF Interface device 120a (using the same example origin device as earlier) . At a decision state 576, a determination is made if the device 120a received a good packet. If so, a return is made at state 580 back to the function 404 (Figure 5) . If not, a "no response" or error status is returned to the "startdata" function 404 followed by the return at state 580.

Referring now to Figure 9, the tools layer "boxdata" function 492 shown in Figure 6 will be described. Function 492 sends a subpacket across the DTMF Interface device 120

(Figure 1) . This may be the only portion of the data needed.

It will periodically be called to send data until the transmission is completed. The burst function begins at a start state 590 and moves to a state 592 wherein a data subpacket is created in an AT+BURST format. This subpacket has the two length bytes, the data stored into a string to be sent, the appropriate checksum, and a carriage return (\r) . At state 594, this subpacket is sent to the origin DTMF Interface device 120a (using the same example origin device as earlier) . At a decision state 596, a determination is made if the device 120a received a good packet. If so, a return is made at state 600 back to the function 412 (Figure 6) . If not, a "no response" or error status is returned to the "senddata" function 412 followed by the return at state 600.

Referring now to Figure 10, the tools layer "endboxdata" function 532 shown in Figure 7 will be described. Function 532 sends an ending or final subpacket across the DTMF Interface device 120 (Figure 1) to signal that no more subpackets for the current packet or database field are forthcoming. The burst function begins at a start state 610 and moves to a state 612 wherein an ending packet is created in an AT+BURST format. This packet has the two length bytes equal to 2 in binary format, an ending marker <cntrl-S>, and the appropriate checksum. At state 614, this packet is sent to the origin DTMF Interface device 120a (using the same example origin device as earlier) . At a decision state 616, a determination is made if the device 120a received a good packet. If so, a return is made at state 620 back to the function 422 (Figure 7) . If not, a "no response" or error status is returned to the "enddata" function 422 followed by the return at state 620.

Referring now to Figure 11, a receive process as performed at the tools layer will be described. This process takes place when the destination workstation 110b as shown in Figure 1 (using the example destination workstation as earlier) receives a packet. The burst function begins at a start state 650 and moves to a state 652 wherein a data subpacket is received at a communication port receive buffer (not shown) of the destination workstation 110b. Then, at state 654, the tools layer receives a "WM_COMMNOTIFY" message from Windows as a notification that a message has been received by the receive buffer. The burst function moves to "tools_parse" function 656 which includes a state machine to determine the packet message type. Function 656 also copies the data in the receive buffer to a dynamically allocated memory block to store data in a string format. Function 656 is called by the tool layer whenever there are characters in the buffer. It continues until all of the characters are processed. However, it does not rely on all of the data to be present in the buffer when processing begins. Therefore, messages can span two or more calls to the parser. Function 656 is set up as a state machine to look for the <DLE> character as the start of commands or messages from the device 120 or <CR> character as the start of an alphanumeric response.

A decision state 658 then determines if the subpacket contains a burst message. If not, the burst function moves to state 660 and waits for the next data subpacket. If the subpacket contains a burst message as determined by state 658, the burst function proceeds to state 662 wherein the data string is sent to the manager for parsing into a bMsg_st structure. The bMsg_st is a data structure within the memory of the workstation 110 which temporarily stores information associated with the data burst. This structure includes a four byte tag to identify the data type, the length of data in bytes, and a union of three pointers to the data in three different formats. A "telcallback" function 664, which is at the manager layer 148 (Figure 2) , is then called. The function 664 receives messages from the tools layer 150, processes them, and returns the results to the UI layer 146. The function 664 will be further described in conjunction with Figure 12.

Upon return from the function 664, a decision state 666 determines if the manager layer called the "resend" function 708. If so, the tools layer "resend" function 668 is called. Function 668 sends a message to the destination device 120b to issue a resend command, which requests a resend of the last subpacket, to the device 120a at the other end of the connection. Subsequently, the burst function proceeds back to state 660 to wait for the resent subpacket to be received. If state 666 is false, the burst function moves to a "confirm" function 670 at the tools layer. The function 670 sends a message to the destination device 120b to issue a confirm command to the origin device 120a at the other end of the connection. Upon return from the function 670, the burst function proceeds to state 672 wherein the memory allocated as part of the "tools_parse" function 656 is deallocated. The memory is not needed since the data is copied by the manager at function 664. The burst function then moves to a decision state 674 to determine if the user wishes to quit the receive process. If so, the burst function moves to a state 676 and exits the burst process. If not, the burst function moves to state 660 and waits for the next data burst.

Referring now to Figure 12, the manager layer

"telcallback" function 664 shown in Figure 11 will be described. Function 664 is called by the tools layer to parse the data string sent by tools into the bMsg_st structure previously mentioned. The burst function begins at a start state 690 and moves to a decision state 692 wherein a determination is made whether the string has a beginning marker (<cntrl-Q> in the presently preferred embodiment) . If so, the burst function moves to state 694 wherein a "TM_BURSTACT" message is sent to the UI, followed by a return to the tools layer (Figure 11) at state 696. If the decision state 692 is false, the burst function moves to a decision state 698 wherein a determination is made whether the string has a ending marker (<cntrl-S> in the presently preferred embodiment) . If so, the burst function moves to state 700 wherein a "TM_BURSTNOTACT" message is sent to the UI, followed by a return to the tools layer (Figure 11) at state 696. If the decision state 698 is false, the burst function proceeds to a "parsedata" function 702. The function 702 takes the data string, parses it, and fills in the bMsg_st structure with tag and data in preparation to be passed up to the UI layer. Upon return from the function 702, a "check2sum" function 704 calculates and verifies the checksum. The checksum is as previously described. If the checksum is not correct as determined at a decision state 706, a manager layer "resend" function 708 is called, which will call the "resend" function 668 at the tools layer (Figure 11) . If the checksum is correct at state 706, the burst function proceeds to a decision state 710 to determine if the data is complete by checking a three byte marker or continuation string at the end of the subpacket. This check is actually part of a "unitedata" function 712. If the data is not complete, function 712 receives the incoming data subpacket and buffers it until the remaining data arrives in a subsequent subpacket. The return at state 696 is done if the data is not complete.

When the remaining subpackets arrive, the function 712 reunifies the data into a complete packet within the bMsg_st structure and then sends the structure to the UI at state 714. A "TM_BURST" message accompanies the structure, and then a manager layer "confirm" function 716 is called, which will call the "confirm" function 670 at the tools layer

(Figure 11) . Finally, a return at state 696 to the function

670 is done. Software for the databurst function is, in a presently preferred embodiment, written in 'the "C++" language. The software described herein, some of which is listed in the attached Microfiche Appendix was translated from the source code into object code using the Borland "C++" compiler, version 3.1. Sections titled "mgrburst.txt" and "tlburst.txt" are included in the Microfiche Appendix. Nonetheless, one skilled in the technology will recognize that the steps in the accompanying flowcharts can be implemented by using a number of different languages, language translators, computers and circuitries.

The manager layer functions as shown in the attached Microfiche Appendix are as follows: StartData, SendData, EndData, _check2sum, _resend, _confirm, _jarseData, _splitData, _uniteData, TelCallBack. The tools layer functions as shown in the attached Microfiche Appendix are as follows: BeginBoxData, BoxData, EndBoxData, Resend, Confirm, TOOLS_Parse.

IV. Business Card Transfer Application One or more applications programs in the user interface layer, available as part of the Windows dynamic link library

(DLL) , may be included under an applications module, e.g., telephone module, which is also part of the DLL. These are stand-alone programs that can be accessed by other functions, modules, or executable files.

The present invention includes an application called Business Card Transfer. This function transmits business card information from one workstation to another via the phone lines using the data burst function. The information is automatically formatted in the shell database, and a destination user is given the option of saving, modifying or destroying the entry. The Business Card Transfer function easily automates the formerly slow and error prone process wherein the user manually typed-in database entries. Figures 13a and 13b are a flowchart which, in conjunction with the screen displays of Figures 14 to 20 illustrate one presently preferred embodiment of the Business Card Transfer (BCT) function software which transmits data via the system 100, and is a part of the present invention. It should be noted that, unless specified otherwise, the operation described with reference to the flowchart of Figure 13, is within one of the workstations 110, e.g., workstation 110a, and input and output functions described therein are performed via the input/output devices 112-118 which communicate directly with the workstation 110a.

Referring to Figure 13, the BCT function, begins at a start state 740. In one presently preferred embodiment, BCT may be executed from Microsoft Windows^® 3.1 or higher software running on the Microsoft MS-DOS operating system, preferably version 4.1 or higher. The Windows software may be run from the RAM memory within any one of the workstations 110. The shell software of the system 100 is normally initiated at Windows start-up, although it may also be initiated from the Windows Program Manager, or the Windows File Manager, for example, at a state 742. In any case, once the shell is open, the user selects which module, e.g., telephone, to run by clicking on the icon for the module. Typically, the user activates functions on a menu or dialog box by the "point and click" method associated with pointer devices such as the mouse 114. The user simply positions the cursor (not shown) on the video display 112 over the desired icon (or button in other instances) and depresses a button on the mouse 114. Of course, other indication methods may be used, such as a keyboard or trackball. When the phone icon has been selected, a display screen as exemplified by Figure 14 is seen on the video display 112 of the workstation 110a. The user can then click on the Dial button 850 which retrieves a phone number list from which a person to be called is selected. At state 744, once the person is selected, the call is initiated. A display screen exemplifying the information for an outgoing call on line 1 is shown by Figure 15. At this point, the user at the origin end can begin voice communication with the user at the destination end as in a typical telephone call. Voice communication is possible throughout the flow shown in Figure 13 .

At a decision state 746, a determination is made whether the send process or the receive process is to be executed on the user workstation 110. The origin workstation 110a executes the send process while the destination workstation 110b executes the receive process. Of course, either workstation 110 may transmit or receive data. If the send process is to be executed, the burst function moves to a state 748 wherein the user opens the phone menu and selects, for this example, the Initiate Business Card Transfer item 860 as illustrated by the screen display of Figure 16. This selection is done, for example, by moving the mouse to that line in the phone menu, or by using the keyboard down cursor key. The burst function proceeds to state 750 wherein the user selects or deselects data attributes that are to be sent to the destination workstation 110b as illustrated by the screen display of Figure 17. The user can choose all information 870, all business information 872, all home information 874, or subsets of the business or home information. The subset is made by selecting (by clicking on the square box next to the attribute name, or others means) the desired attributes, e.g., company name 876 or fax number 878, from the business or home information. In the example screen display of Figure 17, business information attribute 880 is darkened to indicate that it has been selected. When the attributes are properly selected, the user clicks on the "OK" button 882. The send process then essentially executes the general User Interface flow of Figure 4. Each attribute may be composed of one or more data fields. A list of potential data fields, including a tag and the associated data, is shown in TABLE 4.

TABLE 4 Tag Data FINA First Name 1

1

5

The general User Interface (UI) flow is summarized by the states 752, 754, and 756. At state 752, the UI initiates the burst by calling the "startdata" function 404 (Figure 4) . The UI then moves to state 754 and iterates through the data 0 by calling the "senddata" function 412 for each checked attribute which ultimately becomes a packet. At state 756, the UI calls the "enddata" function 422 to signal the end of the burst. The flow then proceeds from state 756 through the off page connector A 758 on Figure 13a to the off page 5 connector A 758 on Figure 13b and then to state 760.

At state 760, the burst function displays the phone module screen as previously illustrated by Figure 15. Note that data is transferred during states 752 to 756 and voice communication over the telephone line is not practical (but 0 is possible) during that time due to the DTMF tones being transmitted. Also of note is that voice communication during. the data transfer time will not cause data transmission errors or terminate the data transfer. Good voice communication can be resumed after state 756. The "HANG UP" button is selected when the user desires to terminate the voice communication, and a screen display as previously shown by Figure 14 is seen on the video display 112. At a decision state 762, the user either quits the shell and returns to the Windows environment at state 764, or loops back through the off page connector C 766 of Figure 13b to the off page connector C 766 of Figure 13a and subsequently to state 744. If a receive process is to be executed as determined at state 746, the person at the origin end of the connection initiates a Business Card Transfer at state 780. The following description then applies to operation in the destination workstation 110b. At state 782, a structure to temporarily hold a database entry is set up by the burst function. This structure receives the attributes sent over with each call of the "senddata" function 412. Associated with the structure is unique identification (UID) information which includes a serial number of the origin device 120 and other information that is used to identify the structure. This UID information is indicative of an individual entity such as a person, company, or organization. After the structure is set up at state 782, the burst function moves to a decision state 784 to determine if the burst contains an attribute from a "senddata" function call or an endburst marker from an "enddata" function call. If the burst contains an attribute, the burst function moves to state 786 wherein the attribute is placed into the structure set up at state 782, followed by a loop back to state 784. This loop continues until an endburst is detected by state 784 and the burst function moves to state 788. At state 788, the structure that has been filled by state 786 is presented to a display routine. The burst function then proceeds through the off page connector B 790 to Figure 13b and further to a decision state 792 wherein the UID of the structure filled by state 786 is compared to the UIDs of entries in the shell database. If the UID of the structure matches a UID in the database, the burst function proceeds to state 794 and displays the structure as illustrated by the screen display of Figure 18. Only the attributes selected by the user at the origin end are filled in. A set of four buttons 890, 892, 894, and 896 which correspond to states 796, 798, 800, and 802, respectively, are seen at the bottom of Figure 18.

If the user selects button 890, the burst function moves to state 796 and toggles between displaying the structure and the original database entry with the matching UID. The resultant screen display is illustrated by Figure 20. If the user selects button 892, the burst function moves to state 798 and saves the structure in the shell database as a new entry but gives it a new UID so that it does not save over the original entry. If the user selects button 894, the burst function moves to state 800 and does not save the structure. If the user selects button 896, the burst function moves to state 802 and saves the structure as an entry in the shell database. If the UID already exists in the database, the structure overwrites the original entry. After completion of state 798, 800, or 802, the burst function moves to state 760 and displays the phone module screen as previously illustrated by Figure 15.

If the UID of the structure does not match a UID in the database, i.e., the structure will be a new entry if saved, the burst function proceeds to state 804 and displays the structure as illustrated by the screen display of Figure 19. Only the attributes selected by the user at the origin end are filled in. A set of two buttons 900 and 902 which correspond to states 800 and 802, respectively, are seen at the bottom of Figure 19. States 800, 802, and further states of Figure 13b have been previously described.

While the above detailed description has shown, described and pointed out the fundamental novel features of the invention as applied to various embodiments, it will be understood that various omissions and substitutions and changes in the form and details of the device illustrated may be made by those skilled in the art, without departing from the spirit of the invention.

Claims

WHAT IS CLAIMED IS:

1. In a telephone network, a data burst system, comprising: a first workstation; first means for voice communication across the telephone network; a first interface device connected to the first workstation, the first voice communication means and the telephone network, the first interface device including means for encoding data into DTMF tones and means for decoding DTMF tones into data; a second workstation; second means for voice communication across the telephone network; a second interface device connected to the second workstation, the second voice communication means and the telephone network, the second interface device including means for encoding data into DTMF tones and means for decoding DTMF tones into data; wherein voice communication between the first and second voice communication means and data communication between the first and second workstations can occur during a single telephone connection across the telephone network.

2. In the system defined in Claim 1, a method for transferring unique identification information indicative of an entity, comprising the steps of: calling from the first voice communication means to the second voice communication means; selecting unique identification information stored on one of the workstations; and sending the selected data to the other workstation.

3. The method defined in Claim 2, wherein the unique identification information includes an entity name.

4. The method defined in Claim 3, wherein the entity name is a personal name.

5. The method defined in Claim 2, wherein the unique identification information includes a postal address.

6. The method defined in Claim 2, additionally comprising the steps of: receiving the selected data at the other workstation; and storing the selected data in a database at the other workstation.

7. The system defined in Claim 1, wherein the workstation includes a pointer device.

8. The system defined in Claim 1, wherein the first means for voice communication is a telephone.

9. The system defined in Claim 1, wherein data comprises ASCII data.

10. In a telephone network, a method of communicating data and voice signals between a first and second data burst system, each data burst system having means for voice communication, comprising the steps of: establishing a telephone connection between the first and second systems; communicating voice signals from one system to the other system; translating data in the first system into a set of tones; transmitting the tones from the first system to the second system; and translating the tones at the second system into data.

11. The method defined in Claim 10, wherein each data burst system includes a computer having a processor and a memory.

12. The method defined in Claim 10, wherein each tone comprises a DTMF tone.

13. The method defined in Claim 10, wherein the data comprises identification information indicative of an entity.

14. A data burst system, comprising: means for processing and storing data; means for converting data stored in the processing means into converted data; means for transmitting and receiving signals across a switched telephone network wherein the signals include voice signals and generated signals indicative of the converted data; wherein the voice signals and generated signals are selectively switched in a single telephone connection.

15. The system defined in Claim 14, wherein the means for transmitting and receiving includes means for voice communication.

16. The system defined in Claim 14, wherein the generated signals comprise tones.

17. The system defined in Claim 14, wherein the data includes identification information indicative of an entity.