I. BACKGROUND

The present invention relates to the field of display advertising, and in particular, to the display and printing of graphic information in a distributed data processing system. In a conventional distributed data processing system, a host system is connected to and controls several remote systems. The remote systems are usually slaved to the host system, but are also capable of operating independently of the host system. The remote systems accept data and instructions from the host system, process the data and instructions, and notify the host system of the results of the processing. It is not uncαawi for the host system to send different data and instructions to each of the remote systems under its control.

In some distributed processing systems, th host system may send different graphics data and instructions to each of several remote systems for display. For example, first graphics data and instructions may be sent to a first remote system, second graphics data and instructions may be sent to a second remote system, and so on. In such a system, the type of graphics data to be displayed changes often. For example, if the remote systems are displaying graphics relating to retail advertisements, the advertisements may run at different times on different days of the week. Similarly, advertisements may be cancelled or new advertisements added or the manner in which the advertisements are displayed, such

as dissolve, fadeout, etc., may change. A need exists for an extremely flexible retail graphics display system that would take into account the almost constant alteration of the displayed information, while still keeping system overhead to a minimum. II. SUMMARY OF THE INVENTION

It is an object of the present invention to allow flexibility in the display of retail advertisement graphics.

It ^" is a further object of the present invention to keep system overhead of a distributed processing system to a minimum.

It is a still further object of the present invention to allow a host system to alter all information concerning a retail graphic advertisement stored in a remote system.

It is a still further object of the present invention to allow a host system to alter all information concerning a retail coupon stored in a remote system.

It is a still further object of the present invention to compact data sent to the remote system to a greatest degree possible.

.Additional advantages of the present invention will be set forth in part in the description which follows and in part will be obvious from that description or may be learned by practice of the invention. The advantages of this inven¬ tion may be realized and obtained by the methods and ap¬ paratus particularly pointed out in the appended claims.

The present invention obtains the advantages listed above by allowing the host system to alter all information concerning a retail graphics advertisement by downloading information to the remote system and by sending transaction command files that refer to the downloaded information. More specifically, to achieve the objects and in accordance with the purpose of the invention, as embodied and broadly described herein, the invention involves downloading all information required to display graphics and organizing the information into three main types of files: display files, command files, and transaction files. Some types of information are downloaded using only command files and transaction files.

As recited herein, the present invention is a method of displaying a screen display in a system including an interconnected host processor and remote processor, the method comprising the steps of: storing in a memory of the remote processor a plurality of sets of display data, each set of display data describing a display screen; storing in the memory of the remote processor a plurality of sets of commands, each set of commands specifying a set of display data; storing in the memory of the remote processor a plurality of sets of transaction data, each set of transaction data specifying a set of commands; sending, by the host processor, a set of display data, a set of commands, and a set of transaction data to the remote processor;

receiving, by the remote processor, the set of display data, the set of commands, and the set of transaction data; storing, by the remote processor, the received set of display data as one of the plurality of sets of display data; storing, by the remote processor, the received set of commands as one of the plurality of sets of commands; storing, by the remote processor, the received set of transaction data as one of the plurality of sets of transaction data; retrieving from the memory of the remote processor a set of display data specified by the retrieved set of commands; and displaying, by the remote processor, a display screen described by the retrieved set of display data, at the predetermined time, according to the retrieved set of commands.

As recited herein, the present invention is a method of displaying a screen display in a system including an interconnected host processor and remote processor, the method comprising the steps of: storing in the memory of the remote processor a plurality of sets of commands, each set of commands specifying a coupon to be printed; storing in the memory of the remote processor a plurality of sets of transaction data, each set of transaction data corresponding to a transaction to be performed, each set of transaction data specifying a predetermined t.ime to print a coupon and further specifying a set of commands; sending, by the host processor to the remote processor, a set of transaction data;

receiving, by the remote processor, the set of transaction data; storing, by the remote processor, the received set of transaction data as one of the plurality of sets of transaction data; retrieving from the memory of the remote processor the set of commands specified by the received set of transaction data; and printing, by the remote processor, a coupon described by the retrieved set of commands, at the predetermined time. III. BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and which constitute a part of this specification, illustrate one embodiment of the invention and, together with the descrip¬ tion, explain the principles of the invention.

Fig. 1 is a block diagram of a distributed processing system including a host system having a memory and several remote systems, each having a memory;

Fig. 2 shows a format of an ad ID file in the memory of the host system of Fig. 1;

