WO1999035815A1

WO1999035815A1 - Automatic identification of modems

Info

Publication number: WO1999035815A1
Application number: PCT/US1999/000250
Authority: WO
Inventors: Joseph Schober
Original assignee: America Online, Inc.
Priority date: 1998-01-06
Filing date: 1999-01-06
Publication date: 1999-07-15
Also published as: AU2028199A

Abstract

Methods and apparatus implementing a technique for identifying a network device such as a modem using an interactive sequence of commands. A detection application sends one or more commands to a connected modem or other network device where which commands are sent is determined according to the responses received to previous commands. The detection application accesses an identification database including command sequences to identify one or more network devices. The sequence of commands sent to the network device varies, depending upon what type of network device is installed. In general, in one aspect, the technique includes sending a first command to a network device; receiving a response to the first command; if the response does not uniquely identify a type of the network device, selecting a second command according to the response to the first command; and sending the second command to the network device.

Description

AUTOMATIC IDENTIFICATION OF MODEMS

BACKGROUND The invention relates to automatic detection and identification of network devices, such as modems, connected to a computer system

A modem or other network communications device is typically connected to a computer system at a serial port of the computer system. This connection may be internal to the computer system. In order to interact with the modem, the computer system uses a driver defining a command and response set specific to the modem. In order to provide the proper commands and inteφret the responses of the modem, the computer system establishes the type of the modem and selects an appropriate driver. The type can be supplied to the computer system by a user or data file or the computer system can attempt to determine the type of the modem. There is no single standard for establishing the type of a modem at this time, such as a single query to which all modems respond with a unique identifier.

The Windows™ operating system by Microsoft™ provides a facility to determine the type of a modem. Under Windows™, when a modem is initially connected to the computer system, the computer system sends a predefined sequence of commands to the modem and records the responses received from the modem. The sequence of commands does not vary according to the responses received or according to information supplied indicating which modems are supported. Based on these responses, the computer system selects a modem type and corresponding driver. The computer system may confirm the selection with a user. Due to differences amongst conventional modems, different modems may respond to the same sequence of commands in the same way (which would not indicate a unique identification of the modem), may respond differently, or may not respond at all. SUMMARY The invention provides methods and apparatus implementing a technique for identifying a network device such as a modem using an interactive sequence of commands. A computer sends one or more commands to a connected modem or other network device. The computer determines which commands to send according to an identification database and the responses received to previous commands. Accordingly, the sequence of commands sent to the network device varies, depending upon what type of network device is installed.

In general, in one aspect, the technique includes sending a first command to a network device; receiving a response to the first command; if the response does not uniquely identify a type of the network device, selecting a second command according to the response to the first command; and sending the second command to the network device.

The technique of the invention provides one or more of the following advantages. A modem can be identified efficiently and accurately. A modem can be identified with little or no user interaction. When the specific type of a modem is not recognized, the family of the modem can be identified. The databases for identifying modems can use any format of byte patterns for commands and responses. Commands repeated in the databases can be cached for efficient operation. Particular features provided by a modem can be identified in conjunction with identifying the modem.

BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 A shows a prior art computer system including a desktop computer and a modem. FIG. IB shows an operating system and a detection application program which execute on the computer.

FIG. 2 is a flowchart of a process for identifying a modem connected to a computer.

FIG. 3 is a flowchart of a process of building an identification database. FIG. 4 shows a structure of an identification database compiled from a modem database.

FIG. 5 is a flowchart of a process of identifying a modem by traversing an identification database. FIG. 6 is a flowchart of an optional process of identifying attributes of an identified modem.

FIG. 7 is a flowchart of an optional process for determining whether the detection application system configuration supports TCP/IP.

DETAILED DESCRIPTION FIG. 1 A shows a prior art computer system 100 including a desktop computer 105 and a modem 110. The desktop computer 105 can be any kind of computing device which can communicate with a connected network communications device, such as a modem. The illustrated modem 110 is an analog modem, but can alternatively be some other kind of network communications device, such as a terminal adapter or cable modem.

