WO2002017058A1

WO2002017058A1 - A user interface management system and method

Info

Publication number: WO2002017058A1
Application number: PCT/AU2001/001070
Authority: WO
Inventors: David Swift; Patrick Bettels-Blume; Elissa Doyle; David Johnson
Original assignee: XERTS INTERNATIONAL Ltd
Current assignee: XERTS INTERNATIONAL Ltd
Priority date: 2000-08-25
Filing date: 2001-08-27
Publication date: 2002-02-28
Anticipated expiration: 2003-02-25
Also published as: WO2002017155A1; WO2002017156A1; WO2002017060A1; WO2002017059A1

Abstract

The present invention relates to a user interface management system for use by a system administrator providing relatively high skilled administrators with the ability to provide low skilled operators with the facilities to develop and/or modify the visual aspect of a user interface. The system includes a means to create available items for display in a user interface development system and subsequent inclusion by an operator in the visual aspect of a user interface, the creation of available items including generation of an object to represent the item, the object comprising attributes that are selected by the system administrator and associated with the object.

Description

TITLE

A user interface management system and method.

FIELD OF THE INVENTION

The present invention generally relates to a system and method of user interface management and more particularly, to the provision of a user interface development environment for an interactive system that allows an operator to define the user interface presented to customers for the purpose of ordering goods and services.

BACKGROUND OF THE INVENTION

Computerised ordering systems that allow customers to order goods and/or services have been proposed but typically, these systems are operated by service staff who accept the order from the customer and operate the ordering system to place the order for the desired goods and/or services. Usually, service staff undergo training in order for them to obtain the necessary skills to effectively and efficiently operate such an ordering system.

Other systems have also been proposed where the customers operate a component of the computerised ordering system to directly place an order without the necessity of intervention by service staff. However, these systems are less common as they are generally considered to be too expensive for most environments that accept and process customer orders.

Computerised ordering systems comprise many advantages for customers seeking to order goods and or services. Generally, the primary advantage in these types of systems is obviating the requirement for a customer to relay their order through a human operator, this process possibly involving delays whilst waiting for available staff to record the order and is subject to human error.

The high cost of computerised systems for collecting and processing orders generally results in the system being considered economically unjustifiable in many environments. In this respect, the two major cost components are the initial capital investment in the system and the ongoing cost for technical support. In the instance of an ordering environment where the items that may be ordered may change frequently, the cost of technical support to regularly ^• update the system to reflect new offerings becomes significant. For example, in a restaurant where items on the menu may change on a weekly basis, the cost of technical support for highly skilled operators to adjust the menu of available food items may incur substantial cost.

Accordingly, it is an advantage of the present invention to provide a system for the management of a user interface and operation by a relatively highly skilled operator such that the-necessary items and facilities may be provided to a relatively low skilled operator to enable that operator to construct and/or modify a user interface thus avoiding the requirement, and hence cost, of highly skilled operators to perform such tasks.

The present application is one of a five co-pending applications describing an interactive ordering system and the development and management thereof, the system having application in environments such as a restaurants, hotels, casinos and so on. For a full description of the system, the reader is referred to these five co-pending applications by the same applicant that relate to different aspects of the system:

"A video and video management system for navigation through a user interface system". This aspect of the system enables the user to navigate through a hierarchical menu structure used in providing the user with selectable indicia.

"A user interactive system and method comprising profiles". This aspect of the system provides users with a choice of indicia that may be in a form of graphical images relating to their language and/or customs, whilst remaining transparent to the rest of the operating system.

"An interactive ordering and management system and method". This aspect of the system enables management of user orders and requests and provides information to the system operator.

"A user interface development system and method". This aspect of the system relates to the development of the user interface by subsequent use by users seeking to submit orders and requests. In particular, this aspect provides the ability for relatively low skilled operators to develop and/or modify the visual aspect of a user interface.

"A user interface management system and method". This aspect of the system relates to the management of the user interface development system thus providing relatively high skilled administrators with the ability to provide low skilled operators with the facilities to develop and/or modify the visual aspect of a user interface.

Thus the present invention relates specifically to "A user interface management system and method". The contents of the other four co-pending applications are intended to be incorporated within the present specification by reference thereto.

SUMMARY OF THE INVENTION

In one aspect the present invention provides a user interface management system for use by a system administrator including a means to create available items for display in a user interface development system and subsequent inclusion by an operator in the visual aspect of a user interface, the creation of available items including generation of an object to represent the item, the object comprising attributes that are selected by the system administrator and associated with the object.

In an embodiment, items may be formed from an aggregation of objects, each object including any one or more of the following attributes, or any combination of one or more of the following attributes:

Graphical images;

Text; or

Sound;

the attributes being selected by a system administrator at the time of creating an item.

Preferably, a system administrator is provided with the facility to determine the availability of items for inclusion by an operator in the visual aspect of a user interface. The system administrator may construct blank templates of the visual aspect of a user interface for subsequent completion by an operator, the system administrator associating items with templates thus determining the availability of items for use by an operator.

The user interface management system may also include a means to define a placeholder designating a specific region of the visual aspect of the user interface into which an available item may be located. In this embodiment, the system administrator may be provided with a list of pre-defined placeholders. The system administrator may also classify placeholders according to the types of available items that may be located in the placeholder.

In a preferred embodiment, a system administrator may associate a first placeholder with at least one additional placeholder and may prevent additional placeholders being displayed to an operator until an appropriate item requiring additional placeholders is located in the first placeholder. In this embodiment, placeholders may be defined within a template.

In creating available items, a system administrator may select at least one graphical image to be displayed to an operator upon location of an available item in a placeholder to provide an indication to the operator of the success or otherwise of the location of the item in the placeholder. The system administrator is provided with a list of available tests that may be applied upon location of an item into a placeholder, selection of an available test causing that test to be applied upon location of an item into a placeholder and display of the appropriate image indicating the success or otherwise of the applied test. The system administrator may also select when tests will be applied. Such tests may include checking the accessibility of object attributes.

In another embodiment, the system administrator may create functions for display to an operator for selection and association with an item located in a placeholder. In addition to the pre-defined attributes of an item, the system administrator may also determine a list of available sounds that may be used by an operator to associate with items located in a visual user interface.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate an embodiment of the invention. In the drawings:

Figure 1 is a schematic diagram of a database used in a preferred embodiment of the present invention illustrating the database tables;

Figure 2 illustrates the "advertising" tables of the database;

Figure 3 illustrates the "category" tables of the database;

Figure 4 illustrates the "image and sound" tables of the database;

Figure 5 illustrates the "profile" tables of the database;

Figure 6 illustrates the "ordering items" tables of the database;

Figure 7 illustrates the "maintenance" tables of the database;

Figure 8 illustrates the "restaurant table" tables of the database;

Figure 9 illustrates the "system information" table of the database;

Figure 10 illustrates the "sound theme" tables of the database;

Figure 11 illustrates the "screens and buttons" tables of the database;

Figure 12 illustrates the profile tab of the User Interface Utility screen;

Figure 13 illustrates the visual and audio maintenance tab of the User Interface Utility screen; Figure 14 illustrates the system maintenance tab of the User Interface Utility screen;

Figure 15 illustrates the File option menu of the User Interface Utility screen;

Figure 16 illustrates the system configuration window of the User Interface Utility screen;

Figure 17 illustrates the User Interface Utility screen when being edited;

Figure 18 illustrates the Category Image Assignment window of the profile maintenance of the User Interface Utility;

Figure 19 illustrate the list of category images available under the Edit Category selection of the profile maintenance of the User Interface Utility;

Figure 20 illustrates the time period maintenance screen of the profile maintenance of the User Interface Utility;

Figure 21 illustrates the screen editor of the profile maintenance section of the User Interface Utility;

Figure 22 illustrates the screen editor in relation to a transmit screen;

Figure 23 illustrates the buttons for a navigation screen;

Figure 24 illustrates creating a new button for the navigation screen;

Figure 25 illustrates the Item Type Maintenance form of the Visual and Audio Maintenance of the User Interface Utility;

Figure 26 illustrates the item Sub Types form of the Item Maintenance form;

Figure 27 illustrates the Image Maintenance form of the Visual and Audio Maintenance of the User Interface Utility;

Figure 28 illustrates the Image maintenance form for a product background; Figure 29 illustrates the Sound Theme form of the Visual and Audio Maintenance of the User Interface Utility;

Figure 30 illustrates the File Import form of the Visual and Audio Maintenance of the User Interface Utility;

Figure 31 illustrates the Remove files form of the Visual and Audio Maintenance of the User Interface Utility;

Figure 32 illustrates the XOS Category Editor form of the System Maintenance of the User Interface Utility;

Figure 33 illustrates the XOS/Micros Category Assignment form of the System Maintenance of the User Interface Utility;

Figure 34 illustrates the Table Maintenance form of the System Maintenance of the User Interface Utility;

Figure 35 illustrates the Table Colour Maintenance form of the System Maintenance of the User Interface Utility;

Figure 36 illustrates the colour selection of the Table Colour Maintenance form;

Figure 37 illustrates the Product Maintenance form of the System Maintenance of the User Interface Utility;

Figure 38 . illustrates the Screen Type Editor form of the System Maintenance of the User Interface Utility;

Figure 39 illustrates the Button Types form of the System Maintenance of the

User Interface Utility;

Figure 40 illustrates the selection of the sound type of the Button Type form;

Figure 41 illustrates the System Information form of the System Maintenance of the User Interface Utility;

DESCRIPTION OF A PREFERRED EMBODIMENT The following detailed description of an embodiment of the invention refers to the accompanying drawings. Although the description includes exemplary embodiments, other embodiments are possible, and changes may be made to the embodiments described without departing form the spirit and scope of the invention.

The present invention is well suited to the management of a user interface of an interactive ordering system for a restaurant or cafe environment where customers place orders for food and/or beverages. Of course, the invention is also suited to other environments such as hotels, supermarkets, airport terminals and the like where customers place orders for goods and/or services. In the example of a hotel, customers can usually order a range of services including room service, entertainment (such as in-house movies) and information services relating to events or places of interest in the vicinity of the hotel.