Fig. 3 shows a format of a distribution file for ads and coupons in the memory of the host system of Fig. 1;

Fig. 4 shows a format of a coupon ID file in the memory of the host system of Fig. 1;

Fig. 5 shows an example of a coupon displayed by the present invention;

Fig. 6 shows a format of a transaction file for ads or coupons in the memory of a remote system of Fig. 1;

Fig. 7 shows a fo.rmat of a command file for ads in the memory of a remote system of Fig. 1 by way of an example;

Fig. 8 shows a format of a display file for ads in the memory of a remote system of Fig. 1;

Fig. 9 shows a format of a command file for coupons in the memory of a remote system of Fig. 1;

Fig. 10 further shows the format of a command file for coupons in the memory of a remote system of Fig. 1;

Fig. 11 shows an example of a command file for coupons having the format of Figs. 9 and 10;

Fig. 12 shows a continuation of the example of Fig. 11;

Fig. 13 is a flow chart of a method for downloading a display file of Fig. 8, a command file of Figs. 7 or 9-12, or a transaction file of Fig. 6;

Fig. 14 is a flow chart of a method for scheduling ads and coupons according to the downloaded display file, command file, and transaction file in one of the remote systems of Fig. 1;

Fig. 15 is an example of a rotation list generated by a store controller of Fig. 1 to schedule ads or coupons; and

Fig. 16 shows a format of an ad log file in the memory of the host system of Fig. 1.

IV. DESCRIPTION OF THE PREFERRED EMBODIMENTS

Reference will now be made in detail to a presently preferred embodiment of the invention, examples of which are illustrated in the accompanying drawings.

The present invention is preferably embodied in a retail display system called a "reverse vending machine." The reverse vending machine resembles a conventional vending machine, with the addition of a display screen and an input slot. When a user places an empty beverage container, such as a plastic milk jug or a soft drink can or bottle, in the input slot, a menu displayed on the display screen prompts the user to choose one of a plurality of methods of remuneration, such as cash, a monetary gift to be donated to charity, etc. Such machines are usually placed in retail outlets such as grocery stores to allow customers to dispose of their empty beverage containers.

While beverage containers are being inserted into the reverse vending machine, the reverse vending machine preferably displays a variety of advertisements and public service announcements (both hereinafter called ads) on a built-in display. These ads can be either static, i.e. , non-moving , or animated , i.e., containing moving components. Because the present invention is directed to the display of these ads and not to the reverse vending machine aspect of the system, the present invention could be embodied in any type of distributed display system. For example, the present

invention could be embodied in a system whose sole function is to display ads in a retail store.

Some embodiments of the present invention also include a mechanism for printing and dispensing retail coupons. For example, a coupon for a discount on a retail product may be printed and dispensed whenever beverage containers are inserted into the reverse vending machine. Because the present invention is directed to the printing of these coupons and not to the reverse vending machine aspect of the system, the present invention could be embodied in any type of distributed display system.

Other embodiments of the present invention also include a compact disk player, which plays ads from compact disks in addition to displaying downloaded ads on the screen. Ads stored on compact disks are called "full video" ads and will be discussed further below.

Fig. 1 is a block diagram of a distributed processing system 100 including a host system 110 and a plurality of remote systems 115(1) ...115(n) . Host system 110 includes a memory 140 and a processor 145. Each remote system 115(1) ...115(n) includes a store controller 120 and one or more display controllers 130. Each store controller 120 includes a processor 122, a memory 124, and a clock 126. Each display controller 130 includes a processor 132, a memory 134, a display 150 and a printer 160.

Host system 110 and remote systems 115(1) ...115(n) are interconnected by a transmission line 125. In a preferred embodiment, host system 110 and each of remote systems 115(1) ...115(n) is equipped with a modem, and transmission line 125 is a standard telephone line. Transmission line 125 could also be a transmission line physically connecting hosr system 110 and remote systems 115(1) ...115(n) or any apparatus that allows signals to pass between the systems.

As stated above, host system 110 includes a memory 140. Memory 140 is preferably a hard disk, but may also include RAM, floppy disk drives, tape, or the like. Memory 140 includes a plurality of files, some of which are described below, which include information relating to the display of various ads on remote systems 115(1) ...115(n) and information relating to printing of various coupons on remote systems 115(1) ...115(n) . Portions of these files are described below.

Information is transmitted along transmission line 125 from host system 110 to a store controller 120 which, in turn, instructs each display controller 130 connected to store controller 120 which ads to display and which coupons to print. Each display controller 130 can access the files stored in memory 124 of its corresponding store controller 120.