The modem 110 is connected to the computer 105 by a cable 115 inserted into a communications port 120 of the computer 105. The modem 110 is also connected to a network connection 125, such as an analog phone line connected to the public switched telephone network ("PSTN"). The network connection 125 is in turn connected to a computer network 130, such as the Internet or another computer. The modem 110 provides to the computer 105 access to the network 130. In order to use the modem 110 to access the network 130, the computer 105 identifies the modem 110 as described below.

FIG. IB shows an operating system 150 and a detection application program 155 which execute on the computer 105. The detection application 155 interacts with the operating system 150 to determine the hardware configuration of the computer system 100 and to identify the modem 110. The detection application also accesses a modem database 160 and an identification database 165. The modem database 160 includes one or more command sequences for modems supported by the detection application 155. The identification database 165 is a structure of data from the modem database 160 organized to optimize the identification of the modem 110. The databases 160 and 165 can be stored outside of the computer system 100 and accessed across a network connection. The detection application 155 can be divided into separate applications to perform the operations described below, such as a preprocessor application to form the identification database 165 and an identification application to identify the modem 110 using the completed identification database 165. Thus, the identification database 165 can be compiled before executing such an identification application. FIG. 2 is a flowchart of a process 200 for identifying a modem connected to a computer. The process 200 is performed by the detection application. The detection application establishes the number of communications ports, such as by querying the operating system (step 205). The detection application preferably sends a signal to a communications port to determine whether a modem is connected to the port (step 210). The signal is preferably one or more commands which are generally supported by modems at a speed that is generally supported by modems, such as an "AT" command at 9600 bps (bits per second). If the detection application does not receive a valid response to the signal, the detection application records that no operable modem is connected to the current port and checks whether the current port is the last communications port (step 215). If the current port is the last port, the detection application has checked all the available communications ports and the identification process is complete (step 220). If another port is available, the detection application checks the next port for a modem (step 210), as described above. If the detection application receives a valid response to the signal, the detection application records that an operable modem is connected to the current port and optionally determines the fastest communications port speed supported by the modem (step 225). The detection application preferably determines the fastest speed by sending a generally supported command, such as the command sent in step 210, at various data speeds. The detection application records the fastest speed which resulted in a valid response from the modem as the fastest speed of the modem. After establishing the fastest speed of the modem, the detection application identifies the type of the modem (step 230). The detection application sends one or more commands to the modem and checks the modem's responses. The detection application uses the responses of the modem to determine if the modem has been identified and which command to send next by accessing an identification database, as described below. The identification database is compiled from a modem database which includes command sequences to identify various modems uniquely. If the detection application fails to identify the modem, the detection application records that the modem connected to the current port is not identifiable and checks whether the current port is the last communications port (step 215), as described above. If the detection application successfully identifies the modem, the detection application optionally identifies attributes of the modem (step 235). Attributes to identify include telephone line connection and touch-tone support, as described below.

After identifying the modem and optionally identifying attributes of the modem, the detection application checks whether the current port is the last communications port (step 215) to check any remaining ports, as described above. Once the detection application has checked all the communications ports, the detection application has identified all of the available modems which the detection application can identify. FIG. 3 is a flowchart of one process 300 for building an identification database. A sequence of commands which uniquely identify a particular type of modem are entered into a modem database, and associated with the type of modem (step 305). These commands can be determined empirically or supplied by a manufacturer of the type of modem. Each sequence includes at least one command. At least one sequence is entered for each type of modem which is able to be identified with the identification database. A sequence can also identify a set of related modems, or a "family" of modems. For example, "Practical Peripherals PM288MTII" can be a specific type of modem and "Practical Peripherals Modem" can be a family type when more specific identification information is unavailable. Commands and responses can be in any format of byte patterns recognized by a modem in the modem database. One format uses ASCII commands and responses, such as "ATM". These ATI commands are commonly used by modem manufacturers. Additional examples of commands include "ATE1QV1" and "AT&K3&Q5". After all the command sequences have been entered into the modem database, the modem database is preferably compiled into a tree structure to form the identification database (step 310). To form the identification database, the detection application parses the modem database and gathers common sequences together. For example, two sequences which differ only at the last command can be represented by a common sequence up to that branching point. The gathered sequences can be prioritized so that the first command sent excludes or qualifies the largest subset of modems in the database. This prioritization can be accomplished by recording the number of occurrences of command sequences in the modem database. The sequences can also be prioritized so that more common modem types will be checked for first. Commands which are unnecessary for unique identification can also be removed from the sequences.