In the preferred embodiment, customers, or users, are provided with an ordering system which includes a visual display and a selection means enabling customers to select items from the visual display. Visual displays incorporating a touch sensitive selection means such that customers may touch the display in a region corresponding to a displayed item in order to select that item have been found to be particularly intuitive and relatively easy for customers to understand and use. This type of arrangement is also preferred by those with physical disabilities who may otherwise experience difficulty operating other type of selection means such as a mouse device as used with most personal computers.

Whilst ease of use of the ordering system interface is important for customers, it is an advantage of the present invention to provide a user interface development environment enabling an operator of the user interface development system, such as a food and beverage manager of a restaurant or cafe, to develop and edit the user interface that will be presented to customers without the requirement for that operator to undergo extensive training to require new skills. A system according to the present invention is likely to be operated by a highly skilled practitioner, however, it enables the highly skilled practitioner to create a user interface development system that may be operated by a low skilled operator for the purpose of creating and/or editing a user interface presented to a customer thus enabling the operator to perform those tasks without the requirement of referring to a relatively high skilled practitioner. Database Description

Detailed in Figure 1 is a schematic of the typical tables used in the database of the present example. Each of the necessary tables will be discussed in more details in the following section, where they are divided into logical sections. The database is used to run the XOS (Xerts Ordering System), the host podium and the transfer of information to and from existing kitGhen databases such as Micros.

Advertising Tables

Figure 2 details the advertising tables used in the database. Before we describe the advertising tables it is important to understand how the advertising works. Advertising is in the form of messages that appear on the screen to the user, usually in a select area of the screen, the content of which can change depending on the screen that the user is accessing at the time.

Advertising is divided into profiles. Each advertising profile may be assigned to a XOS profile. Therefore, one may have an advertising profile for Japanese which links to a XOS Japanese profile. One may also have an advertising profile in English which links to an English XOS profile. There can also be children's advertising in a children's profile and so on.

Within an advertising profile the operator of the User Interface Management system may specify when and where a particular set of advertisements are played. A set of advertisements is called an advertising group. This is made up of several individual advertising images.

For example, a particular advertising group may be made up of five images. If these images all relate to a product such as beer, then there is a beer-advertising group. The operator may then specify when and where in the database, in the XOS, the particular beer group appears. For example, the operator may select that the beer group may only be viewed at dinnertime and only when the user selects a beverage screen. The operator may also select the beer group to be shown all day but only in the beers and sodas screen. This level of flexibility does make the table structure somewhat complicated. In the preferred embodiment, advertising uses the following five tables; advProfile 10 (advertising profile), advGroup 12 (advertising group), main_advGroup 14 (maintenance of advertising group), advlmages 16 (advertising images) and advTimePeriod 18 (advertising time period). First we begin with the advertising profile 10. As described previously, an advertising profile is made up of all the different advertising groups for this particular set. For example, there may be an advertising profile for children or one for another language. In this table there is simply a profile ID 20, and a description 22, the description being the name of the profile.

The advertising time period table 18 as mentioned above allows one to select when a particular advertising group is displayed. For example, the operator may want the beer advertisements to be displayed at lunchtime. These particular time periods are calculated in the advertising time period table 18. It is important to note that for the preferred embodiment, the total of all the time periods must cover a twenty-four hour period of time but must never overlap. In the table there is a time period ID 24 that is the primary ID followed by a description 26. The description is simply used in the User Interface Utility to allow the operator to distinguish between time periods. There is then a start time 28 and an end time 30. As an example, lunch may be the description, with a start time of 11:30 and an end time of 14:00 hours.

As mentioned above, a profile is made up of several advertising groups. Each advertising group, for example beer, is made up of several advertising images. The advertising images table 16 has several entries that are all primary keys. The advertising group ID 32 may link this particular image to the beer. The image ID 34 is a foreign key link to the image catalogue and gives the ID of the particular advertisement that the operator may wish to show. For example this may be a Brand X beer. The play order 36 allows the operator to choose where in the group they wish this particular Brand X advertisement to play. If it is to be played first the operator enters 1 (one). To play it fifth, the operator enters a five (5). It is important to note that for the preferred embodiment, the number must run in order with no gaps. This rule is maintained in the User Interface Development System. Using these three values as the primary key, the operator can have the same image appear many times in the particular group. For example the Brand X beer may appear as advertisement one and as advertisement five in this particular group.

The groups are given a particular name in the main advertisement table 14. Like other maintenance tables described in the maintenance system the group is given a group ID 38 and a description 40. This description is simply used in the content management system to allow the operator to distinguish between groups. In the beer example the operator would enter the unique primary key followed by beer. All the advertising images would then have the same group ID as beer but they would have separate ID's and group order until the group is filled. The size of the group is not fixed.

The advertising group table 12 has four values for the primary key, the primary key being signified by the key symbol (42). This allows the flexibility of allowing a group to be in a profile, for a specific time and for specific positioning in the XOS. First in the advertising group table is the group ID 44. Considering the beer example, this would be the foreign key link to the beer group in the maintenance advertising table 14. Next is the profile ID 46 for the advertisement group. As mentioned previously an advertisement profile is made up of several advertisement groups therefore each group must be given a particular profile ID. A group may however belong to several profiles. The operator can select for a product, which may be associated with a particular profile ID such as adults, the time period ID 48, namely when they want the beer to be displayed. Once again the operator selects from the foreign key in the advertisement time period table 18. Thus, in the example of a beer in the adult profile, beer may appear in several different time periods; one therefore simply creates a new record for each time period in which the beer group appears.

The final part of the link is the category JD 50. This is a foreign key link to the category part of the category table (discussed later). Each screen is given a particular category that may already be used in existing systems, such as the well known Micros. If the Micros category of a screen matches the category of this record in the category ID 50, the operator knows to display this particular group of advertisements if the time period and profile also match. This then allows the operator to say that beer in the adult's profile when available at lunchtime will be shown in the screen that has beers and sodas, Beers and sodas having its own category ID. As with time periods, one may show in different category ID's the same group. For example if one wanted to show beer in an all drinks screen at lunchtime one needs to create a new advertising group record for each drink category ID, leaving the group, profile and time period the same. Different category ID's apply to wine, soft drinks, cocktails, etc.

For a particular group in a particular profile at a particular time and a particular category, in our example for beer, in our adult profile at lunchtime, on beers and sodas, the operator must select a ratio 52. The ratio is very important in the preferred embodiment as not every screen in the XOS will relate to a Micros category ID. For example, the Home screen is not related to the Micros category ID and neither is the transmit screen. Therefore whenever a category ID is not available for a screen one shows the system category. The system category has a category ID of negative one (-1). The system advertisements in the system category will display whenever there is either

(a) no category for the particular screen; or

(b) there is a category for the particular screen but there is no matching group for that particular category.

For example, there may be a screen with a category of entrees, but no entree specific advertisements. In this scenario the operator may display the system advertisements. The ratio allows arrangement for a particular beer profile, for a beer in the adult profile at lunchtime for beers and sodas menu the operator wants to show either all beer advertisements or 50% beer and 50% system. If 50/50 is selected a user will first see a beer advertisement followed by a system advertisement, followed by the next beer advertisement with each advertisement displayed for approximately the same period of time.

The field "isRandom" (54) provides the order in which advertising images within an advertising group are to be displayed. If "isRandom" is true when the records are first returned to the XOS they will be randomised. They are only randomised once per XOS session. This ensures fair play for all advertisements. If it is not random then they are simply played in the play order specified in the advertising images.

Category Tables

Categories use the following tables; Category 100, XOSCategory 102, XOS CategoryMicros 104 and XOSCategorylmage 106.

As illustrated in Figure 3, the category table 100 is a list of all categories 108 stored within existing restaurant or kitchen operating systems such as that referred to as Micros. The category name 110 details are imported directly from a system such as Micros and may not be edited by the operator. Next there are the XOS categories 102. When a user orders items in the XOS they are grouped by category. These categories are usually drinks, mains, desserts and so on. They can be rather large groups but are seen in the bottom left hand side shopping cart of the order screen and is also how items are grouped in the transmit screen. For a XOS category there is a primary key 112, a description 114, this description being solely for use in the XOS User Interface Development System and is never seen in the XOS, and also a display order 116. The operator sets the display order for all XOS categories. This tells the XOS which order to display the items both in the shopping cart in the bottom left hand corner of the order manu and also in the main transmit page.

The XOSCategories 106 are linked to Micros Categories using the XOSCategoryMicros table 104. This is a link with just the category ID 118 and the Micros category ID 120 forming the primary key. For a XOS Category there is a XOS Category Image. The XOS Category Image is actually an image set made up of two images. The first is the image that displays in the bottom left hand shopping cart area, and the second one is the one that displays in the transmit screen. There needs to be a separate XOS Category ID 122 for each profile 124. This is so that the system may provide, for example, a Japanese version of these categories in a Japanese profile and an English version of the categories in an English profile. Thus for each XOS category in each profile there is an image set 126 which is an image set of the two previously mentioned category ID's.

Image and Sound Tables

The following section provides a description of how images and sounds are stored in the Xerts database and is also illustrated in Figure 4. In the XOS there is no text and everything is stored as a graphical image. The only text that one may see is the prices on the product. This is because the prices may change and one does not want to re-create graphics every time a price change occurs.

In order to store all of the images and sounds within the Xerts database we use the following four tables; CatalogEntryType 200, CatalogEntrySubType 202, SoundCatalog 204 and ImageCatalog 206.

The CatalogEntryType stores the information of a set of images or sounds, that is, an image name or a sound name. Here a primary key 208 is followed by the number required 210 which gives the total number of images or sounds within a current set. Note that a set may be images or sounds, but it may never be both in the preferred embodiment. There is also provided a description 212, which is solely used for the User Interface Management System so that the operator can see which fields they are editing. We also have a media type 216, which is where we find out whether it is a sound or an image. So for a set one basically stores how many images or sounds are within the set, a basic description of the set and also whether the set contains images or sounds. The media type will be an I or an S indicating an image or sound respectively.