As stated above, each remote system 115(1) ...115(n) includes a memory 124 and a memory 134, which are preferably

a hard disk, but may also include RAM, an optical disk, or the like. Each of memories 124 includes a plurality of data files, which include information required to generate ads on one or more displays 150 as described below. Each of memories 124 also includes a plurality of data files, which include information required to generate coupons on a corresponding printer 160 as described below. Each memory 124 may store different data to generate different ads and coupons.

To achieve the greatest flexibility in the system of the present invention, all information stored in each of memories 124 is downloaded to remote systems 115(1) ...115(n) from memory 140 of host system 110. The downloaded information for ads are organized into "display files," "command files," and "transaction files." The downloaded information for coupons are organized into "command files" and "transaction files. " Each of these types of files has a predetermined format, and the format of command files for ads and coupons differ, as described below.

Each remote system 115 receives data describing different ads and coupons. The format of the files on the host system and on the remote systems are discussed below. Once the display files, the command files and the transaction files have been downloaded to remote system 115, remote system 115 displays retail graphic ads and coupons according to the downloaded files. A transaction file indicates a

command file to display and a time to display it. The command file indicates at least one display file, which contains graphics information describing either an ad or a coupon. Coupon command files do not indicate display files, but, instead, directly describe a coupon appearance.

Preferably, display files are downloaded to the remote systems weekly. Thus, information describing new static, animated, and full video displays are introduced into the remote systems every week. Preferably, command files are downloaded weekly. Thus, new ads and coupons are introduced into the remote systems every week. Preferably, transaction files are downloaded weekly. Thus, instructions to display certain ads or to print new coupons at certain times are introduced into the remote systems every week.

Next, information stored in memory 140 of host system 110 and used to generate the display files, command files, and transaction files is discussed. Memory 140 of host system 110 contains data describing all ads and coupons that can be displayed by the remote system. This data includes "ad display files," "ad command files," "ad ID files," "ad distribution files," "coupon command files," "coupon ID files," and "coupon distribution files."

.Ad display files are bitmaps describing ads. Ad command files are described in connection with Fig. 7 below. Ad ID files contain information describing each ad. Ad distribution files contain information describing on which

remote systems the ads are to be displayed. Both ad ID files and ad distribution files are used to generate ad transaction files for the various remote systems 115.

Coupon command files are described in connection with Figs. 9-12 below. Coupon ID files contain information describing each coupon. Coupon distribution files contain information indicating on which remote systems and at what times each coupon is to be printed. Both coupon ID files and coupon distribution files are used to generate coupon transaction files for the various remote systems 115.

Fig. 2 shows a format of an ad ID file 200 in memory 140 of host system 110 of Fig. 1. The fields of Fig. 2 are defined as follows. An ad_id field is an eight byte character field and contains a unique ad ID number, such as "AD000001," which is also used as the file name of the command file for the ad. The format of a command file for an ad is discussed below is connection with Fig. 7, and the format of command files does not differ between host system 110 and remote systems 115.

In Fig, 2 an ad_id_ext field is a three character field, which is used as an extension for the file name of the command file for an ad. .An account_no field is a six character field and contains an account number of a customer running the ad. .An ad_type field is a two character field and contains a value of "AN" if the ad is animated, a value of "NA" if the ad is not animated, or a value of "FV" if the

ad is to be played from a CD player included in the system. A format_type field is a two character field and contains a value indicating an ad layout format, such as a preferred color palette of the ad. The format_type field is not used in a current embodiment, but may be used in future embodiments. A subject field is a fifteen character field and contains comments on the subject of the ad. A time_of_day field is a twenty-four character field, where each character position indicates a different hour of a day. Time_of_day field indicates for which hours of the day the ad should be displayed, beginning with the one a.m. through two a.m. hour interval. For example, if time_of_day field contains "x.x.x.x.x.x.x.x.x.x.x.x. ", the ad is to be displayed every other hour. A days_of_week field is a seven character field, where each character position indicates a different day of the week. Days_of_week field indicates on which days of the week the ad is to be displayed, in a manner Saimilar to t.ime_of_day field. A display time field is a four byte integer field containing a number of seconds to display the ad at one time.

A display__type field is a three character field containing a value indicating how the ad is to be displayed. Possible values of display_type field include: "SR" - (Sweep Right) indicating that the ad is to be displayed from the left edge of the screen first; "SL" - (Sweep Left) indicating that the ad is to be displayed from the right edge of the