Table 1 shows an example of the contents of a modem database. A modem type is indicated by "[]", such as "[modem-A]" for the modem type "modem- A". A command to be sent to the modem is indicated by "Cmd". A response to a command for the type of modem is indicated by "Resp". For example, "resp-A" is a valid response to the command "ATI3^ΛM" for a modem-A type modem, "modem- fam" is a type of a family of modems. "modem-C" is a type of modem-fam modem. TABLE 1

[modem-A]

Cmd = ATI3^ΛM Resp = resp-A

Cmd = ATI4^ΛM Resp = resp-B

[modem-B]

Cmd = ATI3^ΛM Resp = resp-A

Cmd = ATI5^ΛM Resp = resp-C

Cmd = ATI6^ΛM Resp = resp-D

[modem-fam]

Cmd = ATI3^ΛM Resp = resp-A

Cmd = ATI5^ΛM Resp = resp-C [modem-C]

Cmd = ATI3^ΛM Resp = resp-A

Cmd = ATI5^ΛM Resp = resp-C

Cmd = ATIl^ΛM Resp = resp-E

[modem-D]

Cmd = ATI4^AM Resp = resp-F

FIG. 4 shows a structure 400 of an identification database compiled from the modem database information shown in Table 1. The identification database can be implemented as a collection of linked objects. The structure 400 includes nodes 405, 410, 415, 420, 425, 430, 435, 440, 445, 450 and arrows 407, 409, 412, 414, 422, 424, 427, 429, 437, 447, 449. Nodes represent data, such as objects, and arrows represent links between data, such as pointers. Nodes are organized in levels. For example, nodes 405 and 445 are at the topmost level and node 410 is on a lower level. The detection application traverses the structure 400 following the arrows between nodes to identify the modem. Node 405 is at the top or root of the structure, labeled "ROOT" in FIG. 4. Traversal begins with the root node 405.

The data for a node preferably includes a command field and a modem field. The command field indicates a command to send to the modem or is empty, such as a NIL value. The modem field indicates a type of modem or family of modems or is empty. In FIG. 4, the command and modem fields are represented by "Cmd=" and "Modem=", respectively. For example, node 405 has a command field indicating an ATI3^ΛM command and an empty (NIL) modem field.

The data for a node also includes zero or more pointers, represented by arrows in FIG. 4. Downward arrows, such as arrows 407 and 447, represent pointers which are associated with recognized responses received from the modem to the command of the command field of the node and indicate which node is next upon receiving the corresponding response. These responses are the valid responses to the command at this node in the identification database. For example, arrow 407 indicates that when the detection application receives a response of resp-A to the command ATI3^ΛM at node 405, the next node is node 410. These downward arrows lead the detection application to a lower level in structure 400.