The CatalogEntrySubType table 202 contains information about each individual image or individual sound within an image or sound set. There is a foreign key link 218 to the CatalogEntryType. There is a sequence ID 220, for example, type A may have sequence ID 1,2,-3 which is because the "num. required" field tells us we only need three records. There is also a description of this particular image type 222 and the file extensions 224 that this image type extension may use, for example, an image of this sub-type must be either a JPEG or an MPEG or if it is a sound it must be a WAV file. A location 226 of this particular subtype may also be stored. This will be an X for a server or a C for a client.

So for each set of images or set of sounds there is information about each individual image or sound within the set. A quick example may be as follows. In the XOS one shows products on the menu screens. The product button is actually made up of four individual images, therefore the number required is set at 4, the description would be a product and buttons and the media type would be an I because it is an Image. There is a catalog entry sub type for each button within this particular products button. The first button within a products button is the deselected image. That is what the button looks like before a user selects it. So for type ID product button there will be a first image with a description of de-selected and in the example, it must be a JPEG. The location will be on the client. In the preferred embodiment, most images and sounds are stored on the client as it is considered to be more stable and has more computing power as compared with the server. The second image which will be the type ID of the product button, type sequence ID of 2, is the selected image, that is, it is the graphical image when the user has selected that product. So the description will be "selection". Once again, in the example, this can only be a JPEG and one enters JPEG on the extension and enters a location of Client since it will be stored on the Client.

There is also a third image so the type ID is once again the same as the product button, the type sequence ID is 3 and the third image is the large image so one types large image into the description. This is the image that is displayed in the centre of the XOS ordering screen whenever the user selects a product button. Next is the file name extension. In the case of the large image this may either be a JPEG or it may be an MPEG, so these can be entered in a semicolon-delimited list. Once again the operator enters the location. It is important to note for the preferred embodiment that even though there are two different file types they must always come from the one location.

Finally for the product button there is a fourth image therefore the type ID is once again the product button, the type sequence ID will be number 4 and the description will be "selection screen image". This image is the one that will appear on the selection screen when a user selects the transmit button. The file extension would be JPEG and once again the location will be on the Client.

Therefore, for each CatalogEntryType, which is a set of images or sounds, an operator is provided with the details of each image or sound within the set.

The system then uses the ImageCatalog 206 or the SoundCatalog 204, which is dependant on whether the CatalogEntryType is an I for an image or an S for a sound. If working with an image, the operator first enters an image ID 228 which is simply a unique number followed by the image sequence ID 230, in the case of a product described earlier one would have the same image ID four times with the image sequence ID being 1,2, 3, 4 each time. It is this image ID and sequence ID that make up the primary key. One then links to the type of image 232. This type of image is the type of set as described in the CatalogEntryType defined by the type ID. Then there are the physical file names 234 which are simply the file names from which one can access the file and the system category 236. The system category may not need to be used but if it is, the system category ensures that any amendment or changes made by the system administrator or by the programmers can be tracked. That is, it is a category that tells you whether the particular row of the database that was amended was entered by an operator or by a developer.

For sounds this is very similar to the images. There is the sound ID 238 and a sound sequence ID 240, for example the sound ID 4 may be used three times for sound sequence ID 1,2 and 3. This makes up the primary key. As with images, there is also the type ID 242, which is the CatalogEntryType, the physical file name 244 and system category 246.

Profile Related Tables

Each session of the XOS runs in a particular XOS profile. That is every screen that appears in the XOS and every button within every screen is related to that particular profile. This allows the operator to have different versions of the XOS for different customers, for example, a children's version, an adult's version, an English version and a Japanese version. There is no limit to the number of profiles that may be created. To change languages, an operator may simply enter a new profile and select images from that profile where the image includes a graphical representation of text in that countries' language. For example, there may be a Japanese version of all the buttons. To work with profiles, the database includes the Profile table 250, Profile_TimePeriod table 252 and TimePeriod table 254. We consider each of these in turn, first considering the Profile table and referring to Figure 5.

The Profile has a unique identifier 256 followed by its description 258. This description of the profile may be displayed in the User Interface Management System. It may also be displayed in the User Interface Development System when an operator selects which profile they wish to edit, and it may also be displayed in the Host Podium system. When a waiter assigns a table to customers they must select the profile that the XOS will be running. It is the descriptions in this table that will be displayed thus detailing a list of available profiles.

The start-up screen 262 is the screen LD to a screen that appears when the XOS first starts up. Next is the sound theme ID 264 and which will be discussed further below. However, the sound theme ID that is selected here will apply to all buttons in the XOS. Next there is the is Valid 266 field. As there are so many things that may be changed in a profile it is easy for a profile to become invalid. For example, missing screens or missing images. Therefore in the User Interface Development System whenever an operator makes a change in the example of the preferred embodiment, they must re-validate the profile. If they have not re-validated the profile or have re-validated it but it failed that particular profile will not be available in the list in the Host Podium system. Therefore, in the preferred embodiment, the XOS may never run with an invalid profile. Finally, the advertising profile ID 268 is a foreign key link to the advertising profile table. This indicates to the operator which sets of advertisements will be running for this particular profile of the XOS. For example if there was a children's profile, different sets of advertisements could be displayed as compared with an adults profile. In this particular instance, a children's profile will not include advertisements for alcohol.

The Profile_TimePeriod table 252 provides a list of all the profiles and the time periods for which each profile is valid. Before describing this further we first need to consider the TimePeriod table 254. The TimePeriod table is a list of all time periods 270 for which the restaurant is open, divided into segments. There is a start time 272, an end time 274 and a description 276. The description is solely used for the Management system. Common time periods may be breakfast, lunch and dinner. The ProfileTimePeriod table has a profile LD 278 and a time period ID 280, therefore one can say that this particular profile is valid during lunchtime only. It is important to note in the preferred embodiment, that even if a profile is invalid for a time period ID the operator may still select it in the Host Podium system, it will just appear as a different shading or colour. Time periods are used as a recommendation only and may not be enforced when accepting orders from a user.

Ordering XOS Products Tables

In order to understand how items are ordered through the XOS and then transferred to Micros at the following three tables need to be considered, namely; XOS_OrderJtems 300, POS_Order_Items 302 and POS_Batch 304, detailed in Figure 6.

Firstly, considering the XOS DrderJtems table, this table has the primary key of the transaction ID 306, which is a unique identifier. For each product ordered by a customer which has not yet been sent to the kitchen, that is the order will still appear in the transmit screen, the XOS stores a number of parameters. These include the table ID 308, that is the table that ordered the product, the product ID 310, that is the product that has been ordered, and the Condiment LD's 312, that is a string containing any condiment ID's that have been ordered for the product. For example, if a user ordered a Caesar's Salad as the product ID they may have condiment ID's for bacon, chicken and anchovies.

The item status field 314 is used when the customer views the transmit screen and where they may change the status of a product selected from "cleared" to "not cleared", that is, they may delete previously selected items they no longer wish to consider. When they delete any item the item status is changed in the table. The system also stores the date and time 316 that the customer ordered the item.

When the customer selects the transmit button, items are transferred from the XOS into the Order Manager (the POS_Order_Items and POS_Batch tables being used). All the items that are sent when the customer presses the transmit button are collated into a batch. For this batch the XOS stores a primary key batch ID 318 that is simply a unique identifier, the table LD 320 that identifies the table from which the batch originated, and also the batch time and date 322 that the batch was sent. This table also stores a value for batch transferred 324 that indicates if this batch has been sent through to the Micros system.

For each batch the XOS stores the information for each particular product that has been ordered. Many of these fields are simply duplicated from the XOS_Order_Items table. First there is the batch LD 326, which is the foreign key to the POS_Batch table. The transaction ID 328 is the same transaction ID as in the XOS_Order_Items table as are the product LD 330 and condiment ID's 332. When the waiter uses the Order Manager System, they must clear items before they can be transferred into Micros. If an item has been cleared and is ready for transfer it is stored as the item cleared field 334. Whether or not this particular product has been transferred yet is stored in the "isltem transferred" field 336, which provides information as to whether this particular product has been moved from the XOS to the Micros system. If the item has been transferred then the system stores the date and time that this item has been transferred in the "Transfer Date/Time" field 338. Once the particular XOS session has finished the information in the POS_Order_Items and POS_Batch is archived.

In summary, when a customer orders an item on the XOS, it is sent to the XOS_Order_Items table. When they actually transmit the particular orders to the kitchen the POS_Order_Items and the POS_Batch tables are used. Once the XOS session has finished, that is, the table is vacant, the POS_Order_Items and POS_Batch tables are then archived for later reporting.

Maintenance Tables

The maintenance tables in the database, as illustrated in Figure 7 are used by both the Content Management utility and the User Interface Development System. The Maint_ScreenName table 350 enables the operator to give each screen a particular name, the Maint_SoundName table 352 allows one to give each sound set a particular name, the Maint_ImageName 354 table allows the operator to give each image set a particular name whilst the Maint_ProductImage 356 is slightly different in that it allows one to4ink products to image sets.

The MaintjScreenName table is only used by the XOS Content Management Utility. It has a foreign key link 358 back to the Screens table and also a screen name field 360 and notes 362. These fields are provided so that the operator may easily distinguish between screens when working in the Content Management Utility and this is their sole purpose.

The Main_SoundName table is similar to the Main ScreenName table in that it has a foreign key link 364, name 366 and notes 368 that allows the operator to identify a particular name and any notes about each sound set that is in the database. Once again this is used in the Content Management Utility to allow the operator to easily distinguish between the groups of sounds. This information is also used in the Interface Development system. In the User Interface Development System, the operator is able to drag and drop sounds onto buttons. It is the sound name that the operator uses to distinguish between each sound set. There is also a language ID field 370, which does not need to be used but can distinguish between different languages. MaintJmageName 354 works in a similar manner as Maint_SoundName. There is an image ID 372, which is a foreign key link back to the Image catalog. The image name 374 and notes 376 are stored in the Content Management System to allow the operator to easily distinguish between the images. These image names are also used in the User Interface Development System. The User Interface Development System allows the user to drag and drop image sets therefore creating buttons on a particular menu. It is this image name that distinguishes what the image set represents.

