Note: Descriptions are shown in the official language in which they were submitted.
CA 02495243 2005-02-07
WO 2004/019292 PCT/CA2003/001273
METHOD AND APPARATUS FOR AWARDING CUSTOMERS WITH RANDOM PURCHASE REBATES IN
RETAIL STORES
FIELD OF THE INVENTION
The invention relates to awarding purchase rebates. More specifically, it
relates
to intercepting data between a point-of-sale device and its peripherals to
award
random purchase rebates proportional to a purchase amount to buyers who are
purchasing items.
BACKGROUND OF THE INVENTION
Retail store owners are always looking for ways to attract new customers and
to
keep current customers coming into their store. Unless the store has a high
level of revenues, publicities in newspapers, on television and on radio are
quite
expensive for the immeasurable effect that they have.
Retail store owners have therefore looked for other means of attracting
customers. Because human beings are always very happy to be awarded
something, many prior art systems have been created in which prizes and
points are awarded to customers.
Some retail store chains, such as Canadian Tire and The Bay in Canada have
decided to create a "scratch-and-save"TM sale. These sales occur at specific
dates within the year. Each customer coming into the store is handed a card
bearing a square to be scratched to uncover a rebate which will be applicable
on the purchase price of the items he-. then decides to purchase. Typically,
the
squares cannot be scratched by the customer prior to the purchase transaction
being about to be completed at the cash register. The cashier then scratches
the square and confirms the amount of the rebate with the customer. Rebates in
percentages are typically offered. The customer may then decide to follow
through with the purchase, to remove items or to cancel his purchase. Once the
purchase is completed, the cashier initials the card and the customer can
continue to make purchases using the initialed card. However, if the customer
decides to cancel his purchase, the cashier typically keeps the unused card. A
CA 02495243 2005-02-07
WO 2004/019292 PCT/CA2003/001273
-2-
rebate of 10 % is typically the minimum rebate uncovered by scratching the
square. Rebates of 50 % can be, for example, printed on one card out of 833.
The rebates are printed in advance on the cards and the customer is handed a
pre-printed card as he enters the store. A predetermined quantity of each
rebate
is printed and the number of occurrences of each rebate is predetermined.
This system has the drawback, for the retail store owner, that if the rebate
awarded by the card is not high enough according to the customer's
expectations, the customer can walk away without making any purchase or
without making the full purchase he had intended to.
A gas station chain, Esso, has created a frequent buyer program called Esso
ExtraTM, which gives points for each purchase made by a member of the
program. These points can then be used to obtain merchandise, such as gas,
snacks, oil, car wash, etc. In addition to this program, Esso has introduced a
series of contests where the customer may win a prize or an additional number
of Esso Extra points. The prizes are instantaneous. Typically, the result of
the
draw is shown of the receipt for the qualifying purchase and lets the customer
know right away if he won the contest prize or extra points.
This system has the drawback that the prizes awarded are points which the
customers get tired of accumulating points at all different stores they shop
at.
The grand prizes can also seem unattainable to the customers. Customers also
believe that it takes an enormous amount of points to obtain a reward and that
they will forget to use the points because they need to be used at a much
later
time. Therefore, even though the prize is awarded instantaneously, the effects
of the reward are not strong and the fidelity of the customer is not assured.
Moreover, the client does not have an incentive to make a bigger purchase
because of the program since the size of ,his purchase is unrelated to the
prize
potentially won in addition to the standard points.
SUMMARY OF THE INVENTION
Accordingly, an object of the present invention is to overcome the drawbacks
of
the prior art systems.
In particular, an object of the present invention is to capture the data being
CA 02495243 2005-02-07
WO 2004/019292 PCT/CA2003/001273
-3-
communicated between a point-of-sale device and its peripherals. This data can
then be used to award a purchase rebate proportional to the purchase price of
the items purchased by the customer. The customer can then see a direct effect
on the cost of the transaction he just concluded.
According to a first broad aspect of the present invention, there is provided
a
method for awarding an instant rebate. The method comprises determining a
purchase price for a purchase of at least one item made by a client;
activating a
random rebate generator when the purchase price is determined; randomly
determining using the random rebate generator if an amount proportional to the
purchase price is to be awarded to the client; reducing the purchase price by
the proportional amount if the proportional amount is to be awarded.
According to a second broad aspect of the present invention, a system for
awarding an instant rebate. The system comprises a data gatherer for obtaining
a purchase information about a purchase of at least one item; a random rebate
generator triggered by the data gatherer to calculate a purchase price for the
at
least one item using the purchase information and to determine if an amount
proportional to the purchase price is. to be awarded to the client; a rebate
calculator reducing the purchase price by the proportional amount if the
proportional amount is determined to be awarded.
The item is preferably a fresh product.
BRIEF DESCRIPTION OF THE DRAWINGS
These and ofiher features, aspects and advantages of the present invention
will
become better understood with regard to the following description and
accompanying drawings wherein:
FIG. 1 is a flow chart of the main steps of the awarding of a rebate;
FIG. 2 is a block diagram of the main components of a first embodiment of the
system for awarding a rebate;
FIG. 3 is a rebate attribution table for a return of 2 %, with 300 customers;
FIG. 4 is a rebate attribution table for a return of 2 %, with 500 customers;
CA 02495243 2005-02-07
WO 2004/019292 PCT/CA2003/001273
-4-
FIG. 5A and FIG. 5B together are a rebate attribution table for a return of 2
%,
with 11450 customers receiving a rebate and 6 customers not receiving a
rebate;
FIG. 6 is a rebate attribution table for a return of 1.48 %, with 11405
customers;
FIG. 7 is a rebate attribution table for a return of 1.48 %, with 11405
customers
receiving a rebate and 5 customers not receiving a rebate;
FIG. 8. is a rebate attribution table for a return of 1.48 °l°,
with 200 customers
receiving a rebate and 1000 customers not receiving a rebate;
FIG. 9 is a rebate attribution table for a return of 1 %, with 16096.
customers;
FIG. 10 is a rebate attribution table for a return of 9.5 %, with 1200
customers;
FIG. 11 is a rebate attribution table for a return of 10.3 %, with 10000
customers;
FIG. 12 is a rebate atfiribution table for a return of 5 %, with 200 customers
receiving a rebate and 85 customers not receiving a rebate;
FIG. 13 comprises FIG. 13A and FIG. 13B; FIG. 13 is a block diagram of the
main components of a first portion of a second embodiment of the present
invention; FIG. 13B is a block diagram of the main components of a second
portion of the second embodiment of FIG. 13A;
FIG. 14 is a block diagram of the main components of the data gathering
system;
FIG. 15 is a circuit diagram for the architecture of the micro circuit
responsible
for gathering the data;
FIG. 16 comprises FIG. 16A and FIG. 16B, FIG. 16A is a male connector for the
PS/2 port, FIG. 16B is a female connector for the PS/2 port;
FIG. 17 is a circuit diagram for the architecture of a general open-collector
interface;
FIG. 18 is a timing diagram for the device to host communication;
FIG. 19 is an example of a scan code for the "Q" key (15h) being sent from a
keyboard to the computer, channel A is the clock signal, channel B is the data
signal;
CA 02495243 2005-02-07
WO 2004/019292 PCT/CA2003/001273
-5-
FIG. 20 is a timing diagram for the host to device communication;
FIG. 21 is a timing diagram for a detailed host to device communication;
FIG. 22 is the most frequently used standard scan code set for a keyboard;
FIG. 23 is an example of the make and break codes for a few keys;
FIG. 24 is a table showing the typematic repeat rate;
FIG. 25 is a table showing the typematic delay;
FIG. 26 is a table showing the argument byte; and
FIG. 27 is a flow chart of the main steps of the data gathering method.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
While illustrated in the block diagrams as groups of discrete components
communicating with each other via distinct data signal connections, it will be
undersfiood by those skilled in the; art that the preferred embodiments are
provided by a combination of hardware and software components, with some
components being implemented by a given function or operation of a hardware
or software system, and many of the data paths illustrated being implemented
by data communication within acomputer application or operating system. The
structure illustrated is thus provided for efficiency of teaching the present
preferred embodiment.
Referring now to FIG. 1, a preferred embodiment of the present invention will
now be described. The first step of the method for awarding an instant rebate
is
that a client makes a purchase 10. This purchase comprises at least one item.
The total amount of the purchase is calculated and amounts to a purchase
price. The item can be a bag of fresh fruits, for example apples, which needs
to
be weighted and associated to a proper billing code before a purchase price is
determined. The price of the item is determined. The purchase can then be
completed or a simple sub-total can be calculated.
Completing the purchase involves receiving a payment from the customer to
pay the purchase price. The payment can be made in cash, using a credit card,
a debit card, a smart card, coupons, etc. When the payment is received or an
CA 02495243 2005-02-07
WO 2004/019292 PCT/CA2003/001273
-6-
authorization from the card issuer is received and the transaction is
recorded,
the transaction is considered to be completed. As soon as the sub-total
identifying the purchase price is determined, a random rebate generator can be
activated 12. The random rebate generator can be triggered by the reaching of
the price for the item, for a plurality of items or a total on the cash
register and
an attribution of a mode of payment.
The random rebate generator randomly determines 16 if an rebate or
reimbursement proportional to the purchase price is to be awarded to the
client.
The random rebate generator is programmed to award rebates according to a
predetermined rebate attribution table, for example, one in one hundred. When
the random rebate generator is activated, it randomly decides whether this
activation is the one in one hundred rebate attributing activation.
If the random rebate generator determines that this activation is rebate
attributing, the purchase price is reduced by the proportional amount 18. If
the
total was already paid, the reimbursement can be carried out using the same
means as the payment was made with or by any other means. If the payment is
not yet received for the purchase, the proportional amount is attributed as a
rebate on the purchase price.
Preferably, the proportional amount or percentage attributed can be printed by
a
ticket printer on a ticket using text or a barcode. If the ticket printer
prints a
barcode, the barcode can then be read by the optical reader of the cash
register
to directly calculate the reimbursement or rebate to be given to the customer.
Preferably, the proportional amount is the full purchase price, the client
therefore receiving a complete reimbursement or rebate for his purchase. This
has an immediate positive effect on the client and on the other customers
waiting in line at the cash registers. The client then leaves the store with
his
items without having paid anything.
As will be understood, in the case the rebate attributed is the full purchase
price, the more expensive the average purchase price per customer is, the
lesser chances of being attributed the rebate should be used in order to
ensure
that the retail store owner does not lose more than a predetermined percentage
of his revenues to this incentive.
CA 02495243 2005-02-07
WO 2004/019292 PCT/CA2003/001273
-7-
Preferably, the retail store owner calculates an average purchase price per
customer at his store and determines an acceptable portion of his revenues
that
he is willing to assign to this incentive. Once both of these variables are
obtained, .the odds are calculated and programmed in the random rebate
generator.
Some retail store owners may prefer to give only a percentage less than 100
of the purchase price as a rebate. Again the odds can be calculated for the
specific needs of the retail store owner and the random rebate generator can
be
programmed accordingly.
Examples of rebate attribution tables are provided in Figures 3 to 12. These
are
examples of payout probabilities that can be programmed in the random rebate
generator to yield an average return chosen by the store owner. For the
purposes of illustrating the return, the average purchase price of the
customers
was set to 100 $. As will be understood, this average purchase price could be
set to any amount. The rebate attribution table would still show the same
return.
As will also be understood, not all customers will buy items amounting to the
average purchase price, this will therefore influence the return rate in the
shorfi
term. Also, since the determination of the customers receiving a rebate is
done
randomly, there may be variations in the return in the short term. However, in
the long run, the return programmed within the random rebate generator will be
respected.
Figures 3 to 12 are rebate attribution table examples showing different
reimbursement or rebate and return schemes. It will be understood that a
rebate
attribution table for any return rate with a number of customers receiving a
rebate and customers not receiving a rebate could be built and used by the
system. FIG. 3 is a rebate attribution table for a return of 2 %, with 300
customers receiving a rebate; FIG. 4 is a rebate attribution table for a
return of 2
%, with 500 customers receiving a rebate; FIG. 5A and FIG. 5B together are a
rebate attribution table for a return of 2 %, with 11450 customers receiving a
rebate and 6 customers not receiving a rebate; FIG. 6 is a rebate attribution
table for a return of 1.48 %, with 11405 customers receiving a rebate; FIG. 7
is
a rebate attribution table for a return of 1.48 %, with 11405 customers
receiving
a rebate and 5 customers not receiving a rebate; FIG. 8 is a rebate
attribution
CA 02495243 2005-02-07
WO 2004/019292 PCT/CA2003/001273
_$_
table for a return of 1.48 %, with 200 customers receiving a rebate and 1000
customers not receiving a rebate; FIG. 9 is a rebate attribution table for a
return
of 1 %, with 16096 customers receiving a rebate; F(G. 10 is a rebate
attribution
table for a return of 9.5 %, with 1200 customers receiving a rebate; FIG. 11
is a
rebate attribution table for a. return of 10.3 %, with 10000 customers
receiving a
rebate; FIG. 12 is a rebate atfiribution table for a return of 5 %, with 200
customers receiving a rebate and 85 customers not receiving a rebate.
The rebate attribution tables can be built to ensure that a minimum percentage
of the purchase price will always be awarded to the customer. Examples of such
tables are found in FIG. 3, 4, 6, 9, 10 and 11. Other rebate attribution
tables can
have customers not receiving a rebate, that is customers who are awarded a
reimbursement or rebate of 0 %.
It will be understood that the random rebate generator may be programmed with
a plurality of rebate attribution tables to allow flexibility of the system.
For
example, one store owner may decide to have three rebate attribution tables
depending on the day the purchase is made. The first rebafie attribution table
would give a return of 1 % and would be the one typically used. A second
rebate attribution table with a return of 2 % would be used on special days
advertised by the store owner or an third party. A third rebate attribution
table
would guarantee that each client receives at least a reimbursement or rebate
of
10 %, while maintaining a return of 1 % and would be used on weekends. It will
be understood that any combination of rebate attribution tables could be used
to '
suit the store owners' needs.
Preferably, the system is provided by a third party which rents the random
rebate generators. This third party can then manage the publicity of the
system
by advertising the list of stores which offer such a chance to be awarded a
reimbursement or rebate of purchases. This third party can also decide to
publish the list of recent customers who have been awarded large amounts.
This third party publicity can be done in parallel with the store owner's own
publicity efforts.
This method could be used in conjunction with traditional publicity means such
as ads in local newspapers where the total number of customers who have
CA 02495243 2005-02-07
WO 2004/019292 PCT/CA2003/001273
_g_
received a rebate could be indicated or the names of the last customers who
have received a rebate could be printed. For example, the last ten customers
who have received a rebate could be displayed.
Sales taxes are common in industrialized countries. A retail store owner may
decide to reimburse the full purchase price including taxes to the customer
and
absorb the tax amount or may decide to only give back the amount
corresponding to the purchase price before taxes. The customer therefore
receives almost 100 °/o of his purchase price, less the percentage
amount
corresponding to taxes in that particular state and country.
The method can comprise a further optional step of the client confirming 14
his
participation in the random attribution of the rebate. This confirmation can
be
done using a slap button placed on the counter where items are placed to be
purchased. The client would then slap the button after the purchase price is
determined. This would trigger the random rebate generator to carry out the
attribution of the rebate. This step involves the participation of the client
and
makes him believe the moment he chooses to press the participation recorder
has an effect on the attribution of the rebate.
The confirmation could include requesting an answer to a skills testing
question,
the answer of which would be used to confirm the awarding of the rebate in
states where legislation requires a correct answer to such a question to be
awarded the rebate.
Displaying the outcome of the random attribution of the rebate to the customer
is also preferred to show him that the cashier is not trying to prevent him
from
getting his rebate. This also attracts the attention of the other customers
and
generates interest for the system.
Once the rebate is awarded, the cashier preferably records the name of the
client having received the rebate, displays it on a small screen near the cash
register and arranges for a special message to be displayed on a bigger screen
in the store. This message reminds customers that it is possible to be awarded
at least a portion of your purchase in this particular store and can generate
even
more interest if a customer recognizes a name from the message display.
A sound can also be generated when the customer receives a rebate or not.
CA 02495243 2005-02-07
WO 2004/019292 PCT/CA2003/001273
-10-
Another sound can also be played while the random rebate generator
determines the result of the attribution of the rebate. The rebate attribution
sound may be a recorded voice saying : "Your purchase is free ! Please ask the
cashier for your rebate !" These all increase customers' interest.
The random rebate generator does not have to be connecfied to the cash
registers. In order to install this system more rapidly and easily, the
cashier may
be responsible to manually activate the random rebate generator and manually
enter in the cash register the result of the attribution of the rebate. In
these
cases however, it would be preferable that a synchronization methodology be
used to track which purchases yielded reimbursements or rebates. This
synchronization methodology may be the time and date of the purchase, the bill
number, the signature of the client on bofih transactions, etc.
In addition or alternatively to receiving a proportional amount of the
purchase
price, the customer could be given a chance in a random draw among all
customers who have received a rebate in that day, week, month or year. The
amount awarded in that additional draw would typically be much greater than
the average purchase price. The tickets to participate in this draw could be
printed directly from the ticket printer. The ticket printer can be triggered
by the
random rebate generator. If necessary, a keyboard can be provided to enter the
name and telephone number of the customer who will participate in the
additional draw.
A customer fidelity program could be used in conjunction with this system. A
customer, member of the customer fidelity program, could be awarded two
chances of receiving the purchase amount or may have access to a different
rebate attribution table. This privileged customer may also get a chance of
receiving a multiple of the percentage received in the first attribution of
the
rebate. The store owner may decide to limit the amount reimbursed or remitted
to the customer to 100 %. Because this privileged customer has taken the time
to register in the customer fidelity program, special promotions may only be
accessible to him. For example, a profile of his purchases can be built and
offers can be proposed to him depending on this profile and can yield even
better odds in the random attribution of the rebate.
CA 02495243 2005-02-07
WO 2004/019292 PCT/CA2003/001273
-11-
The customer who is a member of the fidelity program may receive a fidelity
card. This fidelity card confirms that he has access to the special fidelity
program. If such a card is provided to the privileged customers, a
participation
recorder can have a card reader able to receive the fidelity card and retrieve
information about the customer from the card's memory. This would then
identify the client and, in case the client receives a rebate, would
accelerate the
process of obtaining his identification. This fidelity card could be assigned
a
personal identification number (PIN) to be entered in the participation
recorder
to ensure that the proper person is using the fidelity card. A PIN attribution
device could then be provided with the system to allow customers to choose
and program their own PIN into the fidelity card. This fidelity card could be
combined with an existing credit or debit card if such a card can be further
programmed.
Referring now to FIG. 2, the main components of the present invention will be
described. The system for awarding an instant rebate comprises a cash register
or point-of-sale device 20 for completing a purchase of at least one item for
a
purchase price. The cash register 20 has peripherals 38 such as a keyboard, a
barcode scanner, a scale, a screen, a printer, etc. A data gathering device 40
intercepts data communicated between the cash register 20 and its peripherals
38 to determine the item being purchased and its purchase price. The data
intercepted is then directly sent back to the cash register 20 or further
processed by the random rebate generator 22 before being sent back to the
cash register 20. A random rebate generator 22 receives a signal confirming
that a purchase price has been determined (an item price was determined, a
sub-total was reached or the purchase was completed) from the data gathering
device 40 and determines if an amount proportional to the purchase price is to
be awarded to the client. The cash register 20 is then used to complete a
reimbursement or rebate of the proportional amount to the client if the
proportional amount is determined to be awarded.
Preferably, a client participation recorder 24 is used to confirm that the
client
making the purchase wishes to participate in a attribution of the rebate by
the
random rebate generator 22.
The system can further include a transaction dialer 28 for contacting a card
CA 02495243 2005-02-07
WO 2004/019292 PCT/CA2003/001273
- 12-
issuer when a client making the purchase is paying the purchase price using a
credit or a debit card, the random rebate generator 22 is then activated
either by
the transaction dialer once the transaction with the card issuer is completed
or
by the cash register 20 when the authorization is received through the
transaction dialer 28.
A display 26 for displaying a result of the attribution of the rebate adds to
the
interest of the system for the customers.
The cash register 20 preferably uses a rebate calculator 32 to determine the
amount to be reimbursed or remitted, especially if the rebate amount is less
than 100 % of the purchase price. The rebate calculator 32 receives the
percentage determined by the random rebate generator 22 and receives the
purchase price from the cash register 20. It then calculates the appropriate
reimbursement or rebate amount to be reimbursed or remitted to the client. A
sales tax calculator 30 may also be needed if sales taxes are not to be
reimbursed or remitted to the client because of local regulations.
Depending on the implementation, the rebate and taxes calculators 32, 30 can
communicate directly with the random rebate generator 22 so that the
information sent back to the cash register 20 already includes the appropriate
rebate.
A,ticket printer 34 is preferably provided and is triggered by the random
rebate
generator 22 to print a confirmation of the result of the attribution of the
rebate.
This confirmation can include the percentage of the purchase amount to be
reimbursed or remitted. A keyboard 38 is also preferably provided to enter the
name and telephone number of the customer into the ticket printer 34 so that
the confirmation ticket printed includes such an identification of the
customer
who received a rebate. This may be necessary in countries where the names of
customers who have received a rebate of more than a certain amount in a
' random attribution of the rebate must be declared to a public authority.
It will be understood that the system of the present invention could be
networked within the store, throughout the chain of stores of a particular
brand,
or throughout a specific region of a chain of stores of a particular brand.
The
display of the last customers who have received a rebate could be generic to
CA 02495243 2005-02-07
WO 2004/019292 PCT/CA2003/001273
-13-
the complete network or personalized for a particular portion of the network.
Some elements of the system could be networked while others would be
independent.
Another embodiment of the invention could take on the aspect of an add-on to a
credit or debit transaction apparatus. The apparatus would include the
following:
a transaction recorder for recording a purchase by a client of at least one
item
for a purchase price, a transaction dialer for contacting a card issuer when
the
client is paying the purchase price using a credit or a debit card, a random
rebate generator receiving a signal either from the transaction recorder or
the
transaction dialer and determining if an amount proportional to the purchase
price is to be awarded to the client. )n this embodiment the present invention
is
fully realized using software and is implemented directly info an InteracTM or
other credit or debit transaction apparatus.
In that embodiment, the transaction recorder records a reimbursement or rebate
transaction of the proportional amount to the client if the proportional
amount is
determined to be awarded and the transaction dialer completes the
reimbursement or rebate transaction with the card issuer.
The client participation recorder for confirming that a client making the
purchase
wishes to participate in an attribution of the rebate by the random rebate
generator can simply be entering into the apparatus a personal identification
number (PIN) assigned to the card or pushing an "OK" button on the apparatus.
Preferably, the display used in that embodiment is the same display as the one
used to complete the credit or debit transaction.
In another embodiment, a specific purchase may entitle a customer to access a
different rebate attribution table with better odds. For example, a store
owner
may identify a product in the store, for example, peanut butter of a certain
brand
in a grocery store, which will trigger the use of an alternative rebate
attribution
table by the random rebate generator. The fact that the client has purchased
the
specific product may be manually confirmed by the cashier or, using the data
gathering device, the random rebate generator can determine from the product
identification code if the specific product has been purchased and then use
the
appropriate rebate attribution table.
CA 02495243 2005-02-07
WO 2004/019292 PCT/CA2003/001273
-14-
Similarly, different rebate attribution tables can be used depending on the
profile
of the customer. For example, senior citizens having proper identification may
have access to a higher-rebate attribution table on certain days of the week.
In still another embodiment of the present invention, the invention could take
on
the form of a fully integrated add-on in a standard cash register, such as a
cash
register manufactured by NCR. The apparatus would include the same
elements. In this embodiment, the present invention is fully realized using
software and is implemented directly info a NCR cash register.
In that embodiment, the display used is the customer display of the cash
register and the ticket printer if provided, is the receipt printer.
In a further embodiment of the present invention, illustrated in FIG. 13A, the
cash register 20 can be connected to a ticket printer 38. This ticket printer
38,
which may be the standard receipt printer of the cash register, can print a
ticket
which mentions the purchase price. The purchase price can be written on the
ticket or may be represented by a barcode. For example, the purchase price
before taxes can be $ 24.95 and the ticket printer can print a ticket
mentioning
this amount using a barcode.
Irregardless of whether the ticket printed is the same as the receipt
typically
given to the customer, the customer may then go to a rebate awarding station
shown in FIG. 13B, with the ticket. The rebate awarding station has a ticket
reader 42. The ticket reader 42 may read the purchase price from the ticket.
If
the purchase price is coded in a barcode, the ticket reader 42 is a barcode
reader. Preferably, the ticket bears a date and/or time which can be used to
determine the validity of the ticket by the validity checker 48. For example,
the
ticket may only be valid for a period of 20 minutes following the purchase, or
can be valid for a period of two weeks following the purchase.
If the ticket is valid, and preferably following an action by the customer to
be
done using the participation recorder 24, the random rebate generator 22 then
determines if a reimbursement or rebate is to be awarded to the customer. If
such a reimbursement or rebate is to be given, it is preferably displayed by
the
display 44. The random rebate generator 22 can then be connected to a
validated ticket printer 46 which prints the percentage of the purchase price
CA 02495243 2005-02-07
WO 2004/019292 PCT/CA2003/001273
-15-
awarded to the customer on the original ticket or on a new ticket. This
ensures
that the percentage 'awarded by the system may not be altered by a cashier or
a
customer with poor ethics. The validated ticket can then be taken to a cash
register assigned to the rebate awarding station or any other cash register
for a
reimbursement or rebate of the proportional amount. The validated ticket can
also be kept by the customer for use in a future purchase in the store. The
validated ticket can be assigned a duration for use.
Preferably, the ticket reader 42 and the validated ticket printer 46 are
provided
in a single apparatus which receives the ticket, retrieves the information
from it,
requests validation by the validity checker 48 and receives the signal with
information on the rebate attributed. It then prints the proportional amount
or
percentage attributed directly on the same ticket and ejects it.
Preferably, the proportional amount or percentage printed by the validated
ticket
printer 46 has the form of a barcode which can then be read by the optical
reader of the cash register to directly calculate the reimbursement or rebate
to
be given to the customer.
This embodiment allows a single rebate awarding station to be used in
conjunction with a plurality of cash registers in a particular store or in one
location for a plurality of stores. It therefore does not delay handling of
the
purchase at the cash register. Customers who wish to participate in the random
attribution of the rebate simply have to walk to the rebate awarding station
in
order to receive their validated ticket.
Shown in FIG. 14 is the data gathering system. The Data Gathering Device 40,
DGD, is placed between the computer in a Point-Of-Sale system (the cash
register 20), POS, and its peripherals 38 such as keyboard 52, scale 54 and
bar
code scanner 56 to intercept the data and redirect it to an external computer,
the random rebate generator 22 (RRG), for analysis before it is allowed
through
to the POS 20 in its original or in a somewhat altered form. This way, not
only
can the DGD 40 allow the RRG 22 to know all the details of a transaction being
performed at the POS 20, but it allows the RRG 22 to track and to act on this
data and perform some related function and/or alter the data before it is re-
injected for processing by the POS 20.
CA 02495243 2005-02-07
WO 2004/019292 PCT/CA2003/001273
-16-
The DGD 40 is preferably made up of nine serial ports, one universal serial
bus
(USB) port, and one custom keyboard infierface plus some additional circuitry
for
power supply regulation and general interface purposes.
The use of the serial ports is as follows. Six of the nine available serial
ports are
paired into Data-In/Data-Out pairs each dedicated to a particular peripheral,
in
this instance, a bar code scanner, a weight scale and a random rebate
generator peripheral. The seventh port is dedicated to the communication
between the DGD 40 and the RRG 22. Finally, the remaining two serial ports
are general purpose serial ports reserved for future uses.
The USB port is not in use in this implementation of the circuitry but will be
useful in the future when more elaborate and more time intensive tasks are
required from the system such as higher speed communication with the RRG 22
because of higher data load to be transferred or as more "intelligent"
peripherals
that therefore require higher bandwidth are introduced in the POS environment.
Finally, the keyboard interface is used in the same manner as the serial
ports,
that is, so as to allow the RRG 22 to monitor and possibly take action
depending on the nature of the information being input into the POS. All data
from the peripherals are redirected by the DGD 40 to the RRG 22 for tracking
and analysis.
The DGD 40 comprises a microcontroller, uC 70, programmed to poll the
various input ports and report any and all activity to the RRG 22 for
processing.
Furthermore, the uC 70 is responsible for the interpretation and tagging of
the
information transmitted to the RRG 22.
When the uC detects data present at a particular port, it initiates the
transfer of
this data into its buffer and starts the re-transmission procedure to the RRG
22.
Once the RRG 22 has received the data it can act upon it and instruct the uC
to
let the data through or to transmit the altered data that the RRG 22 sends the
uC. The architecture of the uC circuit 70 is illustrated in FIG. 15.
CA 02495243 2005-02-07
WO 2004/019292 PCT/CA2003/001273
-17-
Detailed Description of the Hardware
The function of each of the principal elements of the DGD circuit will be
explained.
The PIC 18F452-AN
The microcontroller used in this embodiment of the DGD is a member of
Microchip's PIC18FXX2 series of high performance RISK microcontrollers. The
particular device used is the PIC18F452-AN microcontroller 70. These devices
come in 40/44-pin packages. A pin by pin function description of the inputs
and
outputs (I/O) and other connections used on the device will be given. It is
not
the intent nor the purpose of this text to give an introductory tutorial in
the use
and programming of microcontrollers and more specifically of these devices.
For
further information on the matter and the internal hardware and software
workings of the PIC18FXX2 family, the reader is referred to Microchip's
DS39564B Datasheet document that describes the inner workings of the
microcontrollers in this family.
Pin 1:
The MCLR/VPP pin is the Master Clear (input) or high voltage ICSP
programming enable pin. It is held high to indicate that the device is not to
reset
and to enable its programming.
Pin 2:
This pin is a general input/output pin of Port A of the device. It is used
here to
generate the reset signal for all the other DGD system peripherals at the
beginning of the execution of the programmed instructions.
Pins 33-40:
These pins are part of Port B of the device and are used by the DGD system as
the I/O interface to the keyboard. Specifically Pins 33, 34, 35 and 36 are
outputs
CA 02495243 2005-02-07
WO 2004/019292 PCT/CA2003/001273
-18-
to the keyboard and the other pins are inputs to the microcontroller from the
keyboard.
Pins 10 and 15-18 and Pins 23-24:
These are I/O pins that belong to the Port C of the device and are used here
as
an address bus to select and access individual areas/capabilities of the DGD
hardware. Of course, it should be clear to the reader that these pins could
also
be used as address pins with any other DGD peripherals that could be
interfaced to it.
Pins 25-26: '
These are I/O pins that belong to the Port C of the device and are used here
as
the receive input and transmit output from the microcontroller to the serial
port
dedicated to the communication with the RRG 22.
Pins 19-22 and Pins 27-30:
These are I/O pins that belong to the Port D of the device and are used here
as
a internal data bus for the input and output of information to and from the
microcontroller and the DGD's peripheral devices.
Pins 8-9:
These are I/O pins that belong to the Port E of the device and are used here
as
control signals for the I/O operations to and from the microcontroller to the
peripherals that are part of the serial port and USB port sub-system of the
DGD.
Here again, it should be clear to the reader that these pins could also be
used
as read and write signals with any other DGD peripherals that could be
interfaced to it. Pin 8 is a general write signal and pin 9 is a general read
signal.
Pin 13:
Pin 13 is a clock input to the microcontroller and is self-explanatory.
CA 02495243 2005-02-07
WO 2004/019292 PCT/CA2003/001273
-19-
The DS14C232:
The DS14C232 is a low power dual driver/receiver featuring an onboard DC to
DC converter, eliminating the need for ~12V power supplies. The device only
requires a +5V power supply. The driver's slew rate are set internally and the
receivers feature internal noise filtering, eliminating the need for external
slew
rate and filter capacitors. The device is designed to interface data terminal
equipment (DTE) with data circuit-terminating equipment (DCE). The driver
inputs and receiver outputs are TTL and CMOS compatible. DS14C232C driver
outputs and receiver inputs meet TIA/EIA-232-E (RS-232) and CCITT V.28
standards.
VCC (Pin 16)
Power supply pin for the device, +5V (~10%).
V+ (Pin 2)
Positive supply for TIA/EIA-232-E drivers. An external capacitor of 1.0 pF
(6.3V)
is used as a power reserve. A capacitor of value larger than 1 ~F may be used.
This supply is not intended to be loaded externally.
V- (Pin 6)
Negative supply for TIA/EIA-232-E drivers. An external capacitor of 1.0 pF
(6.3V) is used as a power reserve. A capacitor of value larger than 1 pF may
be
used. This supply is not intended to be loaded externally.
C1+, C1- (Pins 1, 3)
External capacitor connection pins. used by the internal charge pump to
generate the TIA/EIA-232-E levels. A capacitor of 10 pF is used here.
C2+, C2- (Pins 4, 5)
CA 02495243 2005-02-07
WO 2004/019292 PCT/CA2003/001273
-20-
External capacitor connection pins, used by the internal charge pump to
generate the TIA/EIA-232-E levels. A capacitor of 10 pF is used here.
DIN 1, DIN 2 (Pins 11, 10)
Driver input pins are TTL/CMOS compatible. These pins connect the
microcontroller and/or its peripherals and/or RRG 22's transmit, Tx, pins.
DOUT 1, DOUT 2 (Pins 14, 7)
Driver output pins conform to TIA/EIA-232-E levels. These pins connect the
microcontroller and/or its peripherals and/or RRG 22's receive, Rx, pins.
RIN 1, RIN 2 (Pins 13, ~)
Receiver input pins accept TIA/EIA-232-E ~ input voltages (~25V). Receivers
possess a noise filter and guaranteed hysteresis of 100 mV.
ROUT 1, ROUT 2 (Pins 12, 9)
Receiver output pins are TTL/CMQS compatible.
GND (Pin 15)
Ground Pin.
TL16C554 ASYNCHRONOUS COMMUNICATIONS ELEMENT:
The TL16C554 is an enhanced quadruple versions of the TL16C550B
asynchronous communications element (ACE). Each channel performs serial-
to-parallel conversion on data characters received from peripheral devices and
parallel-to-serial conversion on data characters transmitted by the CPU, in
this
case the POS and/or RRG 22. The complete status of each channel of the
quadruple ACE can be read at any time during functional operation by the RRG
22. The information obtained includes the type and condition of the operation
CA 02495243 2005-02-07
WO 2004/019292 PCT/CA2003/001273
-21 -
performed and any error conditions encountered. The TL16C554 quadruple
ACE can be placed in an alternate first-in first-out (F1F0) mode, which
activates
the internal FIFOs to allow 16 bytes (plus three bits of error data per byte
in the
receiver FIFO) to be stored in both receive and transmit modes. To minimize
system overhead and maximize system efficiency, all logic is on the chip. Two
terminal functions allow signaling of direct memory access (DMA) transfers. We
will now describe the function of each of the pins in use in this design.
Pins 32-34:
Register select terminals. A0, A1, and A2 are three inputs used during read
and
write operations to select the ACE register to read or write.
Pins 16, 20, 50 and 54:
Chip select signals CSA, CSB, CSC and CSD. Each chip select (CSx) enables
read and write operations to its respective channel.
Pins 17, 19, 51 and 53:
Transmit outputs signals TXA, TXB TXC, TXD. TXx is a composite serial data
output that is connected to a communications device. TXA, TXB, TXC, and TXD
are set to the marking (high) state as a result of reset.
Pins 7, 29, 41 and 63:
Serial input signals RXA, RXB, RXC and RXD. RXx is a serial data input from a
connected communications device. During loop back mode, the RXx input is
disabled from external connection and connected to the TXx output internally.
Pin 52:
Read strobe IOR. A low level on IOR transfers the contents of the TL16C554
data bus to the external system bus.
CA 02495243 2005-02-07
WO 2004/019292 PCT/CA2003/001273
-22-
Pin 18:
Write strobe IOW. IOW allows the CPU to write into the selected address by the
address register.
Pin 37:
Master reset. When active, RESET clears most ACE registers and sets the
state of various signals.
The transmitter output and the receiver input is disabled during reset time.
Pin 35:
External clock input. An external clock can be connected to drive the internal
clock circuits.
Pins 1-5 and 66-68:
I/O Data bus D7-D0. Eight data lines with 3-state outputs provide a
bidirectional
path for data, control, and status information between the TL16C554 and the
microcontroller. DO is the least significant bit (LSB).
USBN9603/USBN9604 Universal Serial Bus Full Speed Node Controller
This device will be of use in the near future when higher speed peripherals
and
more complex data need to be sent by the DGD to' the RRG 22 for processing.
As an example of a future system that would require such high speed
communication one may think of an automated check out counter where some
and even all item being checked out by a customer would be identified by a
computer vision system and then input to the POS computer for tabulation.
Such a system would require a tremendous amount of data to flow between the
RRG 22 and the POS and would therefore require a much faster interface.
The device is a Universal Serial Bus (USB) Specification, 1.0 and 1.1. It
CA 02495243 2005-02-07
WO 2004/019292 PCT/CA2003/001273
-23-
integrates onto a single IC the required USB transceiver with a 3.3V
regulator,
the Serial Interface Engine (SIE), USB endpoint FIFOs, a versatile (eight-bit
parallel or serial) interface and a clock generator. A tots( of seven endpoint
pipes are supported: one bidirectional for the mandatory control EPO and an
additional six for unidirectional endpoints to support USB interrupt, bulk and
isochronous data transfers. The 8-bit parallel interface supports multiplexed
and
non-multiplexed style CPU address/data buses. The synchronous serial
MICROWIRE interface allows adapting to CPUs without external address/data
buses. A programmable interrupt output scheme allows adapting to different
interrupt signaling requirements.
The device contains a high-speed transceiver which consists of three main
functional blocks: differential receiver, single-ended receiver with on-chip
voltage reference and transmitter with on-chip current source.
This transceiver meets the performance requirements described in Chapter 7 of
the USB Specification, Version 1.1. To minimize signal skew, the differential
output swings of the transmitter are well balanced. Slew-rate control is used
on
the driver to minimize radiated noise and crosstalk. The drivers support -fRl-
STATE operation to allow bidirectional, half-duplex operation of the
transceiver.
The differential receiver operates over the complete common mode range, and
has a delay guaranteed to be larger than that of the single-ended receivers.
This avoids potential glitches in the Serial Interface Engine (SIE) after
single-
ended zeros. Single-ended receivers are present on each of the two data lines.
These are required, in addition to the differential receiver, to detect an
absolute
voltage with a switching threshold between 0.8V and 2.OV (TTL inputs). To
increase Vcc rejection, without glitching, 'a voltage reference sets the
single-
ended switching reference. An external 1.5 ~5% K resistor is required on D+ to
indicate that this is a high-speed node. This resistor should be tied to a
voltage
source between 3.OV and 3.6V, and referenced to the local ground, such as the
output provided on pin V3.3.
The voltage regulator provides 3.3V for the integrated transceiver from 5.OV
CA 02495243 2005-02-07
WO 2004/019292 PCT/CA2003/001273
-24-
device power or USB bus power. This output can be used to supply power to
the 1.5 K pull-up resistor. This output _must be decoupled with a 1 pF
tantalum
capacitor to ground. It can be disabled under software control to allow using
the
device in a 3.3V system.
The SIE is comprised of physical (PHY) and Media Access Controller (MAC)
modules. The PHY module includes the digital-clock recovery circuit, a digital
glitch filter, End Of Packet (EOP) detection circuitry, and bit stuffing and
unstuffing logic. The MAC module includes packet formatting, CRC generation
and checking, and endpoint address detection. It provides the necessary
control
to give the NAK, ACK and STALL responses as determined by the Endpoint
Pipe Controller (EPC) for the specified endpoint pipe. The SIE is also
responsible for detecting and reporting USB-specific events, such as
NodeReset, NodeSuspend and NodeResume. The module output signals to the
transceiver are well matched (under 1 nsec) to minimize skew on the USB
signals.
The USB specifications assign bit stuffing and unstuffing as the method to
ensure adequate electrical transitions on the line to enable clock recovery at
the
receiving end. The bit stuffing block ensures that whenever a string of
consecutive 1's is encountered, a 0 is inserted after every sixth 1 in the
data
stream. The bit unstuffing logic reverses this process.
The clock recovery block uses the incoming NR~I data to extract a data clock
(12 MHz) from a 48 MHz input clock. This input clock is derived from a 24 MHz
oscillator in conjunction with PLL circuitry (clock doubter). This clock is
used in
the data recovery circuit. The output of this block is binary data (decoded
from
the NRZI stream) which can be appropriately sampled using the extracted 12
MHz clock. The fitter performance and timing characteristics meet the
requirements set forth in Chapter 7 of the USB Specification.
The ERRG provides the interface for USB function ultimate source or sink of
data. An endpoint pipe facilitates the movement of data between USB and
memory, and completes the path between the USB RRG 22 and the function
CA 02495243 2005-02-07
WO 2004/019292 PCT/CA2003/001273
-25-
endpoint. According to the USB specification, up to 31 such endpoints are
supported at any given time. USB allows a total of 7 6 unidirectional
endpoints
for receive and 16 for transmit. As the control endpoint 0 is always
bidirectional,
the total number is 31. Seven endpoint pipes with the same function address
are supported.
A USB function is a USB device that is able to transmit and receive
information
on the bus. A function may have one or more configurations, each of which
defines the interfaces that make up the device. Each interFace, in turn, is
composed of one or more endpoints.
Each endpoint is an addressable entity on USB and is required to respond to IN
and OUT tokens from the USB RRG 22 (typically a RRG). IN tokens indicate
that the RRG 22 has requested to receive information from an endpoint, and
OUT tokens indicate that it is about to send information to an endpoint.
On detection of an IN token addressed to an endpoint, the endpoint pipe should
respond with a data packet. If the endpoint pipe is currently stalled, a STALL
handshake packet is sent under software control. If the endpoint pipe is
enabled
but no data is present, a NAIL (Negative Acknowledgment) handshake packet is
sent automatically. If the end point pipe is isochronous and enabled but no
data
is present, a bit stuff error followed by an end of packet is senfi on the
bus.
Similarly, on detection of an OUT token addressed to an endpoint, the endpoint
pipe should receive a data packet sent by the RRG 22 and load it into the
appropriate FIFO. If the endpoint pipe is stalled, a STALL handshake packet is
sent. If the end-point pipe is enabled but no buffer is present for data
storage, a
NAK handshake packet is sent. If the endpoint is isochronous and enabled but
cannot handle the data, no handshake packet is sent.
A disabled endpoint does not respond to IN, OUT, or SETUP tokens. The
ERRG maintains separate status and control information for each endpoint
pipe. For IN tokens, the ERRG transfers data from the associated F1F0 to the
RRG 22. For OUT tokens, the ERRG transfers data in the opposite direction.
CA 02495243 2005-02-07
WO 2004/019292 PCT/CA2003/001273
-26-
The parallel interface is the mode of interface that was selected for these
purposes. This allows the device to function as a CPU or microcontroller
peripheral. This interface type and its addressing mode (multiplexed or non-
multiplexed) is determined via device input pins MODEO and MODE1. Non-
multiplexed mode uses the control pins CS, RD, WR, the address pin AO and
the bidirectional data bus D7-0 as shown in This mode is selected by tying
both
the MODE1 and MODEO pins to GND.
The CPU has direct access to the DATA IN, DATA OUT and ADDR registers.
Reading and writing data to the device can be done either in standard access
or
burst mode.
Keyboard Interface Hardware and Protocol:
This section describes the interface used by the PS/2 keyboard. It will cover
the
physical and electrical interface, as well as the protocol.
The Physical Interface:
The physical PS/2 port is one of two styles of connectors: The five-pin DIN or
the six-pin mini-DIN. In this case, the six-pin connector was used and is
illustrated in FIG. 16A and 16 B.
The pins of the six-pin Mini-DIN are as follows:
Data
Not Implemented
Ground
Vcc (+5V)
Clock
Not Implemented
CA 02495243 2005-02-07
WO 2004/019292 PCT/CA2003/001273
-27-
The Electrical Interface:
Vcc/Ground provide power to the keyboard. The keyboard should not draw
more than 100 mA from the RRG 22 and care must be taken to avoid transient
surges. Such surges can be caused by "hot-plugging" a keyboard (i.e.,
connect/disconnect the device while the computer power is on.)
The Data and Clock lines are both open-collector with pull-up resistors to
+5V.
An "open-collector" interface has two possible state: low, or high impedance.
In
the "low" state, a transistor pulls the line to ground level. In the "high
impedance" state, the interface acts as an open circuit and doesn't drive the
line
low or high. Furthermore, a "pull-up" resistor is connected between the bus
and
Vcc so the bus is pulled high if none of the devices on the bus are actively
pulling it low. The exact value of this resistor isn't too important (110 k
Ohms);
larger resistances result in less power consumption and smaller resistances
result in a faster rise time. A general open-collector interface is shown in
FIG.
17.
Communication: General Description
The PS/2 keyboard implements a bidirectional synchronous serial protocol, The
bus is "idle" when both lines are high (open-collector). This is the only
state
where the keyboard/mouse is allowed to begin transmitfiing data. The RRG 22
has ultimate control over the bus and may inhibit communication at any time by
pulling the Clock line low.
The device always generates the clock signal. If the RRG 22 wants to send
data, it must first inhibit communication from the device by pulling Clock
low.
The RRG 22 then pulls Data low and releases Clock. This is the "Request-to-
Send" state and signals the device to start generating clock pulses. The
following table lists the bus states:
Summary: Bus States
CA 02495243 2005-02-07
WO 2004/019292 PCT/CA2003/001273
-28-
Data = high, Clock = high: Idle state.
Data = high, Clock = iow: Communication Inhibited.
Data = low, Clock = high: RRG 22 Request-to-Send
All data is transmitted one byte at a time and each byte is sent in a frame
consisting of 11-12 bits. These bits are:
~ One start bit. This is always 0.
~ Eight data bits, least significant bit first.
~ One parity bit (odd parity).
~ One stop bit. This is always 1.
~ One acknowledge bit (RRG 22-to-device communication only)
The parity bit is set if there is an even number of 1's in the data bits and
reset
(0) if there is an odd number of 1's in the data bits. The number of 1's in
the
data bits plus the parity bit always add up to an odd number (odd parity.)
This is
used for error detection. The keyboard must check this bit and if incorrect it
should respond as if it had received an invalid command.
Data sent from the device to the RRG 22 is read on the falling edge of the
clock
signal; data sent from the RRG 22 to the device is read on the rising edge.
The
clock frequency must be in the range 10 - 16.7 kHz. This means clock must be
high for 30 - 50 microseconds and low for 30 - 50 microseconds. Timing is
crucial in order to properly communicate the data.
Communication: Device-to-RRG 22
The Data and Clock lines are both open collector. A resistor is connected
CA 02495243 2005-02-07
WO 2004/019292 PCT/CA2003/001273
-29-
between each line and +5V, so the idle state of the bus is high. When the
keyboard or mouse wants to send information, it first checks the Clock line to
make sure it is at a high logic level. If it isn't, the RRG 22 is inhibiting
communication and the device must buffer any to-be-sent data until the RRG 22
releases Clock. The Clock line must be continuously high for at least 50
microseconds before the device can begin to transmit its data.
As mentioned in the previous section, the keyboard and mouse use a serial
protocol with 11-bit frames. These bits are:
~ One start bit. This is always 0.
~ Eight data bits, least significant bit first.
~ One parity bit (odd parity).
~ One stop bit. This is always 1.
The keyboard writes a bit on the Data line when Clock is high, and it is read
by
the RRG 22 when Clock is low.
Fig. 18 is a timing diagram for the Device-to-host communication. The Data
line
changes state when Clock is high and that data is valid when Clock is low.
Figure 19 is an example of a scan code for the "Q" key (15h) being sent from a
keyboard to the computer. Channel A is the Clock signal; channel B is the Data
signal.
The clock frequency is 10-16.7 kHz. The time from the rising edge of a clock
pulse to a Data transition must be at least 5 microseconds. The time from a
data
transition to the falling edge of a clock pulse must be at least 5
microseconds
and no greater than 25 microseconds.
The RRG 22 may inhibit communication at any time by pulling the Clock line low
for at least 100 microseconds. If a transmission is inhibited before the 11th
clock
CA 02495243 2005-02-07
WO 2004/019292 PCT/CA2003/001273
-30-
pulse, the device must abort the current transmission and prepare to
retransmit
the current "chunk" of data when RRG 22 releases Clock. A "chunk" of data
could be a make code, break code, device ID, mouse movement packet, etc.
For example, if a keyboard is interrupted while sending the second byte of a
two-byte break code, it will need to retransmit both bytes of that break code,
not
just the one that was interrupted.
If the RRG 22 pulls clock low before the first high-to-low clock transition,
or after
the falling edge of the fast clock pulse, the keyboard does not need to
retransmit
any data. However, if new data is created that needs to be transmitted, it
will
have to be buffered until the RRG 22 releases Ciock. Keyboards have a 16-byte
buffer for this purpose. If more than 16 bytes worth of keystrokes occur,
further
keystrokes wil( be ignored until there's room in the buffer.
Host-to-Device Communication:
The PS/2 device always generates the clock signal. If the RRG 22 wants to
send data, it must first put the Clock and Data lines in a "Request-to-send"
state
as follows:
~ Inhibit communication by pulling Clock low for at least 100 microseconds.
~ Apply "Request-to-send" by pulling Data low, then release Clock.
The device should check for this state at intervals not to exceed 10
milliseconds. When the device detects this state, it will begin generating
Clock
signals and clock in eight data bits and one stop bit. The RRG 22 changes the
Data line only when the Clock line is low, and data is read by the device when
Clock is high. This is opposite of what occurs in device-to-host
communication.
After the stop bit is received, the device will acknowledge the received byte
by
bringing the Data line low and generating one last clock pulse. If the RRG 22
does not release the Data line after the 11th clock pulse, the device will
continue to generate clock pulses until the Data line is released (the device
will
CA 02495243 2005-02-07
WO 2004/019292 PCT/CA2003/001273
-31 -
then generate an error.)
The RRG 22 may abort transmission at time before the 11th clock pulse
(acknowledge bit) by holding Clock low for at least 100 microseconds.
The steps the RRG 22 must follow to send data to a PS/2 device are as follows:
1 ) Bring the Clock line low for at least 100 microseconds.
2) Bring the Data line low.
3) Release the Clock line.
4) Wait for the device to bring the Clock line low.
5) Set/reset the Data line to send the first data bit 6) Wait for the device
to bring
Clock high.
7) Wait for the device to bring Clock low.
8) Repeat steps 5-7 for the other seven data bits and the parity bit 9)
Release
the Data line.
10) Wait for the device to bring Data low.
11 ) Wait for the device to bring Clock low.
12) Wait for the device to release Data and Clock
FIG. 20 shows this graphically and FIG. 21 separates the timing to show which
signals are generated by the RRG 22, and which are generated by the PS/2
device. Notice the change in timing for the "ack" bit--fihe data transition
occurs
when the Clock line is high (rather than when it is low as is the case for the
other 11 bits.)
CA 02495243 2005-02-07
WO 2004/019292 PCT/CA2003/001273
-32-
Referring to FIG. 21, there are two time quantities the RRG 22 looks for: (a)
the
time it takes the device to begin generating clock pulses after the RRG 22
initially takes the Clock line low, which must be no greater than 15 ms; (b)
the
time it takes for the packet to be sent, which must be no greater than 2ms. If
either of these time limits is not met, the RRG 22 should generate an error.
Immediately after the "ack" is received, the RRG 22 may bring the Clock line
low to inhibit communication while it processes data. If the command sent by
the RRG 22 requires a response, that response must be received no later than
20 ms after the RRG 22 releases the Clock fine. If this does not happen, the
RRG 22 generates an error.
Scan Codes:
The keyboard's processor spends most of its time scanning, or monitoring, the
matrix of keys. If it finds that any key is being pressed, released, or held
down,
the keyboard will send a packet of information known as a "scan code" to your
computer. There are two different types of scan codes: "make codes" and
"break codes". A make code is sent when a key is pressed or held down. A
break code is sent when a key is released. Every key is assigned its own
unique make code and break code so the RRG 22 can determine exactly what
happened to which key by looking at a single scan code. The set of make and
break codes for every key comprises a "scan code set". There are three
standard, scan code sets but the most frequently used one is summarized in
FIG. 22.
Make Codes, Break Codes, and Typematic Repeat:
Whenever a key is pressed, the make code for that key is sent to the computer.
A make code only represents a key on a keyboard, it does not represent the
character printed on that key. This means that there is no defined
relationship
between a make code and an ASCII code. It's up to the RRG 22 to translate
scan codes to characters or commands.
Although most of set two make codes are only one-byte wide, there are a
CA 02495243 2005-02-07
WO 2004/019292 PCT/CA2003/001273
-33-
handful of "extended keys" whose make codes are two or four bytes wide.
These make codes can be identified by the fact that their first byte is EOh.
Just as a make code is sent to the computer whenever a key is pressed, a
break code is sent whenever a key is released. In addition to every key having
its own unique make code, they all have their own unique break code.
Fortunately, however, one doesn't always have to use lookup tables to figure
out a key's break code--certain relationships do exist between make codes and
break codes. Most break codes are two bytes long where the first. byte is F0h
and the second byte is the make code for that key. Break codes for extended
keys are usually three bytes long where the first two bytes are EOh, FOh, and
the last byte is the last byte of that key's make code. As an example, a set
of
make codes and break codes for a few keys is shown in FIG. 23.
FIG. 24 shows the typematic repeat rate and FIG. 25 shows the typematic
delay.
If one presses a key, its make code is sent to the computer. When one presses
and holds down a key, that key becomes typematic, which means the keyboard
will keep sending that key's make code until the key is released or another
key
is pressed. For example, a user opens a text editor and holds down the "A"
key.
When he first presses the key, the character "a" immediately appears on the
screen. After a short delay, another "a" will appear followed by a whole
stream
of "a"'s until he releases the "A" key. There are two important parameters
here:
the typematic delay, which is the short delay between the first and second
"a",
and the typematic rate, which is how many characters per second will appear on
your screen after the typematic delay. The typematic delay can range from 0.25
seconds to 1.00 second and the typematic rate can range from 2.0 cps
(characters per second) to 30.0 cps. One may change the typematic rate and
delay using the "Set Typematic Rate/Delay" (OxF3) command.
Typematic data is not buffered within the keyboard. In the case where more
than one key is held down, only the last key pressed becomes typematic.
Typematic repeat then stops when that key is released, even though other keys
CA 02495243 2005-02-07
WO 2004/019292 PCT/CA2003/001273
-34-
may be held down.
Reset:
At power on or software reset, the keyboard performs a diagnostic self-test
referred to as BAT (Basic Assurance Test) and loads the following default
values:
~ Typematic delay: 500 ms.
~ Typematic rate: 10.9 cps.
~ Scan code set: 2.
~ Set all keys typematic/make/break codes.
When entering BAT, the keyboard enables its three LED indicators, and turns
them off when BAT has completed. At this time, a BAT completion code of
either OxAA (BAT successful) or OxFC (Error) is sent to the RRG 22. This BAT
completion code must be sent 500750 milliseconds after power on.
Many of the keyboards tested ignore their CLOCK and DATA lines until after
the BAT completion code has been sent. Therefore, an "Inhibit" condition
(CLOCK line low) may not prevent the keyboard from sending ifs BAT
completion code.
Command Set:
Certain commands can be issued by the RRG to the keyboard. The keyboard
clears its output buffer when it receives any command. If the keyboard
receives
an invalid command or argument, it must respond with "resend" (OxFE). The
keyboard must not send any scan codes while processing a command. If the
keyboard is waiting for an argument byte and it instead receives a command, it
should discard the previous command and process this new one.
CA 02495243 2005-02-07
WO 2004/019292 PCT/CA2003/001273
-35-
Below are the commands the RRG 22 may send to the keyboard:
~ OxFF (Reset) - Keyboard responds with "ack" (OxFA), then enters "Reset"
mode.
i ~ OxFE (Resend) - Keyboard responds by resending the last-sent byte. The
' exception to this is if the last-sent byte was "resend" (OxFE). If this is
the case,
the keyboard resends the last non-OxFE byte. This command is used by the
RRG 22 to indicate an error in reception.
The next six commands can be issued when the keyboard is in any mode, but it
only effects the behavior of the keyboard when in "mode 3" (i.e., set to scan
code set 3.)
~ *OxFD (Set Key Type Make) - Disable break codes and typematic repeat for
specified keys. Keyboard responds with "ack" (OxFA), then disables scanning
(if
enabled) and reads a list of keys from the RRG 22. These keys are specified by
their set 3 make codes. Keyboard responds to each make code with "ack". RRG
22 terminates this list by sending an invalid set 3 make code (e.g., a valid
command.) The keyboard then re-enables scanning (if previously disabled).
~ *OxFC (Set Key Type Make/Break) - Similar to previous command, except this
one only disables typematic repeat.
~ *OxFB (Set Key Type Typematic) - Similar to previous two, except this one
only disables break codes.
~ *OxFA (Set All Keys Typematic/Make/Break) - Keyboard responds with "ack"
(OxFA). Sets all keys to their normal setting (generate scan codes on make,
break, and typematic repeat)
~ *OxF9 (Set All Keys Make) - Keyboard responds with "ack" (OxFA). Similar to
OxFD, except applies to all keys.
CA 02495243 2005-02-07
WO 2004/019292 PCT/CA2003/001273
-36-
~ *OxF8 (Set All Keys Make/Break) - Keyboard responds with "ack" (OxFA).
Similar to OxFC, except applies to all keys. ,
~ *OxF7 (Set All Keys Typematic) - Keyboard responds with "ack" (OxFA).
Similar to OxFB, except applies to all keys.
~ OxF6 (Set Default) - Load default typematic rate/delay (10.9cps / 500ms),
key
types (all keys typematic/make/break), and scan code set (2).
~ OxF5 (Disable) - Keyboard stops scanning, loads default values (see "Set
Default" command), and waits further instructions.
~ OxF4 (Enable) - Re-enables keyboard after disabled using previous command.
~ OxF3 (Set Typematic Rate/Delay) - RRG 22 follows this command with one
argument byte that defines the typematic rate and delay as follows:
~ *OxF2 (Read ID) - The keyboard responds by sending a two-byte device ID of
OxAB, 0x83. (OxAB is sent first, followed by 0x83.)
~ *OxFO (Set Scan Code Set) - Keyboard responds with "ack", then reads
argument byte from the RRG 22. This argument byte may be 0x01, 0x02, or
0x03 to select scan code set 1, 2, or 3, respectively. The keyboard responds
to
this argument byte with "ack". If the argument byte is 0x00, the keyboard
responds with "ack" followed by the current scan code set.
~ OxEE (Echo) - The keyboard responds with "Echo" (OxEE).
~ OxED (Sefi/Reset LEDs) - The RRG 22 follows this command with one
argument byte, that specifies the state of the keyboard's Num Lock, Caps Lock,
and Scroll Lock LEDs. This argument byte is defined as follows:
F1G. 6 shows the Argument Byte Table "X". In the Argument Byte, the following
bits are defined:
CA 02495243 2005-02-07
WO 2004/019292 PCT/CA2003/001273
-37-
~ "Scroll Lock" - Scroll Lock LED off(0)/on(1 )
~ "Num Lock" - Num Lock LED off(0)/on(1 )
~ "Caps Lock" - Caps Lock LED off(0)/on(1 ). Originally available in PS/2
keyboards only.
Detailed Description of the Software:
The function of each routine element of the DGD software will now be
discussed.
FIG. 27 is a flow chart of the events and the flow of the main program loop.
As
stated earlier, the microcontroller polls every port constantly and waits for
data
to be present and then sends it to the RRG 22.
This is even more clearly illustrated in the following code from an example
main
loop of the program:
00035 void main(void)
00036 (
00037 // pause
00038 Delay10KTCYx(255); // approx 400 ms
00039 Delay10KTCYx(255); // approx 400 ms
00040
00041 RRGLink init();
00042 uart Init();
CA 02495243 2005-02-07
WO 2004/019292 PCT/CA2003/001273
-38-
00043
00044 wart Set96008N1(SCANNER DEV);
00045 uart Set96008N1(SCANNER_RRG);
00046 uart Set96007E1 (SCALE DEV);
00047 uart Set96007E1 (SCALE RRG);
00048
00049 wart Set96008N1 (SWITCH_POS);
00050
00051
00052 scanner
Init();
00053 weight Init();
00054 keyb_Init();
00055
00056
00057 while(1
)
00058 f
00059 scanner
ReadBarcode();
CA 02495243 2005-02-07
WO 2004/019292 PCT/CA2003/001273
-39-
00060
00061 weight CheckRRGRequest();
00062 weight ReadWeight(); .
00063
00064 keyb-ReceiveFromKeyb();
00065
00066 switch_ReceiveFromSwitch();
00067
00068 if(RRGLink rx())
00069 Dispatch();
00070 )
00071
00072
00073 }
The functions scanner ReadBarcode(), weight CheckRRGRequest(),
weight ReadWeight(), keyb-ReceiveFromKeyb(), switch ReceiveFromSwitch(),
RRGLink rx() and Dispatch() will be explained individually.
scanner ReadBarcode():
Read scanner serial port until CR/LF is received. When final LF is received,
CA 02495243 2005-02-07
WO 2004/019292 PCT/CA2003/001273
-40-
build and transmit a packet to the RRG 22 (with only the barcode data).
weighfi CheckRRGRequest():
Check if the POS software has sent a readscale request (char 87 decimal). If
so, re-inject the request to the scale. The RRG does not need to see the
request, and since the POS software sometimes polls the scale, it would
overload the RRG.
weight ReadWeight():
Read data bytes from scale. Each received char is sent to the POS without
processing. When a CR is received, a copy of the complete weight is send to
the RRG (only if it is different compared to the last weight received).
keyb_ReceiveFromKeyb():
Sample clock line and fetch. Check keyboard for low data line that would
signal
data transmission. A 5ms timeout to receive everything is used.
switch ReceiveFromSwitchQ:
Check data from switch and send it to RRG only if the switch goes from 1 to 0.
RRGLink_rx():
Return true if a packet has been received and is ready fio be processed by the
application. If true is returned, access it via global rxPacket, and when done
set
the "ready" member to 0.
Dispatch():
Take the received packet from RRG and dispatch processing.
~ barcode inject command received from RRG -> send barcode to POS
CA 02495243 2005-02-07
WO 2004/019292 PCT/CA2003/001273
-41 -
~ weight request inject command received from RRG -> send request to scale
~ weight request inject command received from RRG -> send weight to POS
~ key data inject command -> send keyb data to POS
~ set switch pattern -> send switch pattern command to random rebate
generator switch
As will be understood, when data is received from the scale and a product code
is received from the keyboard, the RRG determines that a fresh product was
purchased by the client and can calculate and the purchase price using price
tables provided by the store. Once the purchase price is determined, the
random rebate generator can be triggered.
It should be noted that the present invention can be carried out as a method,
can be embodied in a system, a computer readable medium or an electrical or
electro-magnetical signal.
It will be understood that numerous modifications thereto will appear to those
skilled in the art. Accordingly, the above description and accompanying
drawings should be taken as illustrative of the invention and not in a
limiting
sense. It will further be understood that it is intended to cover any
variations,
uses, or adaptations of the invention following, in general, the principles of
the
invention and including such departures from the present disclosure as come
within known or customary practice within the art to which the invention
pertains
and as may be applied to the essential features herein before set forth, and
as
follows in the scope of the appended claims.