Sideways arrows, such as arrows 409 and 414, represent pointers indicating which node is next when a recognized response to the node's command was not received from the modem. For example, arrow 409 indicates that when the detection application does not receive a recognized response to the command ATI3^ΛM at node 405 (i.e., any response other than resp-A), the next node is node 445. These sideways arrows lead the detection application to another node at the same level as the current node. An upward arrow returns the detection application to a previously visited node at an upper level, such as arrow 424 from node 420 to node 405. An upward arrow can be implemented in various ways, such as a pointer, a state variable of the detection application, or using a stack. For example, when the data for a node does not include a pointer to a next node on the same level, or such a pointer is empty (NIL), the detection application can return to the node most recently visited at an upper level, such as by storing nodes in a stack. Thus, because node 420 does not indicate another node at the same level, when an unrecognized response is received for the command of node 420, the detection application returns to node 405, represented by arrow 424. Node 420 can include a pointer to node 405 or can indicate this transition by not including a pointer to another node on the same level. When the command field is empty, the modem field indicates a type of modem or family of modems. When the detection application traverses the structure 400 and reaches a node which has an empty command field, the detection application records the type indicated by the modem field as the type of the modem being identified. For example, node 415 has an empty command field and a modem field indicating the modem is a modem-A type modem. A node with an empty command field does not have outgoing arrows.

When the command field indicates a command and the modem field indicates a modem type, the node preferably identifies a type of a family of modems. For example, node 435 has a command field indicating a command of ATI1^AM and a modem field indicating the modem is a modem-fam type modem. Outgoing arrows from such a node indicate a sub-tree to more specifically identify the modem, if the specific type is recognized. For example, a modem-C type modem is a member of the modem-fam family of modems. The modem-fam family may include other types of modems as well. If a modem is identified as a modem-fam modem but the modem is not a modem-C modem, the detection application records the type of the modem as modem-fam. A node identifying a family of modems preferably does not have sideways or upward arrows. For example, when the detection application does not receive a recognized response to the ATI1^ΛM command at node 435, the detection application records modem-fam as the type of the modem.

In FIG. 4, structure 400 includes a failure node 455. Failure node 455 represents a failure to identify the modem. Failure node 455 can be implemented as a type of node or can be implemented as part of the detection application. When the detection application does not receive a recognized response to the command for the last node at the top level of the identification database structure, the detection application records that the identification failed. The detection application can recognize this failure when the current node does not indicate a next node at the same level and the current node is at the topmost level, such as node 445. Failure can be avoided by including a very generic command sequence to which most modems are able to respond, allowing the detection application to identify the modem as a generic modem.

FIG. 5 is a flowchart of a process 500 of identifying a modem by traversing an identification database. The detection application retrieves from the identification database a first command and sends the first command in the identification database to the modem (step 505). The first command is from the command field of the root node in the identification database structure, node 405 in FIG. 4. The detection application preferably keeps track of the current level in the structure.

The detection application checks the response received from the modem by comparing the response to responses indicated in the identification database for the current node (step 510). If the response matches a valid response to the command, the detection application accesses a next node indicated by the valid response and checks whether the next node identifies a modem (step 515). As described above, a node identifies a modem when the command field is empty and the modem field indicates a modem type, such as node 415 in FIG. 4. If the next node identifies a modem, the detection application has successfully identified the modem (step 520). The detection application can optionally confirm the identification with the user. If the next node does not identify a modem, the detection application retrieves from the identification database a command indicated by the command field of the next node (step 525). The detection application sends this command to the modem (step 505) and the process continues.

The detection application can be configured to cache commands and responses. Hence, the detection application can recognize that the retrieved command is the same as a command previously sent to the modem. In this case, rather than re- sending the same command, the detection application uses the response received from the modem when the command was originally sent.

If the response received from the modem does not match a valid response, the detection application checks whether the current node indicates a next node for unrecognized responses at the same level, such as with a pointer (step 530). In FIG. 4, these pointers are represented by sideways arrows, such as arrow 409 and arrow 414. Node 435 does not have an arrow for an unrecognized response. As described above, FAIL node 455 is not necessarily an actual node in structure 400, and so node 445 also does not indicate a next node. If the current node indicates a next node, the detection application retrieves a command indicated by the command field of the next node (step 525). The detection application sends this command to the modem (step 505) and the process continues.