The Main_ProductImage table 356 links an image set 382 to a product 384. For example it could link an image set that could be a product type in which it represents chocolate cake. The operator then links the chocolate cake image set to the chocolate cake product JD. This allows the system to determine which product the customer has ordered when they press a particular button on the XOS menu.

Restaurant Table Tables

The restaurant tables shown in Figure 8 hold all the information for all the restaurant tables in the Xerts database. Information about all of the tables in the Xerts restaurant are stored in the following three tables, namely, RestaurantTables 400, TableConfig 402, and Colours 404. The information in these tables is used by both the Content Management system for maintenance of the tables and by the Host Podium system, which includes the Order Management and the System Administration mode of the Host Podium system.

The TableConfig table includes a unique identifier being the table ID 406 and a profile ID 408 that determines the profile that the XOS is currently running for that particular table. For example, table 2 may be running a profile for children, table 10 a profile for Japanese tourists whilst table 8 may be running the standard XOS profile. The child lock enabled field 410 indicates whether child lock is enabled. If it is enabled then whenever the customer using the XOS tries to send information to the kitchen, that is:

(a) they try and send a food or drink order;

(b) they try and play a music video or games where the item is automatically charged; or (c) they try to either request the bill or have a request for help,

then they will be presented with a smart card locking screen. On their screen they will advised that they need to enter their smart card, confirm this action and then remove their smart card. If they complete this process correctly their request will be acknowledged, otherwise their request will be denied. The child lock code ID 412 is currently a spare field.

The food ordered field 414 indicates whether the particular table has ordered any food from the XOS. This may be important in the case where certain areas of the XOS are only available after food has been ordered. For example, the operator may not wish the customer to enter the "fun" menu until they have ordered a meal.

The table status field 416 presents the current status of a table and can indicate whether if allocated, vacant, being cleaned, out of service or reserved, etc. The "num. seated" field 418 stores information on the number of customers seated at a particular table at the current time.

The screen Pos X 420 and the screen Pos Y fields 422 are used by the Host Podium system. In the Host Podium there is provided a layout of the restaurant with the tables superimposed on that layout. The position of these tables is stored by their X and Y co-ordinates. The optional guest Name field 424, which may be filled at the Host Podium or the Order Manager, provides a store for the guest name. The comments field 426 enables comments about the particular guests seated at that table or the table to be entered by the Host Podium or the Order Manager as required. An example where this may be used is where a member of the party has a birthday. Another example is where the table may be out of service due to an XOS equipment failure. The comments field enables that reason to be stored in relation to the table so that the information is generally available.

The start time 428 is the time at which a particular table was allocated to the current guests. From this start time the system can calculate how long the guests have been seated at this particular table. The tc time stamp field 430 is used by the Host Podium and the Order

Manager systems to ensure that two different Order Managers do not update the same data concurrently. Therefore whenever the data is updated it is given a new time stamp. There are then several true/false fields. The first is a req help field 432. Whenever the customer requests help from the XOS, the required field for the reqHelp field will be set. This will then be shown in the Host Podium and Order Manager system. This also occurs when requesting a bill, which is the "req Bill" field 434. Whenever the customer using XOS requests a bill by pressing the request bill button this flag will be set. Once this flag is set the information will be shown in the host Podium and the Order Manager systems.

The card ID 436 stores the cards swiped for this particular table. The previous Status field 438 and the previous profile field (not shown) provide the status and the profile respectively that the XOS was in the previous times that it was running.

The RestaurantTable 400 has a foreign key link 440 back to the Table_Config table. The table name 442 is the name of the table and in most cases this will be a numeric number between 1 and 30 for XOS tables and then up to whatever is required for conventional tables. For example we could have table 2, table 10 etc. Although numbers is a guide one may enter any value that they want into the table name field. The field table capacity 444 is the maximum number of guests can be seated at any one table. If a table has a XOS, in the preferred embodiment, one needs to be able to link this table to a table in Micros to allow us to transfer the orders from the XOS into the Micros point of sale system. This is set by the micros table ID 446. The colour LD 448 represents the waiter responsible for the particular table.

Considering the computer name field 450, if a particular table has a XOS, the operator needs to know the network name of the computer. Usually the computer name will be equal to the table name. However, this does not need to be strictly enforced. Since a restaurant may use both XOS and conventional tables the "has XOS" flag 452 tells the operator whether the table is in fact a XOS or a conventional table. Finally the time stamp fielcf454 is the same as for the TableConfig table and its function is to stop one from over-writing other table information.

In summary, the RestaurantTable table 400 stores all of the static information for a particular table, while the TableConfig table 402 stores all of the information that will change whenever a new customer is seated at the table or whenever the table's status changes. Therefore, this is variable information whilst the RestaurantTable is static information.

Finally, there is a colours table 404. In order to allocate waiters to tables the operator allocates each waiter a particular colour. A list of all these colours is shown in this table. The colour ID field 456 is simply the primary key followed by a description 458, which is the name of the colour, for example red, green, blue. Then one has the colour value 460 that is the RGB colour value for the particular colour. The operator then assigns each restaurant table a particular colour using its colour ID 456. Therefore each table is assigned a colour and each waiter is assigned a colour. For example, all pink tables may be serviced by a waiter who has been allocated the pink colour whilst all green tables may be serviced by a waiter who has been allocated green. It is to be understood that the table allocation may be distinguished by other visual indicia such as a pattern or shading.

System Information Table

The system information table 500 illustrated in Figure 9 is used by the XOS Content Management system and also by the User Interface Development System to locate the position of all files required by the XOS. The first four fields of this one record, since this table will only ever hold one single record, provides the root to all the paths required by both the User Interface Development system and the Content Management system The file root

502 is the root of the files from the perspective of the clients - all these files being stored on a server. From this root one gets the html file path 510 which is the file path to all of the html and cold fusion pages, the ess file path 518 which is the path to all the style sheet files, the client image file path 526 which is the path to all the images stored on the clients, the server image file path 534 which is the path to all the images stored on the server, the client sound file path 540 which is the path to all client sounds, and the server sound file path 548 which is the path to all of the sounds stored on the server.

The physical root field 504 is the root for the path of the files stored on the server from the perspective of the server. The html physical path field 514 takes one--to all the html physical paths on the server, whilst the physical path to all of the style sheets is by field ess physical path 522. Similarly the field for all the images stored on the clients is by field client image physical path 530, all of the images stored on the server by field server image physical path 536, all the sounds stored on the clients, by client sound physical path 544 and all the sounds stored on the server by server sound physical path 552.

The web root address 506 allows one to access files over the web. In html web path 510 one has a path to all the html and cold fusion pages, ess web path 524 being the path to all the style sheets, to the client images being client image web path 532, to the server images server image web path 538, to the client sounds client sound web path 546, and to the server sounds server sound web path 546. There is also an additional path, which is the theatre server path 508. This gives the root path to access the theatre server. This path is not used in any other fields.

In the set of fields for each type there are four records, namely "File", "Relative", "Physical" and "Web". "File" is the access to the files on the server from the perspective of the client, the "Physical" is access to the files on the server from the perspective of the server, and the

"Web" is access to the files over the Internet. One extra path, which is the "Relative" path, is the path to the files when running the XOS. Firstly there is a relative path to get to the html directory, the html relative path 512, then a relative path to get to the ess relative path 520 storing the style sheets, the client image relative path 528 that will be the actual position of the files on the client hard drive and the server image relative path 535 that gives the relative path to access the images stored on the server. The client sound relative path 542 provides hard drive location on the client where the sound files are stored and the server sound relative path 550 indicates the relative path to all the sound files on the server.

The System table includes several additional fields. The maintenance web path 556 indicates the address from which the XOS can go to the User Interface Development system. This is because the User Interface Development system uses the XOS for navigation. The XOS web path 558 is used by the User Interface Development system to load the XOS into the original. Finally, there is a smart card number 560. All child locking in the XOS requires the entry and removal of a smart card. The identification number of a smart card is always the same, therefore the number is stored in this system information table. When a customer inserts a card, the system compares the number on that card with the number in the system information table. This ensures that the customer is actually entering a Xerts card instead of another type of smart card.

Sound Theme Tables

Understanding how sound themes work in the Xerts database used in the XOS is illustrated in Figure 10. Sounds use the following tables, SoundThemeSounds 600 and SoundTheme 602.

Firstly, there is the SoundTheme, which simply has a sound theme ID 604 and a description 606. The description is solely for use by the operator in the Content Management system so that they can easily distinguish between the sound themes. This sound theme description is also displayed for a menu in the Screen Builder utility. The sys category 608 tracks the originator of any amendments (as mentioned above).

For each sound theme 610 one then identifies which button type 612 and which sound 614, therefore there is a link back to the SoundTheme and also to our Buttons table. For example, in a particular sound theme the operator may select the button type 612 product to have the sound set of 10. An operator may then select a condiment which has a particular type ID to have a sound ID 614 of 20. Therefore any screens which apply this sound theme will have all products buttons using the sound set which belongs to sound ID 10 and all condiments on this screen with a sound set which has the sound ID 20. An operator can enter any button types into the sound LD, but must have a sound ID for each particular button type. Sound Themes are set both in the Content Management utility and the User Interface Development system. Once a sound theme has been set for a particular screen, then all new images such as products or condiments will be given the particular sound themes sounαTD for the button type ID 612 by default. It should be noted that the Sound Theme may be set for a screen and also for a profile.

Screens and Buttons Tables

To understand the screens and the buttons on the screens in the Xerts database we refer to Figure 11. Each screen in the XOS is stored separately in the Xerts database. A screen may be a separate html page or it may be a segment of video used to navigate through the menu screens. Each screen contains buttons. These buttons may be used for navigation purposes in the navigation video or to order products on a menu. Considering how an operator uses screens and buttons, the system uses the VideoTime table 620, the Screens table 622, the Button table 624, the ScreenType table 626 and the ButtonType table 628.

