WO1995003595A1

WO1995003595A1 - Handheld point-of-sale system

Info

Publication number: WO1995003595A1
Application number: PCT/US1994/008418
Authority: WO
Inventors: Nicos J. Anthony; Gregory Sean Mckinley; Perry Tsang
Original assignee: Inflight Duty Free Shop, Inc.
Priority date: 1993-07-23
Filing date: 1994-07-25
Publication date: 1995-02-02
Also published as: AU7405194A

Abstract

The present invention is directed to a point-of-sale system for controlling, selling, and replenishing of duty free items onboard commercial aircraft. The point-of-sale system (100) includes a programmable, handheld, independently powered computer that provides a user-friendly, dynamic user interface (110). The resulting implementation automates sales and payment transactions (154), pre-sales transactions (142, 152), post-sales transactions (144, 158), updates inventory, and minimizes the use of paper forms, while allowing the inflight sales staff to perform his/her task in an efficient manner.

Description

Handheld Point-of-Sale System

Background of the Invention

1. Field of the Invention

The present invention relates generally to a handheld point-of-sale system, and more particularly, to a system for automating bond store and inflight processing of product inventory and sales transactions.

2. Discussion of Related Art

With the deregulation of airlines, a higher standard of service and facilities is being provided by the different airlines around the world in order to appeal to the customers. One such service is the sale of duty free items inflight.

Airline onboard sales of duty free items (e.g., watches, perfumes, liquors) is now a standard practice for most airlines. This practice allows airline customers to enjoy the benefit of purchasing duty free items in an uncomplicated, relaxed manner during international flights. The sale of these items onboard airlines is commonly referred to as a point-of-sale transaction.

Point-of-sale transactions, however, do provide a variety of management and accounting problems for the airlines.

To begin with, the demand on flight attendants is such that not only must they fulfill the role of tending to the passengers needs during a flight, but they must provide a certain degree of airline marketing (i.e., customer relations). As a result, flight attendants typically do not have the time for nor do they place a high priority on duty free service.

The items for inflight duty free sales are distributed via a "bond store". The bond store is governed by Customs' rules and regulations. It is therefore essential that proper inventory records be kept for all items transferred into and out of the bond store. From the bond store, items are distributed to the individual flights where they are offered for sale to passengers. Proper records must be maintained for all sales and inventory transactions. In addition, these transactions must be able to be performed in an efficient, uncomplicated manner.

Once duty free sales have been completed, a post-sales assessment of the current inventory must be done. Reports documenting inventory changes, sales, and payments must be generated in accordance with accounting and Customs' requirements. Remaining inventory is returned to the bond store where it is replenished for the next flight.

Conventionally, the above functions have been performed manually which is both time consuming and error prone. Inventory sheets have to be manually filled and cross referenced during bond store and inflight activities. Some of these activities have been automated in past years. A variety of companies have tried to incorporate all of the above functions into one singular compact unit but have been unsuccessful in their efforts. Given the long felt need in the industry for this product, there exists a need for a portable system that can functionally handle all the tasks associated with controlling, selling, and replenishing duty free items.

More specifically, there is a need to develop a system for automating inflight sales and inventory management. This automation should not only provide better management facilities, but also allow inflight sales staff to provide a better service to the passengers. Furthermore, the system should be convenient and easy to use by flight attendants at the point-of-sale and during inventory and cash accounting procedures. Consequently, the airline can provide the best possible service to the passengers, and in turn, have a competitive edge over other airlines in this regard. Summary of the Invention

The present invention is directed to a point-of-sale system for controlling, selling, and replenishing duty free items. The point-of-sale system includes a programmable, handheld, independently powered computer that provides a dynamic, user-friendly interface. The resulting implementation automates sales and payment transactions, updates inventory, and minimizes the use of paper forms, while allowing the inflight sales staff to perform his/her task in an efficient manner.

The point-of-sale system provides means for the preparation and replenishment of inflight inventory customized to the needs of particular airlines and locations. It provides accurate and timely information on the items for sale and all inventory changes due to sales, damages, losses and other discrepancies. The point-of-sale system further provides for the generation of reports which document inventory changes, sales and payments in accordance with accounting and Customs' requirements.

In order to provide these services, the point-of-sale system supports a window¬ like interface that is hardware independent. The user interface succeeds in providing a rich set of sales and inventory functions in a user-friendly environment. The combination of functionality and ease of use has not been achieved heretofore in devices of this variety and capability. Users are able to perform sufficiently complex operations at the point-of-sale promptly and easily. Moreover, initial training time in the inflight use of the handheld point-of-sale system has typically been on the order of a few minutes. Brief Description of the Drawings

The foregoing and other features and advantages of the invention will be apparent from the following more particular description of the preferred embodiments of the invention, as illustrated in the accompanying drawings, in which:

Figures 1(A) and 1(B) collectively illustrate a high level block diagram of the functional modules and hardware components of the present invention.

Figure 2 shows a detailed, exploded view of a handheld, programmable computer used in accordance with the teachings of the present invention. Figure 3 shows a flowchart of the initialization of the data structures accessed by the present invention.

Figure 4 illustrates the handheld inventory data structure. Figures 5(A) through 5(D) show the substructures of the handheld flight information data structure. Figure 6 shows the handheld currency data structure.

Figures 7(A) through 7(J) show the data structures that form the sale/payment data structure.

Figure 8(A) through 8(E) show the data structures that form the handheld flight totals data structure. Figure 9(A) is a high level block hierarchial block diagram of the operational flow of the point-of-sale system.

Figure 9(B) illustrates a flowchart of the monitor program for the point-of-sale system.

Figures 10 through 51 illustrate the menus that are accessed via the user interface. Description of the Preferred Embodiments

The present invention is directed to a point-of-sale system for controlling and replenishing merchandise inventory (e.g., duty free items) and management of sales onboard commercial aircraft. However, the system can be applied to other applications as would be apparent to a person skilled in the relevant art.

Following an introduction to the general principles of the point-of-sale system, its major elements are more fully described in separate portions of the detailed description with specific reference to the dynamic, graphical user interface of the present invention. Figure 1(A) is a simplified block diagram of a point-of- sale system 100.

In particular, Figure 1(A) illustrates the different modules of the point-of-sale system 100 and their respective functional interconnections. The point-of-sale system 100 operates within a programmable, handheld, independently powered computer 200, as shown in Figure 2, which is used by airline staff during inflight sales to passengers. The handheld computer 200 has attached thereto a magnetic card reader and printer 210 (shown in Figure 1 as magnetic card reader 130 and printer 120). The point-of-sale system 100 is also connected to an external interface 135 that allows the system to be connected to peripheral devices (i.e., a personal computer or mainframe computer). The resulting implementation automates sales and payment transactions, updates inventory, and minimizes the use of paper forms.

The point-of-sale system 100 includes a user interface 110 which interacts with a set of data structures (described below). The user interface 110 accesses the data structures via a set of software modules - a bond store module 140 and an inflight sales module 150. Both modules 140, 150 contain a plurality of sub-modules. Specifically, the bond store module 140 contains a pre-flight module 142 and a post-flight module 144. The inflight sales module 150 contains a pre-sales module 152, a sales/payment module 154, an adjustment module 156, a post-sales module 158, and a refunds module 160. A functional description of each of these modules will be given in detail below.