If the current node does not indicate a next node at the same level, the detection application checks whether the current node identifies a family of modems (step 535). As described above, a node which identifies a family of modems has a command in the command field and a type of a modem family in the modem field, such as node 435 in FIG. 4. Thus, the detection application can check for a modem family by checking the modem field of the node. If the current node identifies a modem family, the detection application records the modem family as the type of the modem (step 540).

If the current node does not identify a modem family, the detection application checks whether there is an available next node at an upper level from the current node (step 545). As described above, a link to a node at an upper level can be implemented in various ways. If a next upper node is available, the detection application checks whether the upper node indicates a next node at the same level as the upper node (step 530) and the process continues.

If there is no upper node available, the detection application records that the identification has failed (step 550). Identification failure occurs when the modem cannot be identified by any of the command sequences supplied in the modem database. As described above, failure can be indicated in the identification database by an explicit failure node. Alternatively, the detection application can recognize when the modem has not responded successfully. For example, in traversing the identification database represented by the structure 400 shown in FIG. 4, if the modem has not supplied recognized responses to the ATI3^ΛM and ATI4^ΛM commands from nodes 405 and 445, respectively, the detection application recognizes that the modem is not responding to the available command sequences.

The detection application continues to issue commands and check responses, as described above, until the detection application identifies the modem, step 520 or 540, or identification fails, step 550.

For example, in applying the process 500 shown in FIG. 5 A using the identification database shown in FIG. 4 where the connected modem is modem-A modem, the detection application first sends a "ATI3^ΛM" command, indicated by the command field of root node 405. The detection application then checks the response received from the modem. Because the modem is a modem-A modem, the detection application receives a resp-A response to the ATI3^ΛM command. The detection application follows arrow 407 to node 410. The command field of node 410 is not empty, so node 410 does not identify a modem. The detection application retrieves an ATI4^ΛM command from the command field of node 410 and sends the command to the modem. The detection application receives a resp-B response and follows arrow 412 to node 415. The command field of node 415 is empty and the modem field indicates the type modem-A. The detection application recognizes that node 415 identifies the modem as a modem-A modem. The detection application has successfully identified the modem. In another example where the modem is a modem of the modem-fam family of modems, but is not a modem-C modem, the detection application starts at root node 405 and sends the ATI3^ΛM command to the modem. The detection application receives a resp-A response and follows arrow 407 to node 410. Node 410 does not identify a modem, so the detection application retrieves the ATI4^ΛM command from node 410 and sends the command to the modem. The modem may or may not respond to the command, but does not respond with a resp-A response. Because the detection application does not receive a valid response to the ATI4^ΛM command, the detection application checks for a next node at the same level as node 410. Node 410 has arrow 414 indicating node 420 at the same level (i.e., the data for node 410 has a valid pointer to the data for node 420). The detection application follows arrow 414 to node 420. The detection application retrieves the ATI5^ΛM command and sends the command to the modem. The detection application receives a resp-C to the modem and follows arrow 422 to node 425. Node 425 does not identify a modem, so the detection application retrieves the ATI6^AM command and sends the command to the modem. The detection application does not receive a valid response. The detection application checks for a next node at the same level and follows arrow 429 to node 435. The detection application retrieves the ATI1^ΛM command and sends the command to the modem. The modem does not send a valid response because the modem is not modem-C modem. When the detection application checks for a next node at the same level as node 435, the detection application finds no next node. The detection application then checks whether node 435 identifies a family of modems. Both the command and modem fields of node 435 are not empty and so node 435 identifies a family of modems. The detection application retrieves the modem-fam type from the modem field and identifies the type of the modem as the family modem-fam.