The primary table in this respect is the Screen table. For every single screen in the XOS there is an entry in this table. First there is a unique identifier for that table, the screen ID 630, and then if appropriate an image ID 632 for the screen. This contains the background image ID for the screen and is a foreign link to the ImageCatalog table. The image ID may be, for example, a background or it may actually contain a set of images that make up the screen. For example, when one is in the transmit screen one uses an image ED that contains all of the buttons that appear on that screen such as scrolling up and down, the transmit button, the apply changes button and so on. In the preferred embodiment, there are fifteen buttons that appear on that particular screen. However these are grouped into a single image set. Each image set has the one image ID. The sound JJD 634 is the same as the image ID. It may be a background sound that plays when a particular page is open or may be a group of sounds that are played when certain buttons in the XOS are selected. For example, when a user returns to the transmit screen LD and selects the apply changes button a sound will be played, however when the user selects the scroll up or scroll down button different sounds may play.

The source file 636 is the html file that is referenced whenever this screen is requested. For example it may be the file act-menu if one is looking at a menu page or act-navigator if one is looking at a navigation page. Below that is the style sheet file 638. If this particular screen uses an individual style sheet for example on a menu screen, mains and grills will use a different style sheet to those in build-a-burger. The operator may provide a name for the style sheet here. The category ID 640 is used in the XOS when working with advertisements. When one loads a new page in the XOS the category ID of that page is set to advertisements. If one has a particular advertising group that matches that category ID one displays the advertisements in that group. Otherwise the system advertisements will be played.

Field 642 is the profile ID and all screens belong to a profile. The child lock enable 644 screen enables the child lock facility. This file does not need to be used. The screen type ID 646 defines which particular screen a user is viewing and will be described further when considering the ScreenType table. Field 648 is the sound theme ID for this screen, which may be set either into the User Interface Development system or the Content Management utility. This is a sound theme that will apply a certain sound to all buttons on a menu screen. Finally the incidental ID 652, which relates to the LD of another screen, will be called after a random number of user selections if the incidental ID is available for that screen.

A screen may include either an individual html page or video sequence. Considering the VideoTime table 620, there is a foreign key link 654 to our screen and the table has a number of video times. If the screen, be it a video or a normal html file, has a video that must play as a user enters the screen there needs to be a video start and end time. These times are provided by the intro start field 656 and intro end field 658. This segment will usually be around two seconds and it is played whenever the user enters or leaves the screen. If this particular screen is actually part of the video, an operator is required to enter the times for when the screen starts and ends, namely, the main start field 660 and main end field 662. Finally, irrespective of whether this is a video or a non- video screen there needs to be an exit start field 664 and an exit end time field 666 whenever a video is to be played and a user indicates that they wish to exit the screen. For example, an operator may arrange a particular video sequence to be played when a user exits this screen.

Every screen has a particular type field 668 and these are stored in the Screen Type table 626. For a particular type there is a description 670. This is solely for viewing in the User Interface Management system. A list of what is required for that screen is provided. Depending on whether these are set to one or zero, being true or false, the User Interface Management system will allow an operator to enter values into these fields. For example, if we have reqBGImage 674, reqCSS 676 or require video exit 678, then those fields will be available for any entry in the User Interface Management system. It will be recognised that not all fields are relevant for all screens.

Each screen may comprise several graphical images and functional buttons and accordingly, the system needs to keep a track of all the buttons on the screen. Buttons allow users to navigate to further screens in the XOS, and also allow users to order items through the XOS. In the button table 624 there is a screen ID 670, which is a foreign link to the screen on which the button is placed. The image ED 672 indicates what image to display for that particular button, remembering that a single image ED is actually a set of images. Therefore for a product one would have an image ID which is made up of a set of four images; an image to be displayed when the image has been de-selected, an image for when the image has been selected, a large image for display at the centre of the menu and finally, an image to display when a product is ordered we need button to display on the transmit screen.

The position of the button on the screen is recorded in the pos X 676 and pos Y 678 (coordinates) fields and the height 680 and width fields 682.

The link ID field 684 indicates to the XOS which screen to call when a product image is selected by a user. For example, if a user orders a music video they select the music video button for an artist and then select the add button. The link ID indicates to the XOS which screen should be referenced that contains the ordered music video.

The parent ED 686 is used in the case of condiments. Condiments are linked to a particular food image and therefore the XOS needs to know which food images particular condiments are related to so that it only appears in the correct position in the XOS. For example, if a user selects a salad, only the available condiments for that particular salad should be displayed.

The product ED 688 indicates to the XOS which product to order when the customer selects a particular image. This is only used for product images. This product ED is used when transferring information to and from the Micros system. The sound ID 690 is the sound set thatis to be played whenever a particular button or image is selected. The sound set may have different sounds for the different states of the button. For example, for a product image there may be one sound when the product image is deselected, and another when the product image is selected.

Finally the disable if no order button 692 may be set to true or false. A user may press this button only if they have ordered an item. For example, to get to "fun" menu there is a navigational button. However, the XOS can be programmed to prevent users from accessing the "fun" menu where they can play games and watch videos etc, until they have ordered an item such as food or a drink.

Finally, there is the ButtonType table 628. There is the button type ED 694 which is a foreign key link back to the button type ED 674 in the Button table. The description 696 is used solely in the User Interface Development system to allow the operator to recognise which button type they are referencing. The system advises the operator in the User Interface Development system what image set and sound set is applicable to an image of functional button. For example, for an image type product button there are four images within the set; a de-selected, selected, enlarged and a selection screen. For a condiment button only these images are required; namely, deselected, selected and a selection screen image. Therefore we want to ensure that whenever a system operator creates a button type product they are only dragging a product button onto the screen. The correct number of images should then be provided by the system within the XOS. The same principle applies to the sounds. Therefore, for every button type the type of image 698 must be specified and the type of sound 699 that are allowed. These rules are enforced in the User Interface Development system.

The above description detailed the tables that are used in the system database. The following description details the use of various tables to set different parameters in the system. We start with the User Interface Management system which is a window seen by the system operator. The User Interface Management System

The User Interface Utility, generally referred to as the XOS Content Management Utility for the preferred embodiment, comprises a main screen 700 illustrated in Figure 12. This screen is divided into three aspects represented by the three tabs 702, 704 and 706. The first tab 702 relates to the profile maintenance and allows one to edit any details required with respect to each individual profile, Figure 12 illustrating the functions available under the profile tab.

The audiovisual maintenance tab 704 allows one to edit the images and the sounds used by the XOS. As can be seen in Figure 13, there are a total of six choices including Item Type Maintenance 708, Image Maintenance 710, Sound Maintenance 712, Sound Theme Maintenance 714, Import Files 716 and Remove Files 718.

The system maintenance tab 706 allows you to edit any system details and as shown in Figure 14 includes choices such as XOS/Micros category assignment 720, Edit XOS Categories 722, System Directories 724, Edit Table Details 726, Table Colour Maintenance 728, Screen Types 730, Button Types 732, Product Maintenance 734, Advertisement Profiles 736 and Advertisement Groups 738.

Along the top of the utility screen 700 there is a file menu 740 and a tool bar 742. When in this main area selecting File will enable one to change the database connection. It will also allow one to choose whether or not one to view images throughout the system, this being a toggle button. Further, it will also allow one to exit the system by choosing close. This is illustrated in Figure 15.

Although not all are shown in the XOS categories, the menu and the tool bar allow for other different functions. Under File (this illustrated in Figure 15) there is a close option 744 that will return one to the main menu. Under the Edit button the edit area allows one to edit a new record or delete a record. However this may also be achieved by the plus and minus button in the toolbar. A search function is also provided that allows one to move forward and backward though the records. There is also a find choice for locating records and Help simply provides help through the system.

The four arrows 746 on the tool bar enable one to scroll through the records on the grid. The first takes you to the first record, the last takes you to the last record. Back takes you back one record and forward takes you forward one record. The plus symbol 748 allows one to enter a new record enabling the tick 750 or the undo function 752 on the tool bar. The tick, as one would have thought, allows one to save changes whilst the undo cancels changes. If one selects the tick any error messages will appear at the bottom of the menu. The edit menu also allows one to save and undo. The minus button 754 will delete any record whilst the filter button 756 will allow the operator to search through the records for a specific entry.

Layout of the Profile tab

The Profile tab in the Content management Utility provides a number of options for the operator. It enables the operator to edit all the details for each profile in the XOS. Referring now to Figure 12 a list of all the current profiles is listed in the Description grid 758 at the left hand side of the window, whilst the details for that profile window are shown to the right. First there is the identifier 760 which as an arbitrary number. Besides that is a message 762 whether or not the current profile is valid, that is, whether or not it may be used in the XOS. Thus one can see that the April 2000 profile is valid. To validate a profile one presses the validate profile button 764. Then there is the description 766 which is the name of the profile that will be seen in the Host Podium and Order Manager systems. Below that is the time period 768, which is the default time period for that particular profile.

To the right there is a drop down box 770 which provides the advertising theme that may be appropriate for use with the profile. We then have three buttons. Edit screens 772 allows one to edit any screens used in the profile, that is all the screens that make up a XOS. Edit category images 774 allows one to edit the category images for a profile, that is, the images that are shown for each category in the XOS. For example the bottom left hand side of the XOS in the shopping cart and also the selection screen. The last button Validate Profile 764, as mentioned above, allows one to validate a profile.

Layout of Visual and Audio Maintenance tab

The visual and audio maintenance tab allows one to edit the images and sounds using the XOS. The first button being the Item Type Maintenance 708 allows one to edit the type of images and sounds, the second 710 the images and the third 712 allows one to edit the sounds. The sound theme maintenance button 714 allows one to edit the sound themes on the menu screen of the XOS. The import files button 716 is used to import files into the XOS whilst the remove button 718 is used remove the files that are no longer required, generally the old files.

Layout of the System Maintenance tab

This tab allows one to edit all of the system related details for the XOS. The first two buttons 720 and 722 allows us to edit the XOS categories and assign them to Micros categories. One can also edit the restaurant table details and the colours, as well as edit the product which is the assigned product imported from Micros to particular image names. This tab also enables editing of the advertising creating groups and profiles. In addition, one can edit different types of screens and buttons and finally one can edit the system directories, which contain all of the directories used by the XOS.

Changing the Database Connection