screen first; "SU" (Sweep Up) indicating that the ad is to be displayed from the bottom of the screen; "SD" (Sweep Down) indicating that the ad is to be displayed form the top of the screen first; "II" (Iris In) indicating that the ad is to be displayed from the edges of the screen first and the center of the screen last; "10" (Iris Out) indicating that the ad is to be displayed from the center of the screen first and the edges of the screen last; "VB" (Venetian Blind) indicating that the ad is to be displayed in a manner suggesting the opening of a Venetian blind, as is known to persons skilled in the graphics art; and "FI" (Fade In) indicating that the ad is to be displayed with a fade-in, as is known to persons skilled in the graphics art.

A display_repeats field is a three byte integer field indicating a number of times to repeat the ad per hour. An rvm_type field is a one character field indicating whether the reverse vending machine of the preferred embodiment processes plastic, aluminum or glass. A special_options field is a two character field that is presently unused. .An updated__by field and an updated_on field contain data relating to the last update of ad ID file 200. The updated_by field and the updated_on field are used for accounting purposes only and may be omitted without affecting the performance of the present invention.

Fig. 3 shows a format of a distribution file 300 in the memory of the host system of Fig. 1. Distribution file 300

can be either an ad distribution file or a coupon distribution file, because each type of file has an identical format. Distribution file 300 indicates the reverse vending machines where each ad or coupon is to be run. Distribution file 300 is used by the host to determine to which remote systems to download display files, command files, and transaction files describing an ad or command files and transaction files describing coupons. An id field is an eight byte character field and contains a unique ID number, such as "AD000001," which is also used as the file name of the command file for the ad or coupon.

In Fig. 3 an ad_kind field is a two character field indicating whether the ad is a display ad or a coupon. A store__ID field is a six byte integer number indicating an ID of the retail store housing the remote system where the ad is to be run. A rvm_ID field is a six byte integer field indicating an individual remote system on which the ad is to be run. (It is possible to have more than one reverse vending machine at a single retail store). A start_on field is a six character field containing a date in DDMMYY format of the first day that the ad is to run. An end_on field is a six character field containing a date in DDMMYY format of the last day that the ad is to run. An updated_by field and an updated_on field contain data relating to the last update of distribution file 300 and may be omitted. The format of a coupon distribution file is substantially identical to the

format of an ad distribution file, as described above, and will not be described herein.

Fig. 4 shows a format of a coupon ID file 400 in the memory of the host system of Fig. 1. The format of coupon ID file 400 is similar to the format of ad ID file 200. The fields of Fig. 4 are defined as follows. A coupon_id field is a twelve byte character field and contains a unique coupon ID number, such as "C00000000001, " which is also used as the file name of the command file for the coupon. The format of a command file for a coupon is discussed below is connection with Fig. 9-12, and the format of command files does not differ between host system 110 and remote systems 115.

A coupon__id_ext field is a three character field, which is used as an extension for the file name of the command file for a coupon. An account_no field is a six character field and contains an account number of a customer running the coupon. A coupon_type field is a two character field and, in the example, contains a value of "PZ" if the coupon is a prize coupon, a value of "ST" if the coupon is a store coupon, and a value of "MA" if the coupon is a manufacturer's coupon. A format type field is a two character field containing a value of "Cl" if the coupon contains a dollar amount in a corner of the coupon and a picture in a first position of the coupon and a value of "C2" if the coupon contains a dollar amount in a corner and a picture in a second position of the coupon. A subject field is a fifteen

character field describing the contents of the coupon. A clearing house field is a two character code identifying a clearing house address to print on the coupon. A times_of_day field is a twenty-four character field, where each character position indicates a different hour of a day. Times_of_day field indicates for which hours of the day the coupon should be displayed, beginning with the one a.m. through two a.m. hour interval. For example, if times_of_day field contains "x.x.x.x.x.x.x.x.x.x.x.x.", the coupon is to be printed every other hour. A days_of_week field is a seven character field, where each character position indicates a different day of the week. Day_of_week field indicates on which days of the week the coupon is to be printed, in a manner s.imilar to time_of_day field. A display_time field is a four byte integer field containing a number of seconds to display the coupon at one time.

An rvm_type field is a one character field indicating whether the reverse vending machine of the preferred embodiment processes plastic, aluminum or glass. A special_options field is a two character field that is presently unused. An updated_on field contain data relating to the last update of coupon ID file 400 and may be omitted. The updated_on field is used for accounting purposes only and may be omitted without affecting the performance of the present invention.