The modules 140, 150 rely on a data structure containing the inflight inventory for their operation. This data structure described in greater detail below is referred to as the handheld inventory structure (HHIS). The HHIS is part of a handheld database 170 which stores all of the data structures (described in detail below) used by the point-of-sale system 100. The HHIS partitions the inflight inventory into categories of brands (e.g., fragrances for women, cosmetics, liquor, gift & accessories, etc.). In effect, the inflight inventory may be viewed as shown in Figure 4. The individual structures in the HHIS can be accessed via _DSFCtgSet 420. The files in the HHIS data structure include a category set 430, a category description 440 (_DFSCatgry), an item set 450, and item description 460 (_DFSItem). These structures are all separate data structures, described in more detail below, but each is a constituent part of the HHIS.

The HHIS is dynamically built from information about the items sold and exchange rates used by each airline. The HHIS is built outside the handheld computer. In a preferred embodiment, the HHIS is built in the bond store on a personal computer. The personal computer can be connected to a mainframe computer via a direct line or via modem. The HHIS is downloaded to the handheld computer 200 in preparation for bond store and inflight functions.

The inventory for inflight duty free sales is stored in the bond store. The bond store is governed by Customs' rules and regulations. It is essential that proper records be kept for all items transferred into and out of the bond store. In preparation for a particular flight, a ground crew first identifies the following information: flight number, departure date, and cart number. Next, the airline's packing requirements for the flight are compared against the current HHIS state. If necessary, inventory is replenished and the HHIS state is updated accordingly. Subsequently, a listing of the current HHIS state is generated and printed. The current HHIS state indicates all items which will be loaded onto the airplane. The HHIS state also indicates any missing items with respect to the airline's packing requirements.

Once the pre-flight procedures have been completed, the inventory is loaded onto the airplane. The inventory is stored on a push cart (not shown) adapted for inflight services. At this point a designated person (i.e. , a specified senior member of the sales staff) follows a pre-sales procedure. In particular, the designated person checks the actual count and the condition of inventory that has been loaded onto the aircraft against the HHIS state report (printed in the bond store). If the count or condition of the inventory does not match the

HHIS state report, the present invention provides a mechanism for updating the HHIS state. This mechanism is accessed via the inventory function (described below) of the pre-sales module 152. Specifically, after the designated attendant enters a pre-defined ID, he/she selects a category and item via the user interface 110. The HHIS state is corrected by inputting the correct item count. Subsequently, a listing of the current HHIS state is generated via printer 120.

The designated person also verifies flight relevant information (e.g., flight number and departure date), enters the passenger count, and identifies crew members as part of pre-sales procedures.

Once the pre-sales procedures are completed, sales of the inventory (i.e., duty- free merchandise) can begin. The actual sales of inventory is executed by authorized inflight sales staff. Once again, the system requires that the inflight sales staff enter a pre-defined personal ID. Note that the ID procedure is optional and can be customized to the individual needs of the airline.

Once the inflight sales staff has entered the sale/payments module 152, he/she is provided via the user interface 110 with a plurality of categories relating to products. Scrolling is provided in case all the categories cannot fit within one menu. The user interface 110 then provides a list of items (i.e. , products) for the customer to select from. Again, scrolling is provided to view a different set of items if all the items cannot fit within one menu.

Next, the item chosen by the customer is selected via the user interface 110. Information about the item appears via the user interface 110 (e.g., its name, price, and the current available quantity). The user interface 110 provides a numeric keypad. The keypad is used to: (1) enter an initial quantity for the selected brand; (2) increase the quantity already ordered; and (3) reduce the quantity on order by entering the desired (reduced) quantity. Since the desired quantity for a brand is usually one, the keypad is initialized with a count of one when it initially appears within a particular menu.

Once the desired quantity is entered, the user interface 110 returns to the item display. As a brand is ordered, indices which identify the brand, and the quantity ordered, are added to an array of structures which maintains the current number of brands on this order. This array of structures is embedded into a handheld order data structure (HHORS) which is built dynamically to record what the customer has purchased. Additionally, HHORS contains headers linked to dynamically allocated payment structures (see below) and maintains the total sales and current outstanding balance, as well as the currency being used.

Other features of the user interface 110 are as follows. A "review order" key is provided to review what is currently on order. A "payment" key is provided to allow payment for the current order. Cash, credit cards, travelers checks and airline vouchers are all acceptable payment types. The point-of- sale system 100 provides a dynamic change of currency feature. Payment and change to the customer are possible in a variety of currencies, if cash or travelers checks are selected. Cards and vouchers use an airline's base currency and no change is allowed (as a general rule). An airline's base currency is the currency in which it lists its items' prices. The user interface 110 also provides a "cancel order" key. If an order is canceled, the flight attendant takes back all items given to the customer, returns any monies taken from the customer, and presses "cancel order" to update the inventory and reset the HHORS structure.

In an alternate embodiment, a more interactive "cancel order" procedure is implemented. In this design, the user interface 110 will display for the flight attendant the items ordered and any payments made. As items are returned by the customer and payments are returned to the customer, the user interface 110 will display the number of items remaining and the outstanding balance, guiding the flight attendant through exchanges of items and monies until the order is cleared. The design and implementation of this enhancement can be accomplished without undue experimentation by those skilled in the art based on the disclosure of the present invention contained herein.

An order is complete when the outstanding balance is reduced to zero, due to either an exact payment or return of change to the customer. When the order is complete, the user interface 110 displays an "end of sale" menu with a "next sale" key and a "print receipt" key. If the customer wants a receipt, one may be printed by pressing the receipt key. If the "next sale" key is pressed, the user interface 110 returns to the general categories screen for the user either to start a new sale or to exit and select another inflight function.

When an order is complete, all information relevant to that order is stored in resident RAM within a Handheld Flight Totals Data structure (HHFTS).

Adjustments can be made to inventory or to sales at any time during inflight processing. If an adjustment needs to be made to inventory (i.e., damages), the user can access the adjustments module 156. This will update the inventory state HHIS. If adjustments need to be made to sales (i.e., refunds), the user can access the refunds module 160. This will update not only the inventory state HHIS, but also flight totals HHFTS. Once all sales are complete, a post-sales procedure is followed (by accessing the post-flight module 158) by the inflight sales staff. An end of flight report is generated. The summary report lists sales by item and payments delineated by type and currency. Commission for inflight sales staff can also be generated. Finally, an end of flight HHIS listing is generated and printed for use at the bond store. The inventory cart is secured via well known means and not opened until it is received at the bond store.

Figure 1(B) shows a more detailed block diagram of the user interface 110. The goal of the user interface is to enable computer illiterate individuals to easily perform inflight duty free sales functions both in the bond store and during flights. The user interface 110 is implemented through a set of windows which appear dynamically, depending on the function being performed. The user is able to navigate from window to window by pressing computer generated "keys" on the touch sensitive screen 205 of the handheld computer 200. Nearly all windows contain a message area where context dependent messages are displayed to direct the user to take the correct action.