Under the File option an operator can change the database configuration. This brings up a menu choice which, as illustrated in Figure 16, enables one to change the database details that this program accesses. Including the UID 776 which is equal to the user ID, the password 778 for this SQL server I, the name of the database 780, the database driver 782, and finally the server 784 on which the database is located. Once the details have been changed choosing the OK function can set them. This then results in accessing of the new database.

Understanding the Streaming Server

The following section relates to the video graphical functions of the XOS system and describes adding an image name to the database where one of the graphics within the image name is actually a movie that will run from the net-show streaming server. Generally one begins by adding the image name in the normal process. We begin by selecting the new record button. This creates a new record that may then be filled in. Subsequently one is provided with a number of empty boxes to fill in. The first of these is the description such as a product, which has a music video and has the name training. The operator then selects an item type - in this case the Music video type. Then the system provides the operator with a dropdown box for each of the images associated with the image name. In this case the music video would have a stream next to it, meaning that this particular image may come from net-show theatre server. A known streaming Video Selector Window is then provided where the operator defines it with a filename and tests the video. If the video plays fine the operator confirms the selection and the video file name will then appear in the correct drop-down box. The other images are selected as per usual and confirmed.

Profile Maintenance

Editing a Profile

To ^"create a new profile in the XOS Content Management System using the current profile as a template the operator chooses the profile maintenance tab then selects the plus button. After a New Profile Dialogue box appears, the operator selects a template profile from the choices presented in the list within the drop-down box and which presents a list of all current valid profiles. One then selects the relevant profile and enters the relevant description. Selecting the OK button results in the system now creating a new profile that is an exact replica of the one used in the template.

To delete a profile from the system select the profile that one wishes to delete and simply choose the minus button on the toolbar. One will then be prompted to delete this profile. If one selects Yes than one will be provided with a list of all the buttons screens and videos that will be deleted when the profile is deleted. To still delete one chooses Delete Anyway.

Referring in particular to Figure 17 to edit the basic details for a profile one selects the profile to edit. To edit the description one simply clicks in the description field 766 and begins typing. Once the editing is commenced the only buttons in the toolbar that may be accessed are the tick and the undo. This allows one to save and undo any changes. One may also edit the time period 768 that this particular profile is valid for. To simply choose a different time period we select the time period shown, such a lunch. To de-select a time period we then simply unselect it. The time period for which a profile is valid is a guide only and a waiter may choose to edit this time period as they wish.

We can also choose to edit the advertising theme for this profile, as shown in the drop-down box 770. Once all the changes have been made we select the tick which saves the changed for the profile.

Before a profile is available in the Host Podium for use in the Xerts restaurant it must be valid. To validate a profile we choose the profile maintenance tab to enure that the profiles are on the front, select the profile to be validated and then press the validate button. This process may generally take some time. Once the profile validation is complete, the profile validation window is displayed. On the left hand side it will show you the status of each of the individual system of the profile that it checked. At the bottom it will tell you whether or not the profile validation has been successful. On the right hand side there is a list of all screens on the XOS. Any with the plus button may be expanded which shows further screens. In this case from Home there was one main screen for each of the main menu options. Each of these also has screens, such as the Drinks menu which itself may have other screens. The list then can continue to expand showing the buttons that are used within the screens.

Editing XOS Category Images

To edit the category images one selects the Edit Category images button 774 for the relevant profile in the XOS Management utility, after selecting a profile. As shown in Figure 18 a new window 786 will appear showing a list of all XOS categories used in the XOS. These categories appear in the bottom left hand side of the XOS shopping cart and also in the selection screen. Each of these images is actually made up of two. The first image is the one that appears in the shopping cart, the second is the one that appears on the selection screen. To edit the image that will appear for a given XOS category first select the category you wish to edit, such as the kids menu 788, which will then show the current image as kids meals and then select from the drop-down box 790 where one will see a list of all category images 792 in the database, as shown in Figure 19. Also shown in this Figure is the actual image 794 at the bottom right hand side of the window since we selected the show image button discussed earlier. To save the changes one presses the tick and simply exit the window.

Editing Profile Time Periods

To edit an available time period one selects the edit button 796 to the right of the time period area of the profile maintenance button, and wherein the time maintenance form will then appear. This is illustrated in Figure 20 where on the left there is a list of all current time periods 798. To the right there is the description 800 for the start for that period. To add a profile to the time periods, press the plus button, enter a description, such as a Morning Tea period, then enter a start time 802, such as 9:30 and an end time 804 such as 11:45. Once we have entered the details they are confirmed by pressing the green tick so that the record has now been saved. If we press edit again, we can return to the Time Period Maintenance form. Say we want to change from Morning Tea to Morning Coffee, we can do so in the description, then press the green tick and close the form once again. We can then see that the changes have been applied and Morning Tea has been changed to Morning Coffee. If we press edit again we can also delete time periods, such as the Morning Coffee period. So we press the minus button (usually pink), confirm the delete and once again exit the form. One can see that the new time period has ^"been deleted.

Editing Screens

In the layout of the edit screens window we may edit the screens for our profile including adding, deleting, or changing a screen. The Screen editor is brought up by pressing the edit screens button 772 that brings up the display 806 as shown in Figure 21. On the left hand side there is the grid 808 that lists of all screens available for this profile in the XOS. On the right hand side we see all the details of this particular screen. We have a description 810, a notes field 812 telling us when a profile was created, and whether it was created using a template. We can also enter any other appropriate notes. We also have the type of screen 814, and a ^• home screen field 817. It is important to note that this home screen field will only be available when the screen type is set to home and that only one screen profile may be selected as the home screen.

Down below there are items for a video, if appropriate. If the screen-has an introduction in the navigation video we need to enter the introduction times 816. If the screen itself is in the navigation video we need to enter the times 818 in the video that the screen that it is shown. Finally if the screen has any exit video we need to enter the times 820 of those as well.

On the right hand side we need to set the source file 822 that is used in the XOS to display this screen, a style sheet 824, if appropriate a background image 826 and a background sound 828 , also if there is a sound theme we need to select a sound theme 830. If it is a menu it will need to have a XOS category 832. This XOS category is used so that whenever any food is ordered form the menu is added to the shopping cart and also the selection screen.

We also have an option to enter the help 834 that will be displayed at the bottom of the XOS for this particular screen and also an incidental screen 836. An Incidental screen appears when the type of screen is menu and is a video that will play after the user clicks the screen a random number of times whilst in the current screen, generally between 5 and 15.

Different main types of screens include the menu, the navigation screen including home, here one can see and also the use of the background image, which is the navigation video.

Another common type of screen is the transmit screen, the screen editor shown in Figure 22. Here the background images are made up of all images required to be shown on the selection screen. On can flick through this images using the button 838 at the bottom of the Xerts image display catalogue.

The following section discusses the video times required in the Screen editor in the XOS Management utility. Depending on the type of screen working with, one may need to enter introduction, menu or exit times for a particular screen. These times refer to particular segments of the navigation video that you one may wish to play. For example when working with the introduction one may want to enter times of the navigation video that are to be displayed when entering that screen. This is usually two seconds long. If the screen itself is part of the navigation video such as the home, eat, fun, XertsTV and shopping screen, the times that the Video will play when showing that screen will need to be entered. For example, in the eat screen one can see that the particular screen runs from 50 to 70 seconds of the particular navigation video.

Finally some of the screens have exit times. The exit time is the section of the navigation video you wish to display when one is exiting a particular screen. Much like the introduction this will usually be two seconds long.

To add a new screen to a profile one first enters the edit screen of the Content Management Utility and select the plus button (usually blue). One then enters a description and any notes and then selects the screen type, such as a menu screen. Once the screen type is selected that field is disabled. If a mistake is made one has to press undo and then add any new record again.

Dependent on the screen type one will be able to enter values in some of the left over fields. For a menu, one needs an introduction and an exit time. The introduction time for this particular screen is 10 to 12 seconds, the exit from 30 to 32 seconds. One then needs to select a source file, which for the menus this will always be act_menu.cfm. A style sheet is also needed, such as the red wine style sheet. One cannot select an image or a sound for say this particular screen but can select a sound theme that will apply to all buttons on the menu, such as the first sound theme .Then one needs to apply a category, which will be wine, and a bottom pane help image. This drop-down box will show all the current help images in the database. In this case one would want help for white wine. Where appropriate one may wish to enter an incidental screen. This drop-down box will list all current incidental screens. Selecting the tick saves the screen. To delete a screen within a profile once selected one simply needs to press the minus button (usually pink).

To edit a screen one selects the edit screen button. Once in the edit screen, regardless of whether or not changes have been made, the profile has to be revalidated. This is achieved by the validate profile button as discussed earlier. One can then add, delete, or edit any of the screens in the XOS. Further explanations are given in the rest of the present specification.

Editing Buttons on Navigation Video Screens

A typical navigation screen 840 is shown in Figure 23, together with its buttons. To edit the buttons for a navigation screen within a profile one first selects the screen from the grid on the left hand side of the screen editor menu, in this case we want to edit home, then select the Edit Buttons button.

As shown in Figure 23, we see a copy on the left hand side of the screen 842 within the navigation video. It is paused on the first frame of that screen. Each of the boxes 844 represents a virtual button on the navigation video. The highlighted box 846, usually in green on a screen, is the one currently selected over in the navigation button editor. In the navigation button editor 848 we can select the screen 850 that this button links to, that is the screen that the XOS will navigate to once this button has been pressed, the X, Y, height and width 852 which are determined by dragging and dropping a new box size, and also the sound 854 that is played when the button is pressed. There is also disabling if no order option 856. When selected the user will be unable to press this button until they have ordered food or dink from the XOS. The navigation buttons may select the buttons by simply pressing on them and therefore see the details on the left hand side. One may edit and delete buttons as one would in any other screen. To create a button on a navigation screen first select the part of the video, as this is the screen that we wish to add the button to. If, for example we select home we then need to select the Edit Buttons button. Here we can see all of the buttons currently enabled on the video. They are shown by square, with the highlighted or green colour square the one currently selected. To add a new button, press the plus button and then simply click and drag to insert your button, the new button 858 shown in Figure 24 with its details shown in the navigation button editor screen on the right hand side