The above discussion concerns files stored in memory 140 of host system 110. The following discussion concerns files downloaded from host system 110 to one or more of remote systems 115(1) ...115(n) . Because display files and command files have substantially identical formats on the host system and the remote systems, display files and command files are discussed below in connection with the remote system. It is understood that command files and display files are stored on the host system, as well.

Fig. 5 shows an example of a coupon 500 printed by a preferred embodiment of the invention. Coupon 500 is discussed further in relation to Fig. 12.

Fig. 6 shows a format of a transaction file for ads in the memory of a remote system of Fig. 1. The transaction file contains a name of a command file, times and dates that the ad is to be displayed, etc., and other information in a format substantially similar to that of the ad ID file of Fig. 2. However, a transaction file having the format of Fig. 6 may not contain identical data to the ad ID file of Fig. 2. Each transaction file is defined for a specific remote system 115, and thus, for example, an ad may run for one day at a first remote system 115 and run for one week at a second remote system 115. Thus, each transaction file is created by processor 145 of host system 110 according to the information in both the ad ID file of Fig. 2 and the ad distribution file of Fig. 3 for each remote system 115.

A transaction file for coupons is not shown herein. Such a file has a format substantially similar to the of the coupon ID file of Fig. 3, contains similar fields to that of the ad transaction file of Fig. 6, and is created by processor 145 in a manner similar to the manner used to create ad transaction files.

Fig. 7 shows a format of a command file 700 for ads in the memory of a remote system 115 and memory 140 of Fig. 1 by way of example. The command file 700 contains a series of commands relating to the display of one or more display files to define an ad and has the same format on both host system 110 and remote systems 115. In Fig. 7, a keyword "SCRIPT" is followed by the name of the command file (for example, "sierra.spt" ) , the characters "600" representing a maximum number of horizontal pixels available, and the characters "VGA" representing a type of display screen of display screen 160.

Each of the following lines in Fig. 7 represents a command for displaying the ad "sierra.spt. " The first line ("WIPE HORIZONT.AL DOWN kiwi.scl 10 full") instructs processor 132 of a remote system to display a static graphics display in the display file "kiwi.scl" for ten seconds before erasing the display with a horizontal downward wipe, a term that is well-known to persons of ordinary skill in the art. The second line instructs processor 132 to perform the same operation for a display file "child.scl."

The third line ("TEXT BIT generic.fnt 30 40 255 650 100 20 365") and the fourth line ("THE OUTDOORS") instructs processor 134 to display the ASCII text "THE OUTDOORS" in a horizontal downward wipe using a typeface stored in a file "generic.fnt. " The numerals "30, 40, 255, 650, 100 20 365" on the third line are predetermined codes, respectively, for text color, text size, relative speed of display, beginning X coordinate, beginning Y coordinate, ending X coordinate, and ending Y coordinate.

In the example, the word "BIT" indicates that the font is stored in a bit-mapped format. As also shown in Fig. 7, the word "STROKE" may also be used to indicate that a font is stored in a "stroke" format."

The fifth line is similar to the first and second lines. The sixth and seventh lines are s.imilar to the to the third and fourth lines.

The eighth line ("HOLD 1") instructs processor 132 to hold the static graphics currently on the screen for one second. The ninth and tenth lines are similar to the third and fourth lines, and the eleventh through twelfth lines have formats similar to lines already described.

Fig. 8 shows a format of a display file 800 for ads in the memory of a remote system of Fig. 1. In a preferred embodiment, display files are created by a first commercial software product, namely SCANRIX, which is manufactured by RIX Software, Inc. of Irvine, California and are edited with

a second commercial software product, namely COLORIX, which also is manufactured by RIX Software, Inc. This format provides a 640 x 400 resolution with 256 colors. In a preferred embodiment, the files thus created are further modified by proprietary software developed by applicant, which adjusts certain color palette definitions and trims picture borders automatically. Possession of this proprietary software is not necessary for practice of the invention, and non-modified display files or files modified by another means will yield equivalent results. Any suitable method of storing graphical representations of ads may be used to practice the invention.

Fig. 9 shows a format of a command file for coupons 900 in the memory of a remote system of Fig. 1. Fig. 10 further shows the format of the command file for coupons. Fig. 11 shows an example of a coupon command file. Fig. 12 shows an example of a coupon bitmap included in the example of Fig. 11. The coupon command file contains a series of commands relating to the printing of a coupon and has the same format on both host system 110 and remote systems 115.