The user interface 110 is a significant component of the present invention because it succeeds in providing a rich set of sales and inventory functions in a user-friendly environment. This combination of functionality and ease of use has not been achieved heretofore in devices of this variety and capability.

Users are able to perform sufficiently complex operations at the point-of-sale promptly and easily. Training time for the handheld point-of-sale system 100 has typically been on the order of a few minutes.

The user interface achieves its goal through the components 180, 185, and 190, and the window platform 195. This window platform comprises a set of windowing functions (e.g. "create/destroy button", "display/clear message", etc.) which have been designed (a) to raise the application programming level and customize it for the requirements of sales, inventory, and currency change functions; and (b) to insulate the design and implementation above this level from the detail in and differences among vendor provided support software and hardware.

The components 180, 185, and 190 provide, respectively, the data structures and associated functions for inventory, change of currency, and keypad. Each of these components encapsulates its own data structures and public service functions. It is only through these service functions that other components of the point-of-sale system 100 interact with the components 180, 185, and 190. Within the point-of-sale system 100, each of the components 180, 185, and 190 is created, used through its public service functions, and destroyed when it is no longer needed. Because of this architecture, the components 180, 185, and 190 will be called "objects", even though they are not true objects in the sense of object oriented programming. It is submitted, however, that those skilled in the relevant art will be able to provide components 180, 185, and 190 as true objects in an environment which provides an appropriate object oriented platform. The platform of this invention is Microsoft DOS 3.2.

The inventory object 180, even though it can be destroyed and recreated, remains active (or open) while the user interface 110 is being used because its structures and service functions are used throughout bond store and inflight functions. This object 180 provides the category and item selection menus and enables the user to navigate from each category to the items of that category, and in turn from each item to an application specific keypad menu where the transaction is completed.- The keypad which appears on a keypad menu is an instance of the keypad object 190. Bond store functions, pre-sales, sales, post- sales, adjustments, and refund functions all rely on the same inventory object. Through the relevant functions each of these modules cause the inventory object to perform the desired function.

The currencies object 185 is used to change currencies. This object is accessible from the sales module 154 and refunds module 160. The currencies object 185 provides the customer with payment flexibility, while providing the user with an easy to use mechanism to conduct sales transactions in multiple currencies.

The keypad object 190 is an integral part of the point-of-sale system 100 and is used for a wide variety of functions, e.g., to enter an ID, a count of items sold, payment amounts, etc. The preferred embodiment only includes a numeric keypad. However, as would be readily apparent to a person skilled in the art, other enhancements to the keypad are relatively straightforward.

Figure 2 illustrates a programmable, handheld computer system 200 constructed in accordance with the present invention. The handheld computer system 200 utilized in a preferred embodiment is an Epson EHT-20. The handheld computer 200 includes a whole-screen touch sensitive panel 205. The touch sensitive screen 205 is large enough to allow a user-friendly user interface 110. The handheld computer 200 can be electrically coupled to a magnetic card reader with printer 210, a RS-232C interface 215, barcode reader 220, battery pack 225, and external communication adapter 230.

The handheld computer system 200 is designed to be held easily in one hand. It preferably uses an NEC V40 processor chip running at 10 MHz with MS- DOS version 3.20 operating system provided in ROM. The handheld computer system 200 is also provided with up to one megabyte of RAM. In a preferred embodiment, the handheld computer system 200 is programmed using the C programming language.

In a preferred embodiment the touch sensitive screen 205 provides a resolution of 24 x 48 touch panel keys. The specific application program can customize the organization and size of the keys to fit its specific needs.

The handheld computer system 200 can be electrically coupled to an infrared optical communications interface 230 (shown in Figure 1 as external interface 135). The external interface 230 is capable of operation at up to 31250 bits per second (bps). Simply placing the handheld computer system 200 on the external interface 230 allows communication through the external RS-232C connector on the external interface 230, exactly as from the built-in RS-232C connector 215 on the handheld computer system 200. The external interface 230 allows switching between hand-held use and data transfer to a host processor (not shown).

The handheld computer system 200 allows a wide range of external interfaces. It can communicate with other handheld computer systems or with a host processor (e.g., in a bond store). It can also be connected via the RS-232C connector 215 to a barcode reader 220 for high accuracy barcode reading or a touch scanner 240.

The top end of the handheld computer system 200 forms a plug-in interface for a plurality of cartridge units. Note that the mechanical interface is rugged, and when secured with a pair of fixing screws (not shown) there is no possibility of the cartridge option working loose. Possible cartridge units (not shown) include: a 144-dot printer unit; an IC card reader/writer with printer capable of printing and accessing ISO standard IC cards. In a preferred embodiment, a magnetic card reader and printer 210 capable of printing and reading data from ISO standard magnetic cards is provided via the plug-in interface. A roll paper holder 265, adapted to store paper, can be attached to any one of the above cartridge units.

An earphone jack and cord 280 can also be provided. The earphone jack and cord 280 allows a speaker output for use in noisy situations. The battery pack 225 is held positively in position, but detaches with a simple catch action. The battery is detachable to allow charging independent of the handheld computer 200.

The handheld computer system 200 is supplied with a resume function which allows the system, subsequent to power up, to continue processing from the point the power was last switched off. The system 200 is also provided with an auto power off function. This allows the life of the battery pack 225 to be prolonged. If a preset time elapses without any touch panel 205 input, the power is automatically switched off.

A memory RAM card (not shown) can also be provided to transfer data between a personal computer and the handheld computer 200.

These and other features of the EHT-20 are detailed in the "EHT-20 System Guide" available from Seiko Epson Corporation of Nagano Japan. It should be readily apparent to a person skilled in the relevant art that other handheld computer systems can be used to implement the present invention. The necessary requirements for such a system being portability, programmability, and flexibility.

Figure 3 shows a flowchart of an initialization procedure that is required to operate the present invention. The procedure includes the initialization of all the data structures that are accessed by the point-of-sale system 100 during operation. Specifically, the following data structures are provided: Handheld Inventory Structure (HHrS), Handheld Flight Information Structure (HHFIS), Handheld Currency Exchange Structure (HHCXS), Handheld Items Sales Structure (HHORS), Handheld Items Payment Structure (HHPAS), and Handheld Flight Totals Structure (HHFTS). Also note the initialization in block 350 of the handheld window platform 195.

Figure 4 shows the HHIS data structure 400. The HHIS structure includes (1) the category set structure _DFSCtgSet 420; (2) the array 430 whose elements, each being a category description structure _DFSCatgry 440, form a sequence of categories; and (3) an array 450, one for each _DFSCatgry, whose elements, each being an item description structure _DFTItem 460, form a sequence of items for the category represented by _DFSCatgry. The category set structure 420 contains the number of different categories (nCtgs) and a pointer to the array 430 of category description structures 440. The labels CA[0], . . . , CA[nCtgs-l] are used in the point-of-sale system 100 to refer to the first, . . ., nCtgs-th category structures, respectively.

