Registers – Coded record sensors – Particular sensor structure
Reexamination Certificate
2000-07-12
2003-04-01
Tremblay, Mark (Department: 2876)
Registers
Coded record sensors
Particular sensor structure
Reexamination Certificate
active
06540144
ABSTRACT:
FIELD OF THE INVENTION
The invention relates generally to bar code scanners, and more specifically, to techniques for interfacing bar code scanners with computers.
BACKGROUND OF THE INVENTION
For years, various bar code scanner manufacturers have been selling keyboard-wedge bar code scanners. With reference to
FIG. 1
, bar code scanner
108
is connected to a personal computer (PC)
100
keyboard controller port
104
and a computer keyboard
110
in an Y or wedge type configuration. Bar code scanner
108
may contain an on-board processor
109
. PC
100
also contains a processor
101
. The Y or wedge type configuration is implemented using interconnection cable
106
such that computer keyboard
110
and bar code scanner
108
are placed in parallel across controller port
104
. This parallel configuration is used because keyboard controller
102
circuitry within presently-existing PCs (personal computers)
100
and laptop computers attempts to detect the existence of a computer keyboard
110
connected to the keyboard controller port
104
. The controller port
104
needs to be connected to a computer keyboard
110
, even if the keyboard is not to be used for subsequent data entry, and even if the controller port
104
is also connected to an input device other than a computer keyboard. If the keyboard controller
102
circuitry does not detect a keyboard connected to the controller port
104
, the PC
100
and/or laptop may then disable the port, preventing any further inputting of data. In the operational environment of
FIG. 1
, this disablement poses a problem, because we desire to input further data as bar codes are detected and decoded.
With the increasing use of laptop computers and keyless data entry, the keyboard controller port shows great potential as a convenient, somewhat standardized, and readily available data input channel. However, this potential could be advantageously exploited only if it were possible to find some way around the necessity of connecting this port to an actual computer keyboard. By way of clarification, there are a number of existing programs that do not require the use of a computer keyboard per se, but these programs have neglected to provide mechanisms by which a computer keyboard is emulated, so as to prevent the controller port from being disabled.
Assume that a conventional keyboard wedge bar code scanner is connected to a keyboard controller port of a PC or laptop, as shown in
FIG. 1
, while, at the same time, the keyboard that is connected in the parallel (Y) configuration is eliminated. Will the hardware configuration of
FIG. 1
still function as desired? It is important to realize that keyboard-to-PC communications is implemented by means of a 2-way channel. Other types of data must be communicated between the PC and the keyboard in addition to information specifying the key or keys that were pressed. When a PC is powered up, the PC is programmed to check for the existence of a primary data input device, which is typically a keyboard. The PC begins a data exchange with the keyboard, and this communication is called “power-on diagnostics”. If the keyboard is not present, or if the power-on diagnostics fail, the PC will not boot up. Accordingly, if a normal boot-up is desired, the keyboard shown in
FIG. 1
should not be eliminated. In the case of laptop computers, a similar situation exists. A communication protocol is used to sense the presence of an external keyboard that is connected to the laptop's external keyboard port. If the laptop computer fails to detect a keyboard at the external keyboard port, then the laptop computer may disable its external keyboard port.
Even if a technique were to be developed by which a bar code scanner could successfully emulate a computer keyboard, another problem would then arise. Eleven (11)-bit transmission protocols are utilized almost universally to provide keyboard to PC data transfer. The transmission protocol begins with a Start bit (low), followed by 8 data bits, a Parity bit (odd parity) and finally a Stop bit (high). In the context of a computer keyboard, these 8 data bits are used to represent one or more scan codes corresponding to keyboard key presses. However, in the operational environment of
FIG. 2
, these data bits can be employed to represent all or part of a detected bar code. Irrespective of whether these 8 bits represent actual key presses or bar codes, the aforementioned transmission protocol remains unchanged. The protocol allows the PC (or laptop) to interrupt the transmitted sequence up through the 9
th
bit. Since the 9
th
bit can be used to represent all or part of a scan code, the PC will prevent the communication of a scan code if the PC sends out a keyboard port inhibit any time before the 9
th
bit is received by the port. If the scan code represents all or part of a decoded bar code, upon issuance of a keyboard controller port interrupt, the PC will prevent the successful receipt of this bar code at the keyboard controller port.
The aforementioned keyboard inhibit problem is described in greater detail in a reference book entitled, “PC KEYBOARD DESIGN”, by J. Konzak, and published by Annabook. In the configuration of
FIG. 1
, the inhibit problem could cause decoded bar code data to be lost, ignored, corrupted, or misread once the PC or laptop interrupts communication. With the advent of multitasking operating systems, sophisticated network operating systems, and dual-keyboard port laptops and PC's, the problem worsens. Some of these operating systems interrupt keyboard port communications on a frequent and periodic basis, such as once every ten milliseconds. Of course, in operational environments where the keyboard controller port is not used with an auxiliary input devices, the computer keyboard will sense this stoppage of communications and retransmit the scan code after the PC releases its halt or inhibit of the keyboard. Existing bar code scanners are not so equipped. If a data transmission from a bar code scanner is interrupted, the scanner has no mechanism by which to ascertain whether or not a data entry error has occurred.
Pursuant to prior art techniques, bar code scanners had not monitored the inhibit signal because the decoded bar codes were wedged into the transmitted data for brief periods of time, relative to typed-in keyboard data. Also, as a practical matter, the keyboard BIOS virtually never inhibits the keyboard during scan code transmission. Any problems that may have been encountered were handled by changing certain programmable parameters such as inter-character delays or inter-scan-code delays.
SUMMARY OF THE INVENTION
A bar code scanner is equipped with a keyboard emulation mechanism so as to provide an enhanced interface to a keyboard controller port of a computing device such as a personal or laptop computer. The keyboard emulation mechanism eliminates the necessity of connecting an actual computer keyboard to the port by responding to the computing device's standard power-on diagnostic procedure as if it were effectively an electrical equivalent of a computer keyboard.
Pursuant to a further embodiment of the invention, the keyboard emulation mechanism is equipped to detect a keyboard inhibit signal at the keyboard controller port. This inhibit signal may be generated by the computing device. If the keyboard emulation mechanism detects a keyboard inhibit signal while a data byte is being transmitted to the keyboard controller port, the keyboard emulation mechanism stops transmitting the data byte, waits for the inhibit signal to cease, and then retransmits the data byte to the keyboard controller port. This retransmission process is repeated up to a specified number of times, so as to provide additional opportunities for the data byte to be inputted to the keyboard controller port if the port is momentarily disabled by the keyboard inhibit signal. For many applications, it is advantageous to repeat the retransmission process up to three times for a given data byte. If the data byte is still not successfully re
Furlong John A.
Hudrick Donald T.
Scott Ian A.
Metrologic Instruments Inc.
Morgan & Lewis & Bockius, LLP
Tremblay Mark
LandOfFree
Techniques for interfacing a bar code scanner to a PC using... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Techniques for interfacing a bar code scanner to a PC using..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Techniques for interfacing a bar code scanner to a PC using... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3043750