An overall format of coupon command files is shown in Fig. 9. In a preferred implementation of the invention, printer 160 can receive data over a serial communications line and a faster parallel line. To attain a fastest data transmission time, bitmaps describing the coupon are sent over the parallel line and commands that need to be

interpreted by printer 160 are sent over the serial line. This is done in order to relieve the parallel line communications task on the printer from having to interpret every byte sent from display controller 130. Instead, printer 160 can simply pass any data received directly to an internal image data buffer (not shown). This method greatly increases the parallel data download speed between display controller 130 and printer 160.

As shown in Figs. 9 and 11, the coupon command file 900 includes a header 910 indicating numbers of bytes to send respectively on the serial and parallel lines of printer 160. Printer 160 first receives on the serial port a number of lines of commands to be sent on the serial port ("33" in Fig. 11). Because no data is interpreted when received on the parallel port, printer 160 first receives on the serial line a number of bytes to expect on the parallel line ("8320" in Fig. 11). .After printer 160 has received this number of bytes, printer 160 reverts to receiving and interpreting data on the serial line and receives a number of bytes indicated in Fig. 11 by a "S" followed by "2". The number of groups of parallel and serial bytes are indicated by the number of "P" and "S" lines in the header of Fig. 9. The header of Fig. 9 is ended by the ASCII characters "*END".

Fig. 10 further shows the format of data 920 sent over the serial line of printer 160. Each separate image to be

sent to a coupon has a format as follows:

<CI>cmd[ parameters... ]<CT>[data<LT>] where "<CI>" is a "command introducer," which preferably defaults to an ASCII escape character; "cmd" is a command consisting of one or more characters AND followed by zero or more comma-separated parameters, which are followed by a "command terminator" "<CT>," which preferably defaults to a semicolon; "<CT>" is optionally followed by data; and the data is terminated by a "line terminator" "<LT>," which preferably defaults to an ASCII line feed character.

Figure 10 shows six types of commands used to print coupons: field commands, select/set commands, printer commands, overall control commands, data manipulation commands, and query status commands. It should be understood that these commands are shown by way of example only, and that the actual commands in a command file will differ depending on such factors as a type of printer used, etc.

In Fig. 10 the field commands include commands to print text ("FT"), bitmaps and/or logos ("FB"), lines ("FL"), boxes ("FLB"), and barcodes ("FC") .

The select/set commands include commands to select a position on the output medium ("SP"), to select a column for right or left justification ("SJ"), to select a magnification in the X and Y directions for all printed data ("SM"), to select a printer attribute ("SA"), to select a print direction ("SD"), to select a printer font ("SF"), to select

a maptable ("SM"), to select a barcode type ("SCT"), to select a barcode ratio ("SCR"), and to select a barcode height ("SCH").

The printer commands include commands to print a predetermined label ("PL"), to send a paper feed code ("PF"), to cut the paper, when the printer included in display controller 130 has this capability ("PC"), and to print a predetermined test label ( "PT" ) .

The data manipulation commands include commands define a font header ("DFH"), to define a font character ("DFC"), to define a font end ("DFE"), to kill a defined font ("DFK"), to define a data bitmap ("DBD"), to erase a data bitmap ("DBE"), to erase memory contents ("DME") which includes a safety code to avoid accidental erasure, and to clear a print buffer ("DPZ") .

The overall control commands include commands to automatically increment the cursor position ("CAI"), to set a bitmap channel ("CBC"), to set a bitmap type ( "CBT" ) , to set a bitmap protocol ("CBP"), to label dimensions ("CD"), to select a printer ("CS"), to feed before print ("CFB"), to feed after print ( "CFA" ) , to cut after print ( "CU" ) , to reset a printer roll center ("CRZ"), to read a roll center ("CRR"), to change the default <CI> character ("CCI"), to change the default <CT> character ("CCT" ), to change the default <LT> character ("CLT"), to set a printer transporter time ("CTT"), to set a printer verbosity level ("CQL"), to reset the

printer ("RESET"), to set an optical density value ("CO"), and to set an electrical density value ("CE").

The query status commands include commands for querying the status of the current printer ("QP"), the current printer position ("QFP"), the current printer direction ("QFD"), the current printer justification ("QFJ"), the current font magnification ("QFM"), the current printer attributes ("QFA"), the current barcode type ("QFC"), the current font name ("QFF"), the current printer cutter status ("QC"), the current label dimensions ("QD"), the current printer version ("QV"), the last error reported ("QLE"), the current list of fonts ("QLF"), the current list of logos ("QLL"), the current list of barcodes ("QLC"), and the current memory status ("QMP," "QMR," "QMF," "QMS," "QMN," or "QMI").

