Error detection/correction and fault detection/recovery – Data processing system error or fault handling – Reliability and availability
Reexamination Certificate
1999-06-03
2002-06-18
Beausoleil, Robert (Department: 2184)
Error detection/correction and fault detection/recovery
Data processing system error or fault handling
Reliability and availability
C714S002000, C714S048000
Reexamination Certificate
active
06408407
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates generally to device error management. More particularly, the invention relates to a system for delegation of recovery of hardware device errors to a specialized error handler suitable for use in data processing systems used in a retail environment.
BACKGROUND OF THE INVENTION
Many systems used in a retail environment use software applications to perform various operations. Each application may call on various hardware devices in performance of its tasks. Any of the hardware devices is subject to faults and errors. In systems of the prior art, faults and errors are typically handled by a return of an error status to the application which called on the device. After receiving the error status, the application must perform error correction. For example, a retail store may operate a self-checkout system to allow customers to handle their transactions and payments. This may include numerous hardware devices, including barcode scanners for item entry, magnetic stripe readers for reading credit or debit card information, printers for printing transaction receipts, and keypads for customer entry of data. Any of these hardware devices may be subject to faults and errors. For example, a barcode scanner may be unable to properly scan an item as a result of either a fault in the barcode, improper scanning procedure by the customer, or a fault in the scanner itself. A magnetic stripe reader may fail to properly read a credit or debit card. A printer may run out of paper. In conventional systems, each of these events causes a device to return an error code to the controlling application. A platform such as a checkout station may implement several different applications. For example, an item logging application may control scanning and logging of items in the transaction. A payment application may control acceptance of payment and closing of the transaction, with the payment application employing either a cash tender subapplication or a card tender subapplication, depending on whether payment is to be made with cash, or with a credit or debit card. The applications may share control of the same devices, for example a printer. This leads to redundancy of error handling software, and added expense due to the need to include error handling code in each application. For example, each application which calls the printer will sometimes encounter a printer failure and will need to process error messages from the printer and handle correction of the printer failure. The redundancy and accompanying excess expense is particularly pronounced when applications from different vendors reside on the same platform and share control of the same hardware devices. This is true because software applications from different vendors will be developed separately, and are unlikely to include any shared or copied code or procedures, even for functions which are duplicated between the applications, such as error handling procedures addressing errors in the same devices.
There exists, therefore, a need in the art for a system in which different operations may be performed by different applications which call hardware devices as required, and which provides for correction of and recovery from device errors in a way that avoids a need for error handling by each individual application, and therefore avoids the duplicate effort caused when multiple applications call a single device and when each of the applications is required to correct errors for the device.
SUMMARY OF THE INVENTION
A system employing the principles of the present invention may suitably be a customer self-checkout system used in a retail store. During normal operation, the system is typically operated by a user such as a retail customer. The system performs different operations in the performance of its functions, with different operations each being controlled by different software applications. In controlling the operations, the applications make requests to hardware devices as needed. If an application calls a device, and the device returns a normal status, the system logs a “success” status and the process proceeds normally. If the device does not return a normal status, the system determines if the status indicates that delegation to an error handler is indicated. If no delegation is indicated, the system returns the actual device status to the controlling application. If the status is one that should be delegated, the system attempts to look up the desired remedy from a database. The use of a remedy database allows configuring and scripting of actions to take for error correction. If the delegation system does not find an entry for the status, it pursues a default error handling routine. This is a predefined series of steps to be taken in a case in which no remedy is found in the database. After the default error handling routine has been completed, a “normal” status is returned and control is returned to the controlling application.
If the remedy for the error is found in the database, the delegation system proceeds to correct the error. After the delegation system finds the correct scenario to follow, it analyzes the actions prescribed, and the consequences of the error. If the error is one which does not affect the user, the system logs the error status to a file for later processing and returns a “normal” status to the application. If the error condition affects further operation of the system, the delegation system determines if the user can remedy the error, and if so, guides the user through the use of dialogs. If the error is not suitable for remedy by a user, an alert is issued to a store employee and the checkout system is taken offline until a store employee can sign on. At that point, the store employee is directed through a sequence of actions to be taken for remedy of the situation. If the checkout system operation is not affected, or if correction by the user or store employee is successful, the delegation system then returns a “success” status to the calling application, which is then free to continue. Otherwise, the checkout system remains offline until repairs can be made.
A more complete understanding of the present invention, as well as further features and advantages of the invention, will be apparent from the following Detailed Description and the accompanying drawings.
REFERENCES:
patent: 3575589 (1971-04-01), Neema et al.
patent: 3786430 (1974-01-01), Hajdu et al.
patent: 3818199 (1974-06-01), Grossmann et al.
patent: 4497057 (1985-01-01), Kato et al.
patent: 4598356 (1986-07-01), Dean et al.
patent: 4617661 (1986-10-01), Futaki et al.
patent: 5007056 (1991-04-01), Nakajima
patent: 5299207 (1994-03-01), Fujii
patent: 5440688 (1995-08-01), Nishida
patent: 5479611 (1995-12-01), Oyama
patent: 5494136 (1996-02-01), Humble
patent: 5748880 (1998-05-01), Ito et al.
patent: 5748883 (1998-05-01), Carlson et al.
patent: 6000045 (1999-12-01), Lewis
patent: 6128017 (2000-10-01), Alimpich et al.
patent: 6148419 (2000-11-01), Ahrens et al.
patent: 6173422 (2001-01-01), Kimura et al.
patent: 6269460 (2001-07-01), Snover
Beausoleil Robert
Chu Gabriel L.
NCR Corporation
Priest Peter H.
LandOfFree
Methods and apparatus for delegated error handling does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Methods and apparatus for delegated error handling, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Methods and apparatus for delegated error handling will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2922384