In another example where the modem is of a type not in the modem database, but related to the modem-A type, the detection application starts at root node 405 and sends the ATI3^ΛM command to the modem. Because the modem is related to modem-A modems, the detection application receives a resp-A response and follows arrow 407 to node 410. Node 410 does not identify a modem, so the detection application retrieves the ATI4^AM command from node 410 and sends the command to the modem. The detection application does not receive a valid response to the ATI4^ΛM command, so the detection application checks for a next node at the same level and follows arrow 414 to node 420. The detection application retrieves the ATI5^ΛM command and sends the command to the modem. The detection application does not receive a valid response to the ATI5^ΛM command, so the detection application checks for a next node at the same level. Node 420 does not indicate a next node at the same level, so the detection application checks whether node 420 identifies a family of modems. The modem field of node 420 is empty, so node 420 does not identify a family of modems. The detection application checks for an available next upper node from node 420. As represented by arrow 424, node 405 is an available upper node from node 420. The detection application follows arrow 424 to node 405. The detection application checks whether node 405 indicates a next node at the same level. Node 405 indicates node 445 as a next node and the detection application follows arrow 409 to node 445. The detection application retrieves the ATI4^ΛM command from node 410. The detection application recognizes that the ATI4^ΛM command was previously sent to the modem. The detection application uses the previous response, resp-A, as the received response at node 445. Resp-A is not a valid response at node 445, and so the detection application checks for a next node at the same level. Node 445 does not indicate a next node at the same level so the detection application checks whether node 445 identifies a family of modems. The modem field of node 445 is empty so the detection application checks for an available upper node from node 445. There is no available upper node from node 445, represented by arrow 449 and FAIL node 455. The detection application records that the identification failed.

FIG. 6 is a flowchart of an optional process 600 of identifying attributes of an identified modem. This process is preferably implemented using databases pairing commands and responses similar to the modem database and identification database described above. As a result, the details of which attributes are detected, and the process required to detect them, can be determined by these databases.

The detection application checks whether the modem is connected to a telephone line (step 605). The detection application can perform this check by sending an "ATM0X4D;^ΛM" command to the modem and receiving an "OK" response. If the modem is connected to a telephone line, the detection application checks whether the telephone line is a touch tone line (step 610). To check for a touch tone line, the detection application can cause the modem to dial a 5 using a touch tone signal two times, with an intermediate pause. If the modem reports "NO DIALTONE", the detection application assumes the telephone line is touch tone. If not, either the telephone line is not touch tone, or the modem does not support this test and the detection application cannot determine whether the telephone line is touch tone. If the detection application does not determine that the telephone line is touch tone, the detection application ends attribute identification (step 615).

If the detection application determines that the telephone line is touch tone, the detection application checks whether an initial "9" is required when dialing on this telephone line for external access (step 620). To check, the detection application causes the modem to dial a 9 using a touch tone signal. After a pause, the detection application causes the modem to dial a desired telephone number. If the modem does not report "NO DIALTONE", the detection application assumes an initial 9 is required.

If the detection application determines that the telephone line is touch tone, the detection application checks whether an initial "*70" key sequence can be dialed before a desired telephone number (step 625). An initial *70 sequence is typically used to disable a "call-waiting" feature of telephone service. To check, the detection application causes the modem to dial *70 using a touch tone signal. After a pause, the detection application causes the modem to dial a desired telephone number. If the modem does not report "NO DIALTONE", the detection application assumes an initial *70 is acceptable.

After checking for *70, the detection application has finished attribute identification (step 615). In alternative implementations, different combinations of or additional attributes can be checked, such as by using information contained in the identification or modem database.

FIG. 7 is a flowchart of an optional process 700 for determining whether the computer system configuration supports TCP/IP. This process also can be implemented using databases pairing commands and responses similar to the modem database and identification database described above for identifying TCP/IP support as well as network devices. The detection application checks whether an appropriate TCP/IP support library or libraries is available (step 705). Which library or libraries are necessary for TCP/IP support depends upon the system configuration. For example, under Windows™, the detection application checks for a winsock library. The detection application searches in path directories of the operating system to find the TCP/IP support libraries. If the detection application does not find the TCP/IP support libraries, the detection application records that TCP/IP is not supported (step 710). If the detection application finds the TCP/IP support libraries, the detection application checks for hardware support (step 715). The detection application searches a hardware registry maintained by the operating system to determine whether a hardware adapter supporting TCP has been added to the detection application system. If the detection application does not find hardware support, the detection application records that TCP/IP is not supported (step 710). If the detection application finds hardware support, the detection application records that TCP/IP is supported.