Each category description structure 440 contains the id, description (e.g.

Fragrances for Women), and number of brands in the category (nBrnds). It also contains a pointer IA to the array IA[0], . . . , IA[nBrnds-l] of item description structures for that category.

The item description structure 460 includes a ctgRank field 462, an identification field 464, a description field 466, a price field 468, an available quantity field 470, a starting quantity field 472, a damaged quantity field 474, a sold quantity field 476, and an ending quantity field 478.

For example, if the point-of-sale system 100 wants to access the 5th item of the 2nd category, it does so by setting the category and item indices to 2 and 5, respectively, in the relevant inventory object service function.

The identification field 464 is a unique identifier which is associated with a particular item. The description field 466 provides a description of the item and the price field 468 indicates the price. The starting quantity field 472 is the beginning inventory. This field is set in the bond store, and is possibly updated during the pre-sale procedure. The sold quantity field 476 indicates the number of items sold. This field is updated during the sales procedure. The available quantity field 470 indicates the quantity of items that are currently available for sale. That is, this field represents the starting quantity minus the sold and damaged quantities. The damaged quantity field 474 indicates the number of items which are damaged. This field is updated during inflight processing. The end quantity field is the ending inventory. It is set at the end of the flight. This field also becomes the start quantity field 474 for the next flight. Similar to the HHIS data structure, the HHFIS data structure is a composite structure. Figures 5(A) through 5(D) illustrate the substructures of the HHFIS data structure 500. The HHFIS data structure 500 includes the following substructures: the _FlightHdr substructure 510, the _Crew substructure 550, the _CartHdr substructure 570, and the _AirlineHdr substructure 580.

Figure 5(A) shows the _FlightHdr substructure 510. The flight field 512 indicates the flight number. The suffix field 514 indicates the flight number suffix (e.g., flight 318A). The departure fields 516 indicate the departure date (month, day, year, and century) for the flight number indicated in the flight field 512. The sales field 518 provides the total sales in the base currency for the particular flight indicated in the flight field 512. The pax field 520 indicates the passenger count (i.e., the number of passengers on the flight). The from field 522 and the to field 524 indicate the beginning location and the destination of the flight. -The pre-order field 526 is a flag that is set when an order has been paid for but the item will be delivered at a later time. The control fields 528 provide flags for enforcing rules on execution of functions during the bond and inflight procedures. Finally, the cart field 530 indicates the identification of the cart that is associated with this point-of-sale system 100.

Figure 5(B) shows the _Crew substructure 550. The _Crew substructure 550 is an array of structures each holding the identification (id field 552) and the position (pos field 554) of the flight attendants operating the point-of-sale system 100.

Figure 5(C) shows the _CartHdr substructure 570. The id field 572 indicates the cart number. The" seal_open and seal_closed fields 574 and 576, respectively, are used when the cart is locked and a numbered seal or seals are placed on it. Each seal has a different number. Seal_open 574 is an array identifying the seal numbers verified when the cart is opened and inventory is checked as part of pre-sales procedures. Seal_closed 576 is an array identifying the seal numbers on the cart when it is locked at the conclusion of post-sales procedures.

The _AirlineHdr data structure 580 provides information about the airline that is using the point-of-sale system 100. The structure provides information such as the airline name (field 582) and airline code (field 586). Figure 6 illustrates the HHCXS. The HHCXS contains information required by the point-of-sale system 100 for switching between currencies. The nCurncys field 612 indicates the number of accepted currencies. The bi field 614 is an index into a list of available currencies. The Base field 616 indicates the base currency. The wBase field 618 indicates the current currency being used by the point-of-sale system 100. The cf field 622 indicates the conversion factor to get from the base currency (Base) to the current currency (wBase). The NameA field 620, the XRate field 625, and the Desc field 630 provide pointers to substructures.

The NameA substructure 640 is an array of abbreviations for the different currencies (e.g., USD for U.S. dollars). The Desc substructure 660 is a long description for the currency. The XRate field 650 is an array that contains the current exchange rates. XRate[i] gives the value of one unit of currency i in the base currency. Of course, this substructure must be updated frequently.

As items are ordered and payments for these items are made, the sale totals are stored in a an interwoven sales/payment structure called Handheld Order Structure (HHOrder). HHOrder includes information from the HHORS and HHPAS data structures described above. Figures 7(A) through 7(J) illustrate, and the accompanying text describes, the structures which are used by the sales/payment functions.

Figure 7(A) shows the duty free sales order (_DFSOrder) data structure 705 after it is initialized. The fsa field 708 indicates the total sales amount for a given order. The fba field 710 indicates the outstanding balance due for a given order. The prvFba field 712 is used to save the outstanding balance prior to decrementing it by the latest payment. It is used when change is to be returned to the customer, but the last transaction is canceled and the balance prior to the payment must be restored. The change field 713 is used to hold the exact change (without rounding). It is rounded up to die next currency unit (to the next 100 units for Japanese currency) when change is returned to the customer. The nBrnds field represents the number of brands sold. Note that this number may be less than the number of items sold. The si[10] field 716 (_SaleBrand) provides an array often or less brands per order. The pmnt field 720 (_DFSPaymnt) is the payment structure where payments for a particular order are recorded.

Figure 7(B) shows the _SaleBrand data structure 716 in more detail. The cNo field 717 is a category index. The iNo field 718 is a brand index within the category. The qty field 719 indicates the quantity sold for this brand. As each item is selected for sale through navigation from the category menu and the items menu, an entry is made into the next available slot in the _SaleBrand[] array, at the nBrnds position. Each order is limited to ten different brands. Note that this is a policy decision and not an algorithmic limit.

Figure 7(C) shows the _DFSPaymt data structure 720. The fields cash 725a, chrg 725b, tchk 725c, Vchr 725d, and chng 770 in _DSFPaymt (within _DFSOrder) are the headers for the cash, charge, traveler check, voucher and change, respectively, for the current order.

The _PmntTran structure 725 is a header for each payment of a specific type (e.g., cash, charge, traveler check, and voucher). The _PmntTran data structure 725 has three fields. The list field 726 is a generic pointer allocated and dynamically set for a particular data type. The amt field 727 indicates the total amount received for this payment type. The nTrans field 728 indicates the number of payments for this payment type. Initially, the list is null as determined by the null pointer list. As payments are made, appropriate structures are allocated and linked to the end of the payment list of the same type.

The _ChngTran structure 770 is a header for change which may be returned to the customer. The list and nTrans fields are analogous to those in the

_PmntTran structure. The xamt 774 field holds the exact change, i.e. , without rounding. The gamt 776 field holds the change that is actually given to the customer, rounded up to the next currency unit.

Processing and recording of payments distinguishes between cash, traveler check, voucher payments, and charge payments.

A cash payment, for example, is captured by the data structure shown in Figure 7(E). The next field 732 is a pointer to the next payment of this type. The amt field 734 indicates the amount of payment. The curl field 736 indicates the currency index for the payment indicated by the amt field 734. Referring to Figure 7(F), the first structure in the _CashType structure 730 is a header. Thus, the amount shown in the amt field 734 is equal to the sum of all the different cash payments properly converted to the base currency