The above described command files for both ads and coupons are intended to be exemplary only. Other commands may be included or commands may be deleted without affecting the scope of the present invention.

Fig. 11 shows an example of a coupon command file 1100 having the format of Fig. 9 and 10. The coupon command file of Fig. 11 prints the coupon shown in Fig. 5. Not all the commands of Fig. 10 are included in the example, which is presented for purposes of example only.

In Fig. 11 a first line sets a font name of ""HV120BPN.2. " A second line sets a printer direction of "2," indicating a negative Y direction. (Preferably, "1" is

a positive X direction, "3" is a negative X direction, and "4" is a positive Y direction). A third line sets a magnification of a font. A fourth line sets a Y position of "65" and an X position of "150" and prints a text string of "SOi." Fifth through eleventh lines perform similar steps to that of the fourth line. A twelfth line sets a justification value and prints the text "Miller Lite 6 Pack."

A thirteenth line sets a font name of "HV06ORPN.2. " A fourteenth line prints the text "Manufacturers Coupon" at a predetermined position and a fourteenth line prints a box around the text. Fifteenth through thirtieth lines perform similar steps. A thirty-first line sets a default increment value of zero for the remainder of the coupon image, so that subsequent text can be positioned absolutely. A bit map image 930, such as that shown in Fig. 12, follows the thirty-first line and is sent on the parallel line. The last line of coupon command file 1100 is sent of the serial line and prints the coupon defined by the other lines of file 1100. The "PL" command instructs printer 160 to print all the accumulated text and bitmap data currently in its buffers onto a coupon, along with a form feed character and a paper cut character.

Fig. 12 shows a first preferred format of a bitmap image included in a coupon command file, such as that shown in Fig. 11. The format of Fig. 12 is shown for purposes of example, and not as a limitation. In Fig. 12, a bit-mapped picture is

encoded in 16 bit words, low byte first. The picture of Fig. 12 is included herein solely for purposes of example. In Fig. 12, "." represents a white dot and "X" represents a black dot. A hexadecimal representation of this pattern appears at the right of Fig. 12. Thus, in the first row of Fig. 12, the hexadecimal values "ff,ff,3f,00" represent the first row of dots where a rightmost word of dots (ff,ff) is represented in low byte, high byte order, and a next word of dots (00,3f) is represented in low byte, high byte order.

Fig. 13 is a flow chart 1300 of a method for downloading a display file of Fig. 12, a command file of Figs. 7 or 9-12, or a transaction file of Fig. 6. Flow chart 1300 includes steps 1310-1360. Steps 1310-1330 are performed by processor 145 of host system 110 and steps 1340-1360 are performed by processor 122 of a remote system 115. In step 1310 processor 145 determines the name of the file to download and its contents. This determination step differs for each of display files, command files and transaction files. Display files contain graphics information required to display one graphics picture on display 150 or to print one coupon on printer 160. The display files are created by a number of methods, including scanning an existing picture, using a commercial software paint program, converting video input, etc. The display files have a format known to persons of ordinary skill in the art and are named according to a convention of the commercial software package SCANRIX.

Command files have a format shown in Figs. 7 and 9-12 and are created by a user, either by typing ASCII text into a file or by an interactive process (not shown). Command files have the filename extension ".SPT", which stands for "SPOT."

Transaction files for each ad or coupon in each remote system 115 have a format shown in Fig. 6 and are created by processor 145 of host system 110 by combining the information in the ID and distribution files for the ad or coupon. For example, the "start_on" and "end_on" fields of distribution file 300 of Fig. 3 are combined with the add ID file of Fig. 2 or the coupon ID file of Fig. 4 to yield a transaction file, such as shown in Fig. 6. Transaction files have the filename extension ".MSG", which stands for "MESSAGE."

In step 1320 of Fig. 13 processor 145 compresses the file to be downloaded into a compact form to speed transmission. In a preferred embodiment of the invention, the file is compressed by use of a commercial software product, namely PKZIP, manufactured by PKWARE, Inc. of Glendale, Wisconsin. This software determines which of a number of well-known compression algorithms will most compress the file. This algorithm is then applied to the file and an indication of the algorithm used is included with the compressed file. In general, step 1320 is an optional step and any appropriate algorithm may be used to decrease the number of bytes of the file.