As described above, a modem is a hardware device connected to a detection application system that permits the detection application to communication with other computers across public data networks, such as the PSTN. A modem can be an analog modem which connects to a standard telephone line. Other network communications devices which can be used in place of a modem within the technique of the invention include ISDN adapters, network cards, cable modems, and other devices that can inteφret a data stream containing commands and return responses to those commands. To check for multiple types of devices, a single application can check for all known devices. The application can be modified by "plug-in" software components or corresponding independent software tools can be used.

The invention may be implemented in hardware or software, or a combination of both. However, preferably, the invention is implemented by means of a computer program executing on one or more programmable systems each comprising at least one processor, a data storage system (including volatile and non-volatile memory and/or storage elements), at least one input device, and at least one output device. Program code is applied to input data to perform the functions described herein and generate output information. The output information is applied to one or more output devices, in known fashion. The processor may be, for example, a digital signal processor (DSP). Each program is preferably implemented in a high level procedural or object oriented programming language to communicate with a computer system. However, the programs can be implemented in assembly or machine language, if desired. In any case, the language may be a compiled or inteφreted language. Each such computer program is preferably stored on a storage media or device

(e.g., ROM or magnetic diskette) readable by a general or special pwpose programmable computer, for configuring and operating the computer when the storage media or device is read by the computer to perform the procedures described herein. The inventive system may also be considered to be implemented as a computer-readable storage medium, configured with a computer program, where the storage medium so configured causes a computer to operate in a specific and predefined manner to perform the functions described herein.

Various implementations of the invention have been described. Additional variations are possible. For example, in the processes described above, non-order dependent steps can be performed in different sequences. Alternative sequences of checking for links to other nodes are possible. The detection application can attempt to identify a modem at a port without first checking for an operable modem. The modem and the communications port can be a single physical entity. The identification database can be organized in various ways, such as a table with linked entries. Numerous arrangements of nodes and links can be formed from the command sequences supplied in the modem database. Some modems can indicate a maximum speed in response to a particular command and so the detection application can directly query the modem for a maximum speed. The modem database and identification database can be constructed separately. The modem database can also be a collection of data files, such as one file for each modem type. The detection application can be a single application or a group of applications. A pre-processing software application can be used to form the identification database from the modem database. The modem identification can be performed by an identification application or tool with access to the identification database. The process which identifies the modem can originate from the operating system or from a separate application program or agent. Additional databases can be supplied and compiled to identify various devices connected to the computer as well as attributes of those devices.

Claims

CLAIMSWhat is claimed is:

1. A method of identifying a network device connected to a computer system, the method comprising: (a) sending a first command to a network device;

(b) receiving a response to the first command;

(c) if the response does not uniquely identify a type of the network device, selecting a second command according to the response to the first command; and (d) sending the second command to the network device.

2. The method of claim 1 , where the first command and second command are selected from an identification database which is formed by combining a plurality of command sequences to identify a corresponding plurality of types of network devices.

3. The method of claim 1 , where the network device is a modem.

4. The method of claim 1 , further comprising continuing to send commands to the network device until a response uniquely identifies the network device as a type.

5. The method of claim 4, further comprising requesting a user to confirm the type.

6. The method of claim 4, where the type indicates a group of related types of network devices.

7. The method of claim 1 , further comprising:

(a) reading a plurality of command sequences, where each command sequence includes a sequence of one or more pairs of commands and responses and identifies a corresponding network device; and (b) combining the plurality of command sequences into a tree having at least one node and at least one leaf, where each leaf of the tree identifies a network device.

8. The method of claim 7, where at least one node identifies a group of related network devices.

9. The method of claim 7, where combining the plurality of command sequences into a tree comprises:

(a) combining similar commands into common nodes;

(b) eliminating nodes which are not necessary to identify a network device uniquely; and

(c) prioritizing nodes so that certain network devices can be identified more quickly than other network devices in the tree.

10. The method of claim 1 , further comprising identifying one or more attributes of the network device.

11. The method of claim 10, where one attribute is telephone line status.

12. The method of claim 10, where one attribute is support for TCP/IP.

13. The method of claim 10, where identifying one or more attributes of the network device includes using an attribute identification database formed from one or more sequences of one or more pairs of commands and responses.

14. The method of claim 10, further comprising checking whether the network device is connected to a telephone line.

15. The method of claim 10, further comprising checking whether a telephone line connected to the network device is a touch tone telephone line.

16. The method of claim 10, further comprising checking whether an external access key sequence can be dialed before a desired telephone number.

17. The method of claim 10, further comprising checking whether a disabling key sequence can be dialed before a desired telephone number to disable one or more telephone services.

18. The method of claim 10 , further comprising :

(a) checking whether the network device is connected to a telephone line;

(b) if the network device is connected to a telephone line, checking whether the telephone line is a touch tone telephone line;

(c) if the telephone line is a touch tone telephone line, checking whether an initial 9 can be dialed before a desired telephone number; and

(d) if the telephone line is a touch tone telephone line, checking whether an initial *70 can be dialed before a desired telephone number.

19. A method of identifying a network device connected to a computer system, the method comprising sending a series of commands to a network device, where a next command is selected according to a response to a previous command in order to identify the network device uniquely, so that different network devices which return different responses cause different series of commands to be sent.

20. A method of identifying a network device connected to a computer system, the method comprising:

(a) retrieving a command from a command sequence in an identification database; (b) sending the command to a network device;

(c) receiving from the network device a response to the command;

(d) if the response is a valid response, checking whether the command is a last command in the command sequence;

(e) if the command is the last command in the command sequence, identifying the network device;

(f) if the command is not the last command in the command sequence, retrieving a next command in the command sequence from the identification database;

(g) if the response is not a valid response, checking whether a next command is available;

(h) if a next command is available, retrieving a next command in the command sequence from the identification database; (i) if a next command is not available, checking whether a generic type has been identified; (j) if a generic type has been identified, identifying the network device;

(k) if a generic type has not been identified, checking whether identification of the network device has failed; (1) if identification of the network device has failed, ending identification; (m) if identification of the network device has not failed, retrieving a next command in the command sequence from the identification database; and (n) repeating steps (b) through (n) until identifying the network device or ending identification.

21. The method of claim 20, wherein the network device is a modem.

22. A system for identifying a network device connected to a computer system, the system comprising:

(a) means for sending a first command to a network device;

(b) means for receiving a response to the first command; (c) means for selecting a second command according to the response to the first command if the response does not uniquely identify a type of the network device; and (d) means for sending the second command to the network device.

23. A computer program stored on a computer-readable medium, for identifying a network device connected to a computer system, the computer program including instructions operable to cause a computer to:

(a) send a first command to a network device;

(b) receive a response to the first command;

(c) select a second command according to the response to the first command if the response does not uniquely identify a type of the network device; and

(d) send the second command to the network device.

24. A computer program stored on a computer-readable medium, for forming a database for identifying a network device connected to a computer system, the computer program including instructions operable to cause a computer to:

(a) read a plurality of command sequences, where each command sequence includes a sequence of one or more pairs of commands and responses and identifies a corresponding network device; and

(b) combine the plurality of command sequences into a tree having at least one node and at least one leaf, where each leaf of the tree identifies a network device.

25. The computer program of claim 24, where the instructions for causing the computer to combine the plurality of command sequences into a tree include instructions for causing the computer to:

(a) combine similar commands into common nodes;

(b) eliminate nodes which are not necessary to identify a network device uniquely; and

(c) prioritize nodes so that certain network devices can be identified more quickly than other network devices in the tree.