A charge payment is captured by a _ChrgType data structure 740 shown in Figure 7(G). The first three fields, next 742, amt 744, and curl 746, are the same as those found in the _CashType data structure 730 described above. The Card field 748 (_CardInfo) is a data structure which records which records information read from a credit card (or entered via the keypad manually).

Referring to Figure 7(J), the return of change to the customer is captured by a _ChngType data structure 780. The fields next 782 and curl 784 are the same as those found in the _CashType data structure 730 described above. The fields xamt 784 adn gamt 786 are the same as those described in the _ChngTran data structure 770 above.

The _CardInfo data structure 748 is shown in Figure 7(H). The abrivn field 752 provides the particular card abbreviation (e.g., AMEX for American Express). The type field 754 provides the full name of the card (e.g.,

American Express). The number field 756 provides the card number. The owner field 758 provides the owners name as printed on the card. Note, as described below, the owner field 758 is left blank if the credit card information must be entered manually. The xDate field 760 provides the expiration date of the credit card. A linked list analogous to the cash list above captures the charge payments for the current order. The linked lists (cash and charge) are freed when the user ends one order and begins a new one.

Referring to Figure 8, the HHFTS is designed to accumulate the total sales, total payments, and total change for each flight. It is comprised of a set of data substructures: tmSales 810, _CashTr an 830, _CardTran 855, VchrTran 880, and _TotalChng 890. JtmSales 810 represents total sales, _CashTran 830 represents total cash or traveler checks received, _CardTran 855 represents total credit card payments, _VchrTran 880 represents total voucher payments, and _TotalChng 890 represents total change.

The _ItmSale data structure 810 is shown in Figure 8(A). The nltms field 815 represents the number of brands available on the cart. The itmld fields 820, which ranges from [0] to [nltms-l], represents an array of brand identifications. Finally, the itmQSld fields 825, which also ranges from [0] to [nltms -1], represents an array of counters, one for each brand which is on the cart.

When an order is completed (i.e., the outstanding balance goes from positive to zero) the index to the sold brand is retrieved from the _DFSItem data structure 460 and used to increment the appropriate itmQSld field 825. The _ItmSales data structure 810 is then used to update the summary sales file. Note that the information needed to produce the sales is also available from the inventory object. As such, the _ItmSale data structure 810 can be eliminated in an alternate embodiment.

The _CashTran data structure 830 is shown in Figure 8(B). The structure can be used for cash or traveler check payment totals. The nCurncys field 832 represents the number of currencies accepted during the inflight sales. The total field 834 represents the cash totals for the inflight sales. The amt fields 840, which range from [0] to [nCurncys-1], provides an array of the cash total for each currency. The bamt fields 845, which range from [0] to [nCurncys- 1], provides an array of the cash total converted to the base currency. The abrNme field 850, which also ranges from [0] to [nCurncys- 1], provides an abbreviation for each base currency. When an order is completed, if there are cash and or traveler check payments, they are added into the appropriate fields

(the fields can also be considered counters) by the particular currency used.

There is an identical data structure for traveler check totals. For the sake of brevity it will not be described in detail.

The _ChrgTran data structure 855 is shown in Figure 8(C). The nCards field 858 represents the number of card types accepted during inflight sales. The total field 860 represents the total amount charged (in the base currency) during inflight sales. The currency field 862 indicates the current base currency. The usgCnt fields 865, which ranges from [0] to [nCards-1], indicates the number of times the card type was used. The amt fields 870, which also ranges from [0] to [nCards-1], indicates the total amount charged on each card type. Finally, the abrNme fields 875, which ranges from [0] to [nCards-1], provides an abbreviated name for every card type. When an order is completed, if there are credit card payments, the amounts will be added into the appropriate field (counter) determined by the card abbreviation. The _VchrTran data structure 880 is shown in Figure 8(D). The nVchrs field 885 represents the number of vouchers accepted during the flight. The total field 886 represents the total value of the vouchers received during the flight. Finally, the curncy field 888 indicates the base currency name. In a preferred embodiment, vouchers can only be accepted in the base currency. Of course, those skilled in the art can readily appreciate the changes that need to be made to the _VchrTran data structure 880 to accept multiple currencies.

The _TotalChng data structure is shown in Figure 8(E). The nCurncys field 891 is the number of available currencies. The xtotal field 892 is the exact total change in the base currency. The gtotal field 893 is the (rounded) change given to the customer in the base currency. Filed 894-897 are arrays from [0], . . ., [nCurncys-1]. The xamt[i] field 894 is the exact change in currency i. The gamt[i] field 895 is the (rounded) change given to the customer in currency i. The xbamtfi] field 896 is the exact flight change in the base currency. The gbamt[i] field 897 is the (rounded) flight change given to the customer in the base currency. The abrNme[i] is the abbreviation for the i-th currency.

The flight total is accumulated in each of the above substructures. The _ItmSales data structure 810 is written into a total sales file; the payment substructures (_CashTran, _CardTran, _VchrTran) and the change substructure

^_TotalChng) are written into a total payments file; the card detail structures (_CardInf o) are appended into a card detail file.

Figure 9(A) shows a high level hierarchial block diagram of the operational flow of the point-of-sale system 100. Each of the rectangles appears as an individual menu via the user interface 110. A Handheld Application Monitor

(HAM) 910 is provided for overseeing the initiation and completion of the modules 915-995. The HAM 910 may be thought of as a process which is always active. When it is activated, it examines the application function sequence state in the data structure, _AFSState, and determines which module or modules may be activated next. Appropriate screens with relevant keys are then displayed. As each module completes it is obligated to register its completion status in the _AFSState. When an application module completes and exits, control returns to the HAM 190. The HAM 190 then uses the "next function" module to select the application modules which may be activated next. In the current implementation, the HAM is provided in the initialization function. The _AFSState is provided by various flight information flags which are set by application modules and are used to ensure that specific functions (modules) are executed in a prescribed order. In this implementation, the modules of Figure 9(A) are all linked together into a monolithic module. An alternate implementation follows the flowchart of Figure 9(B). This implementation uses the Microsoft DOS batch file language to provide the continuous loop in the HAM 190. A C program provides the "next function" module.

The bond menu 915 has two modules: a pre-flight module 916 and a post- flight module 918. The pre-flight module 916 provides access to two functional options: PC_Interface 920 and bond uplift 930, and the post-flight module provides access to bond inventory 925. The PC_Interface 920 allows data to be downloaded from a host computer to the point-of-sale system 100 or uploaded from the point-of-sale system 100 to the host computer. The bond inventory function 925 provides a mechanism for displaying and updating the HHIS inventory. Uplift allows inventory to be replenished in the bond store.