Once a button has been created one needs to link it to a screen, such as a training screen. We may also apply any sounds to this button and also decide whether or not this button will be disabled if there is no order. Currently Fun, XertsTV and Shop are disabled unless the customer orders food or drink. Once you are happy with the new button press the green tick and then close the window whereby we are returned to the screen editor window.

To delete a button for a navigation screen one first selects it and then simply deletes it by pressing the minus button. A confirmation menu will then appear. Press yes to confirm the deletion, and the changes will now be saved and the button deleted.

To edit a button in the navigation screen, select the button you wish to edit. The button will be highlighted and any details in the navigation editor can be changed, such as disable if no order. Simply dragging and dropping a new box over the top can change the size of the box. The changes can then be confirmed and saved by pressing the green-tick.

Visual and Audio Maintenance

Editing Item Types

An item type is the type of image and sound set used by the XOS. The edit these types press the Item Type Maintenance button 708 that will bring up the Item Type Maintenance Form 860 shown in Figure 25. On the left hand side we have a list 862 of all the different item types used by the XOS. On the right there are shown the details of each type.

For example, a condiment button image requires three items that are an image, the first item must be a selected button image, the second item must be a de-selected button image and the third item a selection screen image, all three having to be JPEG files. The condiment button sound type requires two items, it is S for a sound type, and that the first item is a de-selected sound and the second item a selected sound, both of which must be WAV files.

To add an item type presses the plus button in the Item Type Maintenance Form, enters the type description and whether or not this type will be an image or a sound. Once selected the choice is confirmed by the tick. To delete an item type first select it and then press the minus button. Then confirm the delete when prompted.

To edit an item type, select the item one wishes to delete. We can then edit the type description by entering text, and also the media type. We then validate this by pressing the tick with the changes being saved.

To edit the items within the item type, we select the edit button 864, which brings up the item sub types form 866 shown in Figure. However this will not be able to be done if the type is currently in use anywhere in the system. We add an item by pressing the plus button. We then enter a description 868 and the file extensions 870 that are valid for this item within the type. In this case it may be a JPEG file. We next indicate the location 872, that is, whether this file will be located on the Server C or Client C. Most files will be stored on the clients. To add this new type press the tick.

To delete an item for an item type select we select it, press the delete button and then confirm that deletion. Finally that form may be closed and the Item Type Maintenance Form will be re-opened, where the item types are reduced by one and the number required has also reduced by one.

To edit an item for an item type, select the edit button, which will ring up the items sub type form. We can then edit the fields in any of the fields, and validating them with the tick. The form is then closed and the item type maintenance form re-loads with the editing being updated.

Editing Images

To edit images select the Image Maintenance button 710. The data window or the Image Maintenance form 874 will then be loaded. On the left hand side there is a list 876 of all current items, in this case image names. On the right hand side there are the details for each of these images names. There is a description 878 that is usually the common description used throughout the XOS system and there are also fields for any notes 880, the item type 882 and the physical images 884 that make up the single image name.

When we have a condiments button name image, such as that shown in Figure 27 for a Burger-Cheddar cheese, the image names 884 is made up of a selected button, a de-selected button and a selection screen. In the catalog display in the lower right hand corner you lay see all of the three images, being the selected, de-selected and selection screen images.

For a product, for example a music selection, the first image is a selected image, the second is the de-selected image and the third is the large image and the fourth is the video related to this product. Thus it is important to note that the image name is actually made up of several individual images collated as a group. Using this form we can therefore add, edit or delete any image names.

To add an image name select the plus, which creates an image set to fill. First we enter a description. This is the name that will be seen when assigning images to products and when using the Screen Builder system. As illustrated in Figure 28, we create a beer background image 886 and we note that it is for training. We then need to select an item type. In this case we may for example wish to select a background image. The correct number of drop-down boxes for this particular item type will then appear. Inside this box is a list of all current images in the correct directory that are not being used by any other image name that are located in the correct position, as in the server or the client, and mat-have the same file extension as required by the item types. In this example there is only one so it is selected. You will then see the image appear in the image catalog display. Once the details are acceptable we select the tick to save and exit this form. Once the system has finished re-loading the new time will be added to the image list. To delete an image name first we select the image name, and select the minus key. This delete will need to be confirmed which will than actuate the delete.

To edit an image name, the image name is first selected. The details relating to that image are then shown on the right hand side. We can edit the fields by simply typing within them, such as the description. The item type cannot be edited, only the images within that item type. To change the item type the image name must be deleted and re-created. Once all the desired fields are changed we validate it by selecting the tick that will save the changes to the database. Editing Sound Themes

To edit a sound theme first click on the visual and audio maintenance tab and then choose the Sound Theme maintenance button 814 that will load the Sound Theme Form 888 illustrated in Figure 29. A sound theme is used on the XOS menu screens and applies particular sounds to each type of button depending on what is set in this form. For example any XOS menus using the-first sound theme, all product buttons will have PRD - set one as their sound whilst all help buttons will use the HLP - set one sounds. This ensures that all buttons of the same type on the screen are using the same sounds. From this screen one may edit, add or delete sound themes as is necessary.

To add a new sound theme choose the plus button and enter a name for the sound theme in the description field. Then, for each type of button we must select a sound. The type of button depends on which types of sounds are available for that of button. Thus, for a product button we may only select product sounds. This is because the number of sounds within a group of sound names is dependant on the type of button. To save the sound theme simply press on the tick, which is usually green. Once the changes have been save he form may be closed.

To delete a sound theme first select the required sound theme. Press the minus button and then confirm the delete by selecting yes. The sound theme will now be deleted.

To edit a sound theme first select the sound theme 890 on the grid on the left-hand side. The fields may then be edited by either typing in the files, such as the description 892, or selecting a new option form the different drop-down boxes. Once all the changes have been made we press the tick, which results in the changes being made and the sound them being updated,

Importing and Removing Sound and Images

To import files one selects the Import Files button 816. The File Import Window 894 as shown in Figure 30 will appear. At the top, the type of file to import has to be selected, such as sounds 896, images and movies 898. We then need to select where we want the images to be stored, either on the server or the clients, generally the client. We then select the drive from which the images are to be imported. Then we browse as is normal in an explorer window until we find the directory where the files are stored. Then a list of all files matching the extension listed in the select file type area of the screen. To then import all of the images you simply click on the Import button 900. We then click and drag until all of them are highlighted and press the Import button. At the bottom left hand corner a message Copy Complete! will pop up to tell us that the copy has been completed.

To remove visual and audio files we select the Removal Files button 718, which will load the remove files from 902 illustrated in Figure 31. The form allows us to delete any files that are no longer required. We first select the location 904, and whether a client or server. We then select whether we want to delete images or sounds 906. A list of the relevant files is then listed. We then select those we wish to delete and delete them 908. One will then be prompted, once per image, whether to proceed with the delete.

System Maintenance

Editing Categories

A XOS category is the category that one sees in the XOS, both in the order pad at the bottom left side of the XOS and also the selection screen. We may edit these categories by selecting the Edit XOS category button 722 that will open the XOS Category Editor form 906 illustrates in Figure 32. To the left is a list 908 of all the current categories and on the right is the description 910 for each of these categories. Selecting a category and moving it up and down using the arrows may change the display order of the categories.

To add a XOS category we press on the plus button and provide a description in the field. We may then change the display order as in which order this item will be displayed by using the up and down key, for example Training Category below entrees. To confirm press the tick, generally green.

To delete a XOS category, select the category and then simply press the minus button. Confirm deletion when prompted where the record will be deleted. When it is deleted, all other items below it in the display order will be moved up by one.

To edit a XOS category, select the category and then simply type in the description field to change the description. Once we begin to edit the category, all toolbar buttons besides the tick and the undo have been disabled. We can then move the order up or down and when happy with the changes press the green tick resulting in the changes being saved in the database. Once we have created our XOS categories they must be linked to the appropriate Micros categories. We select the XOS/Micros Category assignment button 720, which will bring up that form 912 as illustrated in Figure 33. In the left hand side there is a list 914 of the Micros categories and to the right the current XOS categories 916 assigned to the Micros one. If we want to assign cartoons to Kids we simply select it from the XOS category and then press the tick. To add, delete or edit a XOS category select the edit button, which will bring us back to the editing categories form. Once we are happy we press the tick and the changes have now been saved.

Editing Xerts Table Details

To edit the table details select the Edit table Details button 726. This will load the table maintenance form 918 illustrated in Figure 34. To the left there are the table names 920, usually their number. Please note that there is a Maint table at the bottom, which is used for the screen builder utility. To the right are details about each table including the table name 922, capacity 924, Micros ED 926 and the computer 928 used for that table. We also have a colour 930, which is the waiter responsible for that table. Finally we have the XOS field 932, which distinguishes between XOS tables and normal tables.

To add a table, press the plus button, enter a table name such as training and fill in its details such as name, capacity, MicrosED and the computer name. Finally we can pick the colour of the waiter responsible for the table. We also need to check the XOS -box if the table has XOS. We then press the tick the details then being saved to the database.

To delete a table, we simply select a table and then press the minus button. The delete will then be confirmed and the changes will then be saved.

Editing Table Colours

The colour of the table represents the waiter responsible for the table. To edit these table colours we select the Table Colour Maintenance button 728, which brings up the form 934 illustrated in Figure 35. From here, there is a list 936 of all current table colours. On the right we see a description 938 of the colour plus the colour 940 itself. We can select the particular colours and even define our own custom colours. To add a new table colour we press the plus button, enter a description and then choose the particular colour by pressing the button 942 to the right hand side of the colour box. This brings up the Colour form 944 as illustrated in Figure 36. To create a custom colour we press the define custom colours button 946. Thus, for example to select a light green we select that colour and press the add to custom colours button. If you are happy with the colour press the tick.

To delete a table colour simply select that colour and then the minus button. The deletion is then confirmed when prompted.

To edit a table colour, select the colour in the left hand side grid. We can now begin editing the details. Typing over the filed can simply change the description. To change the colour select the button to the right of the colour box. We then select a particular colour from the colour range. Once happy with the changes, press the tick that results in the changes saved to the database.