In step 1330 processor 145 transmits the compressed file to one or more of remote systems 115 over transmission line 125 using a well-known transmission method. A preferred embodiment of the present invention uses a 9600 BAUD MNP4 modem. Similarly, in step 1340, processor 145 receives the compressed file and, in step 1350, decompresses the file according to the information transmitted with the file concerning the type of compression algorithm used in step 1320. In step 1360, processor 145 stores the decompressed file in memory 134 as a display file, a command file, or a transaction file according to the format of the file name.

As discussed above, once the display files, the command files and the transaction files have been downloaded to remote system 115, remote system 115 determines which of display controllers 130 will display retail graphic ads and print coupons according to the downloaded files. A transaction file indicates a command file to display and a time to display it. The command file indicates at least one display file, which contains graphics information.

Fig. 14 is a flow chart 1400 of a method performed by processors 122 and 132 of each of remote systems 115 for scheduling ads and coupons according to the downloaded display file, command file, and transaction file in one of the remote systems of Fig. 1. Steps 1402 through 1408 are performed by a processor 122 of a store controller 120. Steps 1412, 1416, and 1420 are performed by a processor 132

in each display controller 130 associated with the store controller 120.

In step 1402, processor 122 checks clock 126 to determine whether a next hour has occurred. When a new hour occurs, in step 1404, processor 122 scans the transaction file 1410 for each ad and each coupon in memory 124 and creates, in step 1406, a new coupon rotation list and a new ad rotation list for each of its display controllers 130. Processor 122 then stores the new rotation lists 1414 in memory 124 of each of its display controllers 130. After processor 122 performs step 1408, control returns to step 1402.

Steps 1412, 1416, and 1420 are performed continuously by each display controller 130 for an ad rotation list and for a coupon rotation list. Only one sequence of steps is shown in Fig. 14 in the interests of clarity. In step 1412, processor 132 accesses rotation list 1414 and gets a nex command file name. If a current command file name is at the end of rotation list 1414, processor 132 gets a command file name from the top of rotation list 1414. In step 1416, processor 132 accesses a command file 1418 having the name retrieved in step 1412, and performs the steps indicated by the contents of command file 1418. These steps may include accessing one or more display files 1419. In step 1420, processor 132 gathers statistics concerning the ad displayed or coupon printed in step 1416. These statistics are periodically •

uploaded to processor 145, and include statistics such as those discussed in connection with Fig. 16 below. After processor 132 has performed step 1420, control returns to step 1412.

Fig. 15 is an example of a rotation list generated by processor 122 in step 1406 of Fig. 14. A rotation list is a list of names of command files that are to be displayed (in the case of ads) or printed (in the case of coupons) during a one hour period. A separate rotation list for ads and for coupons is generated for each display controller 120 attached to each store controller 130. In the example of Fig. 15, six ads (indicated by the six command file names: "crisco.spt, " "litesix.spt," "towels.spt, " dogfood.spt," "butter.spt, " and "winel.spt") are to be displayed repeatedly by processor 132 during a current hour.

In a preferred embodiment of the present invention, the displayed graphics ad includes limited animation. This is accomplished by rapidly displaying a series of display files that.differ from each other only slightly.

In a preferred embodiment, each remote system 115 periodically sends statistics gathered during step 1420 of Fig. 14 to host system 110 over transmission line 125. Fig. 16 show a format of an ad log file 1600 in memory 140 for storing statistics returned from remote systems 115. The fields of ad log file 1600 are as follows. An ad_id field is an eight byte character field and contains a unique ad ID

number, such as ".ADQOQOOl," which is also used as the file name of the command file for the ad, which is discussed in connection with Fig. 7. A rvm_ID field is a seven byte integer field indicating a reverse vending machine to which the current record applies. A start_date field is a six character field containing a date in DDMMYY format of the first day that the ad ran. A days field is a four byte integer indicating a number of days for which statistics were accumulated. Each of a times_ran field and a total_run_time field is repeated twenty four times in each record, once for each hour of the day. Times_ran field indicates a number of times the ad was run for a corresponding hour and total_run_time field indicates a cumulative total display time for the ad. The format of a coupon log file, describing the printing of coupons on a remote system 115 is substantially identical to the format of an ad log file, and will not be described herein.

Other embodiments will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. It is intended that the specification and examples be considered as exemplary only, with a true scope of the invention being indicated by the following claims.