In a preferred embodiment, the HAM 910 only displays the bond menu 915 or the inflight menu 940 when appropriate. In other words, depending on the HHIS state, the HAM 910 will show either the bond menu 915 or the inflight menu 940. For example, an empty or posted flight causes the bond menu 915 to appear since the cart totals must be uploaded and the cart must be prepared for a new flight. A sealed cart causes the inflight menu 940 to appear because the bond store procedures have been completed. The inflight menu 940 provides the following options: pre-sales 945, sales 965, post-sales 970, adjustments 990, and refunds 995. If pre-sales 945 is chosen, the designated attendant can input or make changes to flight information (e.g., flight number, number of passengers, departure date), crew information, and inventory. The inventory is updated if the current inventory is not in conformity with the HHIS listing. If the HHIS listing accurately reflects the inventory present on the cart, the designated attendant should sign and date the HHIS listing; of course, this is optional.

The sales feature 965 will be described in detail below with reference to the individual menus.

If post-sales is chosen, the point-of-sale system 100 provides for displaying and printing the current inventory (inventory 975). The printed HHIS listing is attached to the cart for review by Customs and for handling at the bond store. Also provided is a mechanism for printing a report that includes total sales and payments. If closing 985 is selected, the point-of-sale system 100 closes the flight. Once a flight has been closed, its sales and inventory data cannot be changed.

All the features described with reference to Figure 9 will be described in detail with reference to the individual menus supplied by the point-of-sale system 100. Figures 10 through 52 illustrate the different menus that can be accessed via the user interface 110. Different menu items are selected by pressing down at the indicated position of the touch-sensitive screen 205 of the handheld, programmable computer 200. The menus are very dynamic in that they provide for all possible scenarios. The menus also allow the inflight sales staff to navigate easily from one menu to another. Note that the menus have been designed to provide easy readability. Also note that additional menus (as required) can easily be provided as would be apparent to those skilled in the art. The menus discussed below are not intended to be a limitation, but rather exemplary of the functionality provided by the present invention. Referring to Figure 10, when the point-of-sale system 100 is initially turned on the user is prompted via a window 1020 to enter an identification number. The identification screen 1000 provides a keypad 1005. The user enters a personal ID via the keypad 1005. The entered ID is visible through a window 1010. If a mistake is made, the user is provided with a backspace key 1050 or a clear key 1060. Once the correct ID has been entered an enter key 1040 is pressed. At any time the user can exit the program by pressing the exit key 1030. Note that the particular airline currently employing the point-of-sale system 100 is indicated in a window 1070.

Referring to Figure 11, the user is prompted with a menu that allows selection between pre-sales 1110, sales 1120, post-sales 1130, and adjustments 1140. At the top of the menu is a window 1050 for identifying the particular cart that the point-of-sale system 1O0 will be associated with, the flight number, and the departure time. These three fields are filled in as outlined below. Menu 1100 also provides a previous screen key 1160 that allows navigation between the present menu 1100 and the previous menu 1000.

If the pre-sales key is pressed then the system advances to menu 1200. Figure 12 shows the pre-sales menu 1200. Menu 1200 provides three keys: a flight information key 1210, a crew key, and an inventory key 1230. Menu 1200 also provides a previous screen key 1240 for navigating between the present screen 1200 and the previous screen 1100. For the sake of brevity, the previous screen keys will not be discussed with reference to menus 1300 to 2700. Note, however, this is not intended to detract from the importance of the previous screen key from creating a very user friendly environment.

If the flight information key 1210 is pressed then the system advances to menu

1300. Figure 13 shows the flight information menu 1300. The flight information menu provides four keys: a cart number key 1310, a flight number key 1320, a departure data key 1330, and a pax count key 1340. Referring to Figure 14, if the cart number key 1310 is pressed the point-of- sale system 100 advances to menu 1400. Menu 1400 provides a keypad 1420. The user enters a cart number via the keypad 1420. The entered cart number is visible through a window 1410. If a mistake is made, the user is provided with a backspace key 1430 or a clear key 1440. Once the cart number has been entered an enter key 1450 is pressed. Referring to Figure 15, if an invalid cart number is entered, the point-of-sale system 100 prompts the user with a message in a window 1510. The message indicates that the entered number represents an invalid cart number, and the user should try again. Once a correct cart number has been entered the point-of-sale system 100 returns back to Menu 1300.

Referring to Figure 16, if the flight number key 1320 is pressed the point-of- sale system 100 advances to menu 1600. Note that a Cart number (213) now appears in window 1605. Menu 1600 provides a keypad 1620. The user enters a flight number via the keypad 1620. The entered flight number is visible through a window 1610. If a mistake is made, the user is provided with a backspace key 1630 or a clear key 1640. Once the flight number has been entered an enter key 1650 is pressed. Referring to Figure 17, if an invalid flight number is entered, the point-of-sale system 100 prompts the user with a message in a window 1710. The message indicates that the entered number represents an invalid flight number, and the user should try again. Once a correct flight number has been entered the point-of-sale system 100 returns back to Menu 1300.

Referring to Figure 18, if the departure key 1330 is pressed the point-of-sale system 100 advances to menu 1800. Note that a Cart number (213) and the flight number (205) now appears in window 1805. The departure menu 1800 allows the user to enter in the departure data of a particular flight. The procedure followed, and the keys provided in menu 1800, are similar to that described in connection with menus 1400 and 1600. For the sake of brevity, a description will not follow. Referring to Figure 19, as with menus 1500 and 1700, if the user enters an invalid date he/she is prompted with an error message in a window 1910.

Referring to Figure 20, if the pax count key 1340 is pressed the point-of-sale system 100 advances to menu 2000. Note that a Cart number (213) and the flight number (205), and departure date (06/29/93) now appears in a window

2005. The pax count menu 2000 allows the user to enter the passenger (pax) count. The procedure followed, and the keys provided in menu 2000, are similar to that described in connection with menus 1400 and 1600. For the sake of brevity, a description will not follow. Referring to Figure 21, as with menus 1500 and 1700, if the user enters an invalid quantity he/she is prompted with an error message in a window 2010.

Once the correct passenger count has been entered the point-of-sale system 100 returns back to Menu 1300. Note that the cart number, flight information, departure data, and passenger count do not have to be entered in any specific order. Once this information has been entered into the point-of-sale system

100, the user returns to menu 1200 by pressing the previous screen key 1350.

Referring to Figure 22, if the user presses the crew key 1220 he/she will be prompted with a message menu 2200. Menu 2200 indicates, via the message window 2210, that the crew members have not been identified for a particular flight. Menu 2200 instructs the user to press an add crew key 2220.

Referring to Figure 23, upon pressing the add crew key 2220, the point-of-sale system 100 advances to menu 2300.

Menu 2300 provides a keypad 2320. The user enters the crew identification (ID) number via the keypad 2320. The entered crew ID number is visible through a window 2310. If a mistake is made, the user is provided with a backspace key 2330 or a clear key 2340. Once the crew ID number has been entered an enter key 2350 is pressed. Referring to Figure 24, if an invalid crew ID number is entered, the point-of-sale system 100 prompts the user with a message in a window 2410. The message indicates that the entered crew ID number is invalid, and the user should try again. Once a correct crew ID number has been entered the point-of-sale system 100 advances to menu 2500 (Figure 25).

Referring to Figure 25, menu 2500 allows for selection of a crew position code. The user selects a position by pressing one of the displayed keys. A crew position does not have to be selected. The user returns to menu 2600 (Figure 26) by either selecting a position or pressing the previous screen key 2510. Note that the menu displays the id (23658) of the crew member whose position is being selected.