Linking Products to Images

To link a product to an image name press the Product Maintenance button 734 that will load the Product Maintenance Form 948 illustrated in Figure 37. Here we link product to images is so that when the XOS is running we know that when a customer presses a button which product we need to order in the Micros system.

Once the Product Maintenance form appears we see it is broken into three areas. The first area 950 has two columns. The first is a list 952 of all the products, which have been imported directly in from Micros, the second 954 the XOS category names. One may sort by either the product or category name by clicking on the respective headings. If we do sort by category name it is sorted in alphabetical format.

The middle area 956 has a set of images that are not used on this product. Only product and condiment images are shown in this list. The third area 958 or column has any product or condiment images that have been correlated with the particular product highlighted on the left hand side.

If we wish to add more images to a product, select the relevant product, to see if its image is already associated with this product. We then highlight any further images located in the middle area or column that we want associated with this product. We then press the right arrow 960 to move them into the third area or the far right window. Now there is an additional image that has been linked to that product. To remove a link highlight the image and press the left arrow 962.

It is important to note that each image in the database will appear within the second or third areas or windows, never in both. If you want to remove a number of images press the left button. If we wanted to remove all images we can press the double left button 964. We can only do that though if the image associated with the product button is not currently being used on any XOS system. Once we have completed changes press the green tick to save.

To edit the screen type select the Screen Types button 730 which will load its form 966 illustrated in Figure 38. On the left hand side is a list 968 of all the different types of screens^' available for use in XOS. Most of these will probably not need to be changed unless redevelopment within the XOS occurs. The first type of screen is the Border Screen 970 that provides the border of the XOS. The second is the Child Lock Verification Screen 972 , which is the screen that is shown whenever a customer is asked to use their smart card. The Disabled Button Screen 974 is the screen shown whenever the customer is prevented from entering other parts of the XOS until they have ordered either food and/or drink. The End Point From Menu 976 is a screen that appears once an item on a menu has been ordered, for example if the customer order a music video, it will play in a second screen which will be cold an end point from a menu. The End Point Form Navigation 978 is as above but coming from navigation rather than a cold fusion menu page. The Help 980 is the screen in which the help video is played. The Home Screen 1082 is the initial screen of the XOS, the screen from which the five menu items are available, eat, drink, fun, XertsTV and shopping. Only one home screen may be available per profile of the XOS. The Incidental Screen 984 is a screen that appears after a random number of clicks on a menu screen. The Media Player Error Screen 986 is a screen that shows when a media player error occurs, such as problems with the theatre server. The Menu 988 is the menu from which the customer orders products. The Navigation 990 screens use the navigation video, such as that for the home screen and the sub screens from there, i.e. the drink, eat, fun, XertsTV and shopping. The No Buttons Screen 992 is used when a particular menu screen has no products on it, such as a profile with no alcohol so that the food and beverage manager would remove all alcohol buttons from that menu. When that menu is opened it will count the number of product buttons and if it is zero will open the No Buttons screen. The Options screen 994 is the one appears when the customer presses the options, such as to call a waiter or request a bill. The Order Submitted Screen 996 is the screen that appears once a customer has submitted their order to the kitchen. The Selection 998 is a screen that is shown to the customer when they have pressed the transmit button listing all food and drink items ordered but not yet sent to he kitchen. The Shutdown Screen 1000 is a screen showing a final video when the XOS is shut down. The Welcome Screen 1002 is the initial open up screen that the XOS opens up to.

For each different type of screen different check boxes have been ticked that are the options that are enabled when the systems administrator creates a new screen when working on the profiles. For example, if we click on the help screen when the system administrator creates a new XOS type help screen they will be allowed to enter a background screen and provide an introduction video entrance and exit time. All other options will be disabled.

To create a new screen type, press the plus button. Enter a description for the screen type and next decide which options will be available when the user creates a new screen of this type. First of all we need to device is it is to be a home screen (only one screen per profile can be a home screen). Next we need to select whether or not this screen has a background image. In the case of a navigation video the video is itself the background. We need to decide whether the page has a background sound, which may be one of two things - the sound that is played when the screen opens or sounds that play when the user presses certain buttons. If this particular screen is allowed to use its own style sheet, such as where one has a different number of products, we would need to allow style sheets. The video intro is whether or not we want to play a sequence of videos whenever the customer enters this particular screen. We then need to decide whether or not the screen itself will be part of the video. If we want to play a sequence of videos whenever a customer exits the screen we tick the video exit option. If the sound theme is enabled, the user will be able to select a sound theme that applies to all buttons on a menu in the XOS. The category is whether or not this particular screen leads to a particular XOS category. Thus, for example if we are looking at drinks, whenever anything new on a screen is ordered, the number of drinks in the order pad will increase by one and also in the transmit screen the items that is ordered will appear below the drinks. We finally need to decide whether this particular screen is allowed an incidental video. This has been discussed previously. Once all the details are entered we press the tick to save the new screen. To delete a screen type first select the screen on the left hand side grid and then press the minus button. The deletion will now have to be confirmed and after that will be deleted.

To edit a screen type first select it. To change the description simply type in the description field. One may also check and uncheck any of the tick boxes as required. Once the changes have been made press the tick that saves the changes to the database.

Editing Buttons Types

Understanding the Buttons Types & Description of Button Types

To edit a button type select the Button Type button 732. We will then see the button type form 1004 as illustrated in Figure 39. On the left hand side form there is a list 1006 of all the buttons available and to the right there is a list 1008 of all the details. The current button types are the Add button. The types of images and sounds that are selected in this screen are applied in different areas of the system. A condiment button uses a condiment type of image and sound, and relates to ordering a condiment. A DCR condiment has an image but no sounds, such as the thermometer where an animation occurs whenever a user selects a new condiment. The dummy condiment has no image or sound types and are used with the DCR condiment since the DCR condiment does not have all three condiments that a normal button does, so we need to create dummy condiments. The Help button shown at the bottom of each screen has an image but no sound. There is also the help video and the navigation button that are virtual hotspots on a video that when clicked will either move to a new spot on the video or an html page or an end mode. The product button uses images and sounds and is each of the large products available on a menu for selection. The selection screen button use a transmit image and a transmit sound.

To add a button type press the plus button and then enter a description of the type. Next select the type of images that may be applied to this button, such as a background image. We may also select the type of sounds - such as any sound. The choices shown the drop-down box

1010 in Figure 40. When changes have been applied press the tick that has saved the changes. Note that when any sounds have been selected that field remains blank. To delete a button select it and then press the minus key. Confirm the deletion, which results in the button type being deleted. To edit a button select the button type and then simply edit the description by typing into it. One may also change the image and sound types applied to the button. Once the changes have been made press the tick whereby the changes are saved to the database.

System Directories

To see the various system directories, select the System Directory button 824 that will load the system information form 1012 illustrated in Figure 41. The directories listed above the black line 1014 are the root paths to which all other directories are related. The directories below relate to the paths in relation to other files of the XOS. These will not be described in detail. They can all be changed by typing in the boxes and validated by selecting the tick.

Although the invention has been shown and described in what is conceived to be the most practical and preferred embodiment, it is recognized that departures may be made therefrom within the scope and spirit of the invention, which is not to be limited to the details disclosed herein but is to be accorded the full scope of the claims so as to embrace any and all equivalent devices and apparatus.

Dated this 27th day of August 2001

Xerts International Limited By their Patent Attorneys LESICAR PERRIN

Claims

THE CLAIMS DEFINING THE INVENTION ARE AS FOLLOWS:

1. A user interface management system for use by a system administrator including a means to create available items for display in a user interface development system and - - subsequent inclusion by an operator in the visual aspect of a user interface, the creation of available items including generation of an object to represent the item, the object comprising attributes that are selected by the system administrator and associated with the object.

2. A user interface management system according to claim 1 wherein the system administrator determines the availability of items for inclusion by an operator in the visual aspect of a user interface.

3. A user interface management system according to either claim 1 or claim 2 wherein items are formed from an aggregation of objects, each object including any one or more of the following attributes, or any combination of one or more of the following attributes:

Graphical images;

Text; or

Sound;

4. A user interface management system according to claim 2 wherein the system administrator constructs blank templates of the visual aspect of a user interface for subsequent completion by an operator, the system administrator associating items with templates thus determining the availability of items for use by an operator.

5. A user interface management system according to any one of the preceding claims including a means to define a placeholder designating a specific region of the visual aspect of the user interface into which an available item may be located.

6. A user interface management system according to claim 5 wherein the system administrator is provided with a list of pre-defined placeholders.

7. A user interface management system according to either claim 5 or claim 6 wherein the system administrator classifies placeholders according to the types of available items that may be located in the placeholder.

8. A user interface management system according to any one of claims 5, 6 or 7 wherein a system administrator associates a first placeholder with at least one additional placeholder.

9. A user interface management system according to claim 7 wherein a system administrator prevents additional placeholders being displayed to an operator until an appropriate item requiring additional placeholders is located in the first placeholder.

10. A user interface management system according to any one of claims 4 to 8 wherein placeholders are be defined within a template.

11. A user interface management system according to any one of the preceding claims wherein a system administrator selects at least one graphical image to be displayed to an operator upon location of an available item in a placeholder to provide an indication to the operator of the success or otherwise of the location of the item in the placeholder.

12. A user interface management system according to claim 10 wherein the system administrator is provided with a list of available tests for selection, the tests being applied upon location of an item into a placeholder, selection of an available test causing that test to be applied upon location of an item into a placeholder and display of the appropriate image indicating the success or otherwise of the applied test.

13. A user interface management system according to claim 11 wherein the system administrator selects when tests will be applied.

14. A user interface management system according to either claim 12 or 13 wherein the test includes checking the accessibility of attributes.

_15. A user interface management system according to any one of the preceding claims wherein the system administrator creates functions for display to an operator for selection and association with an item located in a placeholder.

16. A user interface management system according to any one of the preceding claims wherein the system administrator determines a list of available sounds that may be used by an operator to associate with items located in a visual user interface.