Patent Application
20070174499
The present invention relates generally to systems and methods for configuring electronic devices.
When a peripheral device is coupled to a host device, the peripheral device will utilize a predetermined communication protocol to interface with the host device. However, the protocol may not support configuration of the peripheral device either directly with predefined commands or indirectly with encapsulated commands in the protocol. For example, the protocol may not be capable of transmitting configuration data to the peripheral device. To establish a communication link between the peripheral device and the host device which provides for transmission of the configuration data, the peripheral device must switch communication protocols. This is conventionally done manually. For example, a scanner coupled to a computer would have to scan one or more bar codes to switch to establish the communication link and then scan one or more further bar codes to obtain the configuration data.
The peripheral device is typically manually configured with settings input by an installer. Attempts by untrained personnel to accomplish hardware and software installation of the peripheral device may result in wasted time, un-needed repair requests when the peripheral device is working properly but has been installed incorrectly, etc. Costs are also incurred when outside personnel (e.g., IT staff) are contracted to install, configure and troubleshoot the peripheral devices.
The present invention relates to a system and method for configuring an electronic device. The method comprises detecting a coupling of a peripheral device to a host device. A first protocol utilized by the peripheral device is identified. An instruction is transmitted to the peripheral device. The instruction directs the peripheral device to reconfigure itself to use a second protocol.
The present invention may be further understood with reference to the following description and the appended drawings, wherein like elements are provided with the same reference numerals. The present invention is related to a system and method for automating a process of establishing communication between a host device and a peripheral device. In the exemplary embodiments, the present invention will be described with reference to installing and configuring the peripheral device in a point-of-service/sale environment. However, those of skill in the art will understand that the present invention may be implemented in any computing environment in which one or more peripheral devices are coupled to the host device including, but not limited to industrial, warehouse, manufacturing and healthcare environments.
The POS system 15 comprises a host device (e.g., a register 30, a computer) and one or more peripheral devices coupled thereto, e.g., a keyboard 35, a scanner 40, a display, a keypad, a mouse, a printer, a magnetic strip/smart card interface, an image-based scanner, a laser-based scanner, a linear CCD-scanner, a contact scanner, an RFID reader and a magnetic strip reader, etc. The host device may be a stand alone register, computer, thin client device, network-bootable device, mobile device, etc. In the exemplary embodiment, the register 30 may be a PC, laptop or other computing unit which includes an operating system, applications and drivers and is enabled for communication on the network 20. That is, the register 30 may include an Ethernet port for communicating on a LAN, a radio frequency transceiver for communicating on a wireless LAN, and/or other network connection. The register 30 further includes one or more host-peripheral interfaces for coupling to the peripheral device(s). The hardware port used for attaching each of the peripheral devices may be selected based on a corresponding interface used thereby. For example, the keyboard 35 and the scanner 40 may connect to USB ports or Bluetooth® connections on the register 30, while the printer and the display may utilize RS-232 ports. While the exemplary embodiment will be described with reference to the USB ports, those of skill in the art will understand that the present invention may be implemented for any host device with at least one host-peripheral interface.
As is common in retail environments, the peripheral devices are interchangeably used with the POS system 15. For example, the peripheral devices may be added, removed, re-installed, upgraded, temporarily removed for maintenance, etc. To save costs, a retail store operator may ask a store employee to install and configure the peripheral devices. The installation typically requires a hardware connection (e.g., via the hardware port) and a software connection (e.g., installing a driver for the peripheral device on the register 30). The software connection may also require configuring software settings, e.g., drive mapping, data routing, etc. An untrained employee may encounter several problems with these tasks, requiring help from in-house or contracted IT personnel. In either instance, costs are incurred by the retail store operator, because manual installation of the peripheral device requires technical understanding which a typical store employee may not possess.
According to the present invention, the POS system 15 includes an application or a driver, embodied in software and/or hardware, which controls configuration of the peripheral device. In the exemplary embodiment, the driver detects the connection of peripheral devices to the register 30. When the driver detects that the peripheral device utilizes a first communication protocol, the driver transmits an instruction to the peripheral device to reconfigure itself for use with a second communication protocol. In the exemplary embodiment, the first protocol does not support configuration of the peripheral device (e.g., the scanner 40) either directly with predefined commands or indirectly by encapsulation of the predefined commands in the first protocol. The second protocol supports the configuration of the peripheral device, as will be further described below. While the exemplary embodiment describes the application as residing in the driver, those of skill in the art will understand that the application may reside within the register 30, outside of the driver, at the server 25, on a removable storage medium, etc.
As is known in the art, when the peripheral device (e.g., the scanner 40) is coupled to the register 30 (via the USB port), the register 30 requests that the scanner 40 describe itself by supplying enumeration data. While the exemplary embodiment will be described with reference to the scanner 40, those of skill in the art will understand that the other embodiments may reference any of the peripheral devices described herein and/or commonly known in the art. The enumeration data may be included in a series of fields which are defined in the host-peripheral interface, e.g., a USB standard or a Bluetooth® standard. The enumeration data provided in, for example, a device-class field, a device-subclass field and/or a device-protocol field is used by the register 30 to determine whether the scanner 40 is utilizing the first protocol, and, thus, should be instructed to reconfigure itself to utilize the second protocol.
The register 30 may utilize conventional host-side USB software to determine the communication protocol utilized by the scanner 40. That is, the USB standard defines several device-class types such as, for example, a “mass-storage device”, a “human interface device (HID)”, etc. In the exemplary embodiment, the register 30 determines the communication protocol used by the scanner 40 based on the enumeration data provided thereby. For example, the enumeration data from the scanner 40 may be indicative of a “USB HID keyboard wedge device” which utilizes the first protocol, preventing automated out-of-the-box configuration of the scanner 40. That is, the scanner 40 would have to scan one or more bar codes to switch to the second protocol which enables automated configuration.
According to the present invention, the driver monitors a bus (e.g., a USB bus) in the register 30 to determine when the scanner 40 has been plugged into the USB port and/or powered up. As noted above, the driver may monitor connections on any host-peripheral interface, and the USB bus is simply an example thereof. When the driver determines that the scanner 40 is enumerated as a device using the first protocol, it transmits a command which, when received by the scanner 40, instructs the scanner 40 to reconfigure itself to re-identify itself as a peripheral device which utilizes the second protocol, which supports configuration of the scanner 40. After the scanner 40 has switched to the second protocol, it may automatically download its settings from the register 30. The download may also be driven by the register 30 and/or a command sent over the network 20. This may eliminate the manual configuration described above.
In step 210, the driver determines whether a peripheral device using the first protocol has been coupled to the register 30. In the exemplary embodiment, the driver monitors the enumerations on the host-peripheral interface. As stated above, after the scanner 40 is coupled to the register 30, the enumeration data of the scanner 40 is requested by the register 30. Using the enumeration data in the device-class, device-subclass and/or device-protocol fields, the driver determines whether the scanner 40 is using the first protocol. If the scanner 40 utilizes the first protocol, the register 30 will a communication link with the scanner 40 according to the first protocol, which does not support means for configuring the scanner 40.
When the enumeration data indicates that the scanner 40 utilizes the first protocol, the process proceeds to step 215 where the driver initiates reconfiguration of the scanner 40. In the exemplary embodiment, the driver transmits a predetermined instruction on the host-peripheral interface which, when received by the scanner 40, causes the scanner 40 to reconfigure itself to use the second protocol. The predetermined instruction may be, for example, an instruction to set and clear LEDs for Num Lock, Caps Lock and Scroll Lock in a predetermined pattern. The scanner 40 will respond to the instruction, because it enumerated as a “USB HID keyboard wedge device.” In a preferred embodiment, the pattern lasts only approximately 500 ms. However, the driver may continue re-initiating the pattern until the scanner 40 detects it.
Additionally, because the instruction may be transmitted on the USB bus, any other USB HID keyboard wedge device, e.g., the keyboard 35, may respond to the instruction. That is, while the scanner 40 responds to the instruction by reconfiguring itself, the keyboard 35 responds by setting and clearing its LEDs in the predetermined pattern. Those of skill in the art will understand that the instruction may be one or more actions which would be interpreted by the scanner 40 as an instruction to switch communication protocols. Preferably, the instruction is innocuous, such as one or more used and/or unused, supported and/or unsupported keyboard directives (e.g., one or more LED blinks) or HID usages, etc. to minimalize the employee involvement in the installation and configuration of the scanner 40.
In an alternative exemplary embodiment, a driver may include intelligence to recognize vendor-specific peripheral devices which enumerate on the USB bus. The driver only transmits the instruction when the vendor-specific peripheral device enumerates on the USB bus. For example, when the peripheral device enumerates as a “Company A USB HID keyboard wedge device”, the driver transmits the instruction. In this embodiment, the driver may refrain from transmitting the instruction each time a peripheral device that is not manufactured by Company A enumerates on the USB bus.
In step 220, the scanner 40 receives the instruction and reconfigures itself to utilize the second protocol. In this manner, the scanner 40 re-enumerates on the USB bus as a device which utilizes the second protocol. That is, re-enumeration data indicative of the second protocol may be included in the device-class, device-subclass and/or device-protocol fields. Additionally, the scanner 40 may reboot after reconfiguration, and, as such, subsequently enumerates on the USB bus of the register 30 (or any other host device) as a peripheral device using the second protocol. Thus, the driver(s) does not have to transmit the instruction each time the scanner 40 is coupled to the register 30 (or any other host device).
In step 225, the register 30 establishes a communication link with the scanner 40 according to the second protocol. In optional step 230, the driver may reset any peripheral devices on the USB bus to a pre-instruction condition. As explained above, the keyboard 35 may have responded to the instruction by setting and clearing its LEDs. Thus, to minimalize employee confusion, the driver may reset the LEDs to the pre-instruction condition.
In another optional step 235, the register 30 may download settings to the scanner 40. In this embodiment, a Remote Management Mechanism may be enabled. For example, if the register 30 is located in a Pharmacy within the retail store, the settings may include a setting for scanning pharmacy bar codes. If this same scanner 40 is removed from the register 30 and attached to a further host device in a warehouse, the settings of the scanner 40 may be reconfigured by the further host device for warehouse operation.
Those of skill in the art will understand that the present invention may enable automated out-of-the-box setup of a peripheral device. This setup may reduce and/or eliminate manual staging or barcode scanning conventionally required for installing and configuring the peripheral device. Also, the present invention allows non-technical personnel to install and configure peripheral devices on the host device they are using.
The present invention may also eliminate several costs associated with manual staging. For example, upon an unsuccessful attempt to install and configure the peripheral device, untrained personnel may return the peripheral device to a manufacturer for replacement or repair. In actuality, the peripheral device is in proper working order and simply has not been configured properly. The cost of configuration in a staging facility is also reduced and/or eliminated. The present invention further reduces a spares pool. That is, different peripheral device hardware configurations for each software application used by the retail store may no longer be required.
The present invention has been described with the reference to the above exemplary embodiments. Accordingly, various modifications and changes may be made to the embodiments without departing from the broadest spirit and scope of the present invention as set forth in the claims that follow. The specification and drawings, accordingly, should be regarded in an illustrative rather than restrictive sense.