Referring to Figure 26, menu 2600 can be reached in one of three ways: (1) if the previous screen key is pressed from the crew id menu 2300; (2) if the previous screen key is pressed from the crew position menu 2500; or (3) if a given flight has crew that have already been identified, and the user presses the crew key 1220 from the pre-sales menu 1200. This menu displays the crew which have been identified for a particular flight. The user can change the crew id (23658) or position (LI) by pressing the respective key 2630 or 2640, respectively. Additionally, crew members can be added by pressing the add crew key 2610. If the previous screen key 2620 is pressed, control is returned to the pre-sales menu 1200.

From the pre-sales menu 1200, beginning inventory counts are established and printed by pressing the inventory key 1230. The user returns back to the main menu 1100 by pressing the previous screen key 1240.

If the sales key 1120 is pressed then the point-of-sale system 100 advances to menu 2800. Figure 28 shows the sales menu 2800. Menu 2800 includes three main windows: a summary window 2810, a category window 2820, and a services window 2830. The summary window 2810 provides information on total sales for a particular customer and the currency that is currently being used by the point-of-sale system 100. As mentioned above, the point-of-sale system 100 always operates under a base currency, which is the currency the point-of-sale system 100 defaults to at start-up. However, as described below, the point-of-sale system 100 can operate - under a plurality of different currencies. In this example, New Zealand currency (NZD) is the base currency, which is indicated in window 2810.

The category window 2820 provides a plurality of product categories (e.g., fragrances for women, cosmetics, watches, etc.). The flight attendant selects a product category and a list of products is displayed. Sometimes there are more product categories than can fit within one window. In this case, a scroll key (not shown) is provided in order to display additional product categories.

The services window 2830 provides a plurality of keys that provide a number of services. As with previous menus, menu 2800 provides a previous screen key 2880 that allows the user to navigate between the current menu and the previous menu. If a sales balance exists and the previous screen key 2880 is pressed, a message screen 2700 (Figure 27) is displayed. The user cannot exit the sales module if a balance is outstanding. The only option available to the user at this point is to press the previous screen key 2710 and return to the main sales menu 2800.

Window 2830 provides five services: a change currency key 2840, a payment key 2850, a review order key 2860, and a cancel order key 2870. These services will be discussed in more detail below.

Referring to Figure 29, the point-of-sale system 100 advances to menu 2900 if one of the product categories is selected from window 2820. Menu 2900 represents an example of a menu generated by pressing the "fragrances for women" key 2825 in window 2820. Menu 2900 provides three main windows: a summary window 2910, an items window 2920, and a services window 2930. The summary window 2910 and services window 2930 contain the same keys as window 2810 and window 2820 of menu 2800, respectively.

The items window 2920 contains a list of items (i.e., products) that are currently for sale. A scroll key 2940 is provided if there are more items than can fit on one screen. The quantity sold column 2940 displays the number of items of the product that have already been ordered.

Referring to Figure 30, the point-of-sale system 100 advances to screen 3000 if one of the items is selected. In this example, the "Chanel No. 5" key was selected. Menu displays the name of the item, its price, and available quantity in a window 3070. Menu 3000 also provides a keypad 3020. The user enters a quantity representing the number of items the customer wants to purchase via the keypad 3020. The entered quantity is visible through a window 3010. If a mistake is made, the user is provided with a backspace key 3030 and a clear key 3040. Once the quantity has been entered an enter key 3050 is pressed. Once the quantity has been entered the point-of-sale system 100 advances to menu 3100. As with previous menus, menu 3000 provides a previous screen key 3060.

Figure 31 illustrates the currency menu 3100. The currency menu 3100 provides a summary window 3110, a valid currencies window 3120, a message window 3130, and an options window 3140. The summary window 3110 apprises the use of the current sales, the balance due, and the current currency being used (e.g., NZD). The valid currencies window 3120 furnishes to the user a plurality of different currencies from which to select. The message window 3110 asks the reader to either confirm the current currency of select a new currency. If the user wants to confirm the current currency he/she presses the confirm selection key 3150 in the options window 3140. Otherwise he/she selects a new currency by pressing one of the keys in the valid currencies window 3120. The valid currencies in this example are New Zealand Dollars (NZD), Australian Dollar (AUD), Canadian Dollars (CAD), Denmark Kroner (DMK), French Frank (FFR), Hong Kong Dollar (HKD), Singapore Dollar (SGD), Solomon Island Dollar (SOL), British Pound (STG), and United States Dollar (USD). Of course, the point-of-sale system 100 can be programmed to accept and conduct sales transactions with any set of valid currencies.

By selecting a new currency, menu 3200 (Figure 32) is displayed. The user can confirm the selection by pressing the confirm selection key 3210; or the user can exit by pressing the previous screen key 3220.

Referring to Figure 33, the point-of-sale system 100 advances to message menu 3300 if the user has not ordered an item and he/she presses the review order key in menu 2800 or menu 2900. The message in menu 3300 indicates that nothing has been ordered. To remove the message, the user presses a previous screen key 3310.

Referring to Figure 34, the point-of-sale system 100 advances to menu 3400 if he/she presses the review order key in menu 2800 or menu 2900. Menu 3400 provides the user with a summary of all the transactions that have occurred for a particular customer. In this example, one bottle of chanel No. 5 has been purchased. The current currency is the Denmark Kroner. To exit this menu, the user presses a previous screen key 3410.

Referring to Figure 35, menu 3500 is displayed if the user has not ordered an item and presses the payment key in menu 2800 or the payment key in menu 2900. The message indicates that there is no balance to be paid. The only option available to the user is to exit by pressing the previous screen key 3510.

Once an item has been selected for purchase, the user can press the payment key in menu 2800 or menu 2900. Upon pressing the payment key, the point- of-sale system 100 will advance to menu 3600. Menu 3600 has a summary window 3610, an options window 3620, and a services window 3630. The summary window 3610 and services window are similar to window 2910 and window 2930 of menu 2900, respectively.

The options window 3620 provides four different payment types: cash, charge, traveler checks, and airline vouchers.

If the customer wants to pay in cash (using the current currency - in this example DMK) the user presses the cash key 2640. Referring to Figure 37, if the cash key 2640 is pressed the point-of-sale system 100 advances to menu 3700. Menu 3700 provides a keypad 3720 for entering in the cash amount received from the customer. The entered amount is visible through a window 3710. If a mistake is made, the user is provided with a backspace key 3730 or a clear key 3740. Once the amount has been entered an enter key 1450 is pressed. Menu 3700 also provides a "use other currencies" key 3760 that allows the user to advance to menu 3100 described above. If the user enters more than the balance, the amount of change owed to the customer is displayed in message area 3770. The change may also be displayed in different currencies by pressing the "use other currencies" key 3760. Change amounts are always rounded to the nearest whole number unit. This is a policy decision and is properly displayed on the customer's receipts.

Referring to Figure 38, the point-of sale system advances to message menu 3800 if the charge key 3650 is pressed. Message menu 3800 informs the user that he/she should swipe the credit card though the attached magnetic card reader 130. If the magnetic card reader is successful, the customers credit card information will appear in window 3910. Moreover, the point-of-sale system 100 will provide a message in window 3920 that indicates the magnetic reader was successful in reading the credit card. The user enters the amount to be charged to the credit card via keypad 3950. Once the correct amount has been entered, as shown in window 3960, the user presses the enter key 3940. A receipt for the credit card transaction is automatically produced once the enter key 3940 is pressed. At any time, the user can cancel the transaction by pressing a cancel key 3970.

Referring to Figure 40, the point-of-sale system 100 advances to message menu 4000 if the magnetic card reader 130 has failed to read the credit card.

Message menu 4000 requests that the user try to swipe the credit card through the magnetic card reader 130 again. Referring to Figure 41, if the magnetic card reader fails after three attempts (a design parameter), the user is prompted with message menu 4100. Message menu 4100 informs the reader that the credit card cannot be read, and that he/she should enter the information manually. Manual entry is selected by pressing a manual entry key 4110.

Referring to Figure 42, the manual entry menu 4200 is displayed. Menu 4200 provides a summary window 4210, a keypad window 4220, a message window 4230, and a services window 4240. The summary window 4210 displays the current sales and balance totals, as well as the currency currently being used. The message window displays a message that indicates that the credit card number should be entered. The user enters the credit card number via the keypad 4270. The entered credit card number is visible through a window 4265. If a mistake is made, the user is provided with a backspace key 4275 or a clear key 4280. Once the credit card number has been entered an enter key 2350 is pressed. The user is also provided via services window 4240 a cancel key 4250 and a previous screen key 4260. The user can press the cancel key 4250 if, for example, the customer decides to pay with another form of currency. As with past menus, the previous screen key returns the user to the previous screen - in this case menu 3800.

Once the credit card number has been entered properly, the point-of-sale system 100 advances to menu 4300. Menu 4300 provides an information window 4320 that displays the credit card information (i.e., credit card name and account number). Menu 4300 prompts the user via a window 4310 to enter the expiration data of the credit card. The expiration date is entered via keypad 4330. Once the correct date has been entered the user presses the enter key 4340. As with past menus, a backspace key 4350 and a clear key 4360 are also provided. If an invalid expiration date is entered, the point-of- sale system 100 prompts the user with a message in a window 4310. The message indicates that the entered expiration date has expired. Once the expiration date has been entered, the user is presented with menu 3900 for entry of the amount to be charged. As with non-manual mode, a receipt for the credit card transaction is automatically produced once an amount has been inputted and the enter key 3940 is pressed.

If traveler check payment is chosen (via menu 3600), the point-of-sale system 100 advances to menu 4400. Menu 4440 requires that the user enter via a keypad 4410 the amount of payment. The amount appears in a window 4420. Once again, a backspace key 4430 and a clear key 4440 is provided. Once the correct amount has been entered, the enter key 4450 is pressed. Note that a change currencies key 4460 is also provided. The customer might want to make traveler check payments in a different currency then the currency used in previous payments. As such, the user can advance to menu 3100 if a change in currency is desired. Once the change of currency is registered (as shown in window 4470), the point-of-sale system 100 returns to menu 4400.

Menu 4500 is analogous to menu 4400 except for payment by voucher. Oftentimes, airlines provide paying customers with vouchers that can be redeemed for products. These vouchers are an acceptable form of payment, and menu 4500 is provided for this type of payment. A detailed description of menu 4500 will not be given for the sake of brevity.

Once payment has been completed (whether by cash, credit card, travelers check, or voucher), the point-of-sale system 100 advances to menu 4600. Menu 4600 provides a summary window 4610, a message window 4620, and a selection window 4630. As with previous menus, summary window 4610 provides a summary of sales information (i.e., number of items purchased), balance due, and the currency being used. The message window 4620 provides a message relating to the next sale key 4640 and the print receipt key 4650. The message indicates that the next sale key 4640 should be pressed if the user wants to end the current order and begin a new order (e.g., with a new customer). The message also indicates that the print receipt key 4650 should be pressed if the user wants to print a receipt for the current order. Both keys are provided in the selection window 4630.

If a cancel order key is pressed on any of the previous menus then the point- of-sale system 100 advances to cancel order menu 4700. Cancel order menu 4700 provides a summary window 4710, a message window 4720, and a selection window 4730. The summary window 4710 provides information regarding the number of items sold, amount to be refunded (if any), and the current currency. The message window 4720 provides a warning that confirmation of the previous request (i.e., cancel order) will cancel the entire order. The message window 4720 also provides the additional message that the user should press the confirm key 4740 to cancel the order or the previous screen key 4750 to return to the previous screen.

Once all sales are complete, the user returns to menu 1100 using the appropriate previous screen keys. Once again, the user has a choice between the pre-sales key 1110, the sales key 1120, the post-sale key 1130, and the adjustments key 1140. If the user selects the post-sales key 1130, the point-of- sales system advances tosinenu 4800. Menu 4800 provides an inventory key 4810, an end-of-flight reports key 4820, and end-of-flight closing key 4830.

End of flight inventory is able to be displayed and printed by selecting the inventory key 4810. If the end-of-flight reports key 4820 is pressed, the point-of-sales system advances to menu 4900. Menu 4900 provides a message window 4910 which states that the user should press a print key 4910 if he/she wants to print the end-of-flight summary. The message also indicates that the user should press the previous screen key 4930 to cancel the request.

Returning to menu 4800, if the user presses the end-of-flight closing key 4830 before d e before the end-of-flight inventory and end-of-flight reports are printed then the point-of-sale system 100 provides the message shown in menu 5000 (Figure 50). If, on the other hand, the end-of-flight closing key 4830 is pressed after the end-of-flight inventory and reports are printed then the point- of-sale system 100 provides die message shown in menu 5100 (Figure 51). Menu 5100 states a warning that the end-of-flight closing will close the current flight and turn the computer off. The user can confirm his/her actions by pressing the confirm key 5110 or cancel his/her actions by pressing the previous screen key 5120.

Returning to menu 1100, the user can enter adjustments (e.g., damages) to inventory by pressing the adjustments key 1140.

While the invention has been particularly shown and described with reference to preferred embodiments thereof, it will be understood by those skilled in the art that the foregoing and other changes in form and details may be made therein without departing from the spirit and scope of the invention.

Claims

What is claimed is:

A point-of-sale system for ordering at least one item having a computer electronically interconnected to a memory device and a display device, comprising: a handheld, programmable computer having a touch-sensitive screen; a user interface, accessible via said touch-sensitive screen, comprising, (a) first means for providing bond store services including managing, updating, and accessing information related to a bond store, said first means supplying pre-flight services and post-flight services; and (b) second means for providing inflight services including managing, updating, and accessing information related to inflight sales of items, said second means supplying pre-sales services, sales and payment services, adjustment services, refund services, and post-sales services.

2. The system of claim 1, wherein said user interface includes a window platform adapted for interfacing a plurality of objects, said plurality of windows including: an inventory services object, a currencies object, and a keypad object.