Electrical computers and digital data processing systems: input/ – Input/output data processing – Peripheral monitoring
Reexamination Certificate
1998-10-28
2001-08-28
Lee, Thomas (Department: 2182)
Electrical computers and digital data processing systems: input/
Input/output data processing
Peripheral monitoring
C710S002000, C710S037000, C710S120000, C710S108000, C709S241000
Reexamination Certificate
active
06282586
ABSTRACT:
BACKGROUND OF THE INVENTION
1. The Field of the Invention
The present invention relates generally to interfacing communication applications with hardware devices in a computer operating system. More specifically, the present invention relates to interfacing a standard single port communication application to multiple ports without requiring modification to the single port communication application.
2. The Relevant Technology
Typical computer software applications that interface with external hardware devices such as modems, printers, wireless transceivers, as well as other imaginable devices heretofore have been explicitly programmed to interface via a single interface port from the communication application to the target hardware device via an operating system. Many such communication applications have proliferated and have become uniquely successful in their target markets. To appreciate the advances of the present invention, it is necessary to understand how port devices are supported under modern commonplace operating systems. In the present description, an exemplary operating system, such as the Microsoft® Windows '95® and Windows '98® operating systems are discussed. These exemplary operating systems, among others, provide support for communications hardware through the architecture described in FIG.
1
. In
FIG. 1
, the dotted line depicted as boundary
106
represents a protection interface provided by the operating system in conjunction with the microprocessor of the computing platform. Those familiar with the art of structured programming appreciate that applications and higher level drivers operate in the ring
3
area
114
, while the operating system and lower level device drivers execute in ring
0
area
116
. A communication application
100
provides control of a hardware device
112
through an application programming interface (API) which, in the exemplary operating system, consists of a 16 or a 32-bit application function call through the Wirlbox Win32 APIs of the Microsoft operating system. Functions performed through the API include configuring the device, reading data from the device or writing data to the device. Such API function calls
118
are handled by a software component, COMM.DRV
104
which, in
FIG. 1
, is depicted as a ring
3
device driver.
COMM.DRV device driver
104
passes the application function calls through the ring
3
/ring
0
boundary
106
interface to another software module resident within the operating system known as VCOMM
108
using a VCOMM API
120
. VCOMM
108
is a ring
0
device driver that manages all port drivers registered in the operating system. Among other things, VCOMM
108
manages the loading and unloading of port drivers, determines which port driver should handle function calls received through VCOMM API
120
and passes function calls to the appropriate driver for completion of the procedure.
A port driver
110
thereafter handles the details of completing function calls received from VCOMM
108
for a specific hardware device. In the present exemplary operating system (e.g., Windows '95 and Windows '98) such operating systems include port drivers for devices that communicate through serial ports (e.g., SERIAL.VXD) and parallel ports (e.g., LPT.VXD). For hardware devices
112
that deviate from such hardware interfaces, a compatible port driver must be developed and registered with the operating system for interfacing between VCOMM
108
and hardware
112
.
While most communication applications have heretofore communicated directly with a single identified hardware device via a specific compatible port driver, technological advances have enabled communication data to be delivered to and propagated over various hardware configurations that may, for among various reasons, present a preferable hardware medium. For example, traditional computer-to-computer communications have taken place via hardware devices known as modems. A data-generating communication application originates data which is passed down through a device driver and ultimately a modem-compatible port driver for propagation across a physical medium such as a telephone line to a symmetrical receiving computer architecture. While the telephone line conduit provides a preferred interconnection in one case, other interconnection techniques may also provide a favorable channel in other applications. For example, in contrast to a modem operating as the hardware device for communicating over the telephone line, a wireless transceiver having internal modulation capabilities may also be employed for a wireless hardware device application. In such a configuration, a separate port driver compatible with the interactive interface of the wireless transceiver must be substituted for the modem-compatible port driver forming the above-described communication channel.
For such a wireless transceiver configuration, the communication application must be customized to interface with a wireless port driver. Such a menu of hardware devices requires that established communication applications be rewritten at great expense to accommodate each additionally discovered hardware device.
It would represent an advancement in the art to provide a method and system for interfacing a software communication application having a single port interface with a plurality of hardware devices without requiring the modification of the port interface of the communication application. It would further represent an advancement in the art to provide a method and system for enabling a user of a communication application to interact with the communication application in a consistent manner while relying upon the sophistication of the operating system and its associated components and drivers to carry out the requested data exchange over at least one of a plurality of hardware devices without requiring any modifications to the communication application or additional attention by the communication application user.
SUMMARY AND OBJECTS OF THE INVENTION
The present invention relates to a method for alternatively employing one of a plurality of port drivers without requiring the redevelopment of a communication application which traditionally has a single port interface. According to the invention, the inventive architecture employs an intermediate device driver, herein known as a port driver router, which is designated and registered as the port driver for the communication application. When the communication application requests that a port be opened, the designated port driver, the port driver router responds accordingly. In the present invention, the port driver router interfaces with the present hardware structure to determine which one of a possible plurality of hardware devices should be employed in the present port session. The port driver router thereafter makes a determination of which port driver, herein known as the real port driver, should be employed to properly interact with the selected hardware device.
Once the port driver router has determined which port driver should be employed for communicating with the hardware, the port driver router issues a request to the operating system to redirect or hook particular device service requests for servicing the port driver router. The port driver, thereafter acting as or similar to the VCOMM service, requests that the real port driver open a port. The real port driver responding accordingly, returns a port handle pointing to a port information structure comprised of a plurality of pointers to functions including the port close function of the real port driver.
The port driver router then acting in a broker-like manner, modifies the port information structure of the real port driver to include a pointer to the port close function of the port driver router rather than the real port driver. Consistent with the open port process, the port driver router returns a port handle to the requesting VCOMM service. However, rather than returning a port handle to the port driver router's port information structure, the port driv
3Com Corporation
Elamin Abdelmoniem
Lee Thomas
Workman & Nydegger & Seeley
LandOfFree
Method in an operating system, a method and system for... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method in an operating system, a method and system for..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method in an operating system, a method and system for... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2517639