AU2005225141A1 - Method for Acquiring Product Data - Google Patents

Description

24/10 '05 MON 17:38 FAX 61 2 9888 7600 WATERMARK

AUSTRALIA

01006 P001 Secdlan 2 Regulaion 32(2)) Patents Act 1990 COMPLETE SPECIFICATION STANDARD PATENT Application Number: Lodged: Invention Title: The following statement is a full description of this Invention, including the best method of performing it known to us: COMS ID No: SBMI-01807428 Received by IP Australia: Time 17:49 Date 2005-10-24 24/10 '05 MON 17:38 FAX 61 2 9888 7600 WAEAK J07 WATERMARK [a 007 o METHOD FOR ACQUIRING PRODUCT DATA o FIELD OF THE INVENTION The present invention rerates to a method and system for acquiring product data, and is particularly suited to the collection and management of product sales data from many different locations.

BACKGROUND OF THE INVENTION Small retail stores such as convenience stores sell many different products originating from many different suppliers. Given the limited technological 8 15 resources of many convenience stores, it is often difficult for the store owners to easily collect data relating to the sale of their stock.

In addition, the suppliers of products to these retail stores often have limited information in regard to the products sold at specific locations. While manual figures may be acquired by considering the number of products supplied to a particular location over a certain time period, this data is often not accurate, is of limited detail, and is time consuming to acquire. The same products may also be supplied through many different intermediaries, so the manufacturer itself will not know the final sales location of the products.

For many suppliers, the only way to eff iciently manage their products at retail stores is to employ representatives who regularly visit siores to check and monitor stock levels. Eliminating the need for representatives to frequently visit a large number of stores would improve efficiency and reduce the costs to suppliers.

Alternatively, some suppliers simply make regular telephone calls to retailers to ask whether they require any more stock. It is then the responsibility of the retailer to estimate the amount of stock remaining and how much they are likely to require. This method of stock control is often inaccurate because retailers do not know exactly how much stock they have on hand and in storage at the time sales representative calls, and highly inefficient as often more stock is ordered than is actually required.

It would be advantageous to both suppliers and retailers to have a system that enables the automatic monitoring of purchases to assist with stock re- COMS ID No: SBMI-01807428 Received by IP Australia: Time 17:49 Date 2005-10-24 24/10 '05 MON 17:39 FAX 61 2 9888 7600WAEAK 08 WATERMARK IM008 In 2 ordering and control. It would be further advantageous if the systemn could be accessed and utilised by both the supplier (or manufacturer) and the retailer.

o Many large supermarkets and the like do have sophisticated Point of Sale (POS) systems that are linked to systems incorporating software that ci automatically process the stock at hand. These systems can then provide reports for each product to enable automatic or semi-automatic ordering of new stock.

However, for smaller businesses, which represent approximately 80% of the market, such form of stock control is not achievable.

N In addition, it would be advantageous for suppliers to have a system that 8 15 enables the collecting and acquisition of product data such as the times of day or days of the week when specific products achieve the greatest sales, or which locations have the greatest sales in certain products. This type of information allows marketing strategies to be developed by suppliers or manufacturers in accordance with the sales data collected.

For example, a supplier may wish to run a promotion on one particular product at one store. It would be preferable for such a promotion to be run on the day and time when the particular product usually achieves the highest sales at that particular store. Alternatively, a supplier or manufacturer can use sales and product data acquired on their products to run campaigns on underperforming products or in underperforming areas. Presently gaining such data from retail stores that have limited technological resources is a difficult task.

One available option is to install software onto a retail sales terminal which collects data as products are sold. However, this is not an option for businesses that do not have sophisticated IT systems, and for small retail businesses it is not practical from a cost and system maintenance perspective.

It is an object of the present invention to provide a method and system for collecting and processing product data which is practical for use in a wider range of businesses.

SUMMARY OF THlE INVENTION Broadly, the present invention utilises an electronic payment terminal as a mechanism to collect, process and communicate product information from the point of sale to a remote location.

COMS ID No: SBMI-01807428 Received by IP Australia: Time 17:49 Date 2005-10-24 24/10 '05 MON 17:39 FAX 61 2 9888 7600 WATERMARK 009 3 According to a first aspect of the present invention, there is provided a method for acquiring and communicating product data, said method including the steps of: receiving product identification data at a payment terminal; aggregating said product identification data with at least location identity data to form a message; communicating said message via a network to a server.

According to a second aspect of the present invention, there is provided a system for acquiring and communicating product data, said system including: a payment terminal; means for receiving product identification data at the payment terminal; means for aggregating said product identification data with at least location identity data to form a message; means for communicating said message via a network to a server.

According to a third aspect of the present invention, there is provided a payment terminal enabled to acquire product data, said payment terminal including: means for receiving product identification data; means for aggregating said product identification data with at least location identity data to form a message; means for communicating said message via a network to a remote server.

According to a fourth aspect of the present invention, there is provided a computer program for acquiring product data through a payment terminal, said program including: executing means for receiving product identification data at said payment terminal; executing means for aggregating said product identification data with at least location identity data to form a message; executing means for at least initiating communication of said message via a network to a remote server.

According to a further aspect of the present invention, there is provided a method for acquiring marketing information, including the steps of: COMS ID No: SBMI-01807428 Received by IP Australia: Time 17:49 Date 2005-10-24 24/10 '05 MON 17:39 FAX 61 2 9888 7600 WATERMARK 1010 S4

O

O 5 At a merchant premises, receiving product identification data at a payment terminal, aggregating said product identification data with at least O location identity data to form a message, and communicating said message via a network to a server; S- At said server, processing a plurality of said messages so as to provide marketing information.

According to another aspect, the present invention provides a payment terminal adapted to acquire product data and facilitate a loyalty scheme, said payment terminal including: I' Data means for receiving price information data; O 15 Data means for receiving identity data of a customer; Processing means for generating at least loyalty data messages including at least said identity data, said price information and location identity data; and communicating said data to a remote server; said processing means being responsive to messages from said remote server to provide a loyalty benefit to a customer.

Many small retail businesses have credit card or EFTPOS payment terminals. Given the large number of retailers who have payment terminals, it has been recognised by the inventors that it would be advantageous if such a payment terminal could collect and process product data. Payment terminals have communication links to enable financial transactions to be completed, and the present invention utilises this capability to provide product data reporting. As a consequence, with little extra complexity and expense for the business operator, the payment terminal can provide this valuable capability.

The product data may conveniently be acquired by the payment terminal using a barcode reader, and in a preferred form, is acquired by extracting data from an existing bar code scanner associated with a cash register. In this form, the product data may be collected by the payment terminal at the same time the product data is acquired by the cash register, requiring only one step for both functions.

In another preferred form, the product identification data is further aggregated with timing data prior to the data being communicated to the server.

COMS ID No: SBMI-01807428 Received by IP Australia: Time 17:49 Date 2005-10-24 24/10 '05 MION 17:40 FAX 61 2 9888 7600 WTRAKIji WATERMARK [Moil In This allows further sales and marketing data to be collected end used by suppliers and manufacturers as they wish.

o In another preferred formn, the present invention further provides a mechanism for providing a loyalty program for a specific small business, or group ci of businesses, based on the product data acquired.

BRIEF DESCRIPTION OF THE DRAWINGS One implementation of the present invention will be described with reference to the accompanying figures, in which: Figure 1 is a conceptual diagram of the components of the preferred implementation of the present invention and their interaction; Figure 2 is a conceptual diagram of the operating system used in the preferred implementation of the present invention; Figure 3 is a modified cable and accompanying connectors for collecting the product data according to the preferred implementation of the present invention; Figure 4 is a sample merchant report according to the preferred implementation of the present invention; Figure 5 is a sample report of customer purchases according to the preferred implementation of the present invention.

DESCRIPTION OF PREFERRED EMBODIMENT The present invention will be described with reference to one particular implementation. It will be appreciated that persons skilled in the art could implement the present invention in many different ways, and variations of the invention may be produced without departing from its spirit or scope.

The present invention is not specific to any particular hardware or software implementation, and is at a conceptual level above specifics of implementation.

The following is provided to assist in understanding the practical implementation of one embodiment of the invention.

Figure 1 illustrates the components of the preferred implementation of the present invention. At the retail store [evel, the system includes a payment terminal 1, a modem 2, a barcode scanner 3, and optionally an electronic cash register 4.

The payment terminal 1 is operatively connected to a financial host typically a financial institution, the financial host 5 being responsible for the COMS ID No: SSMI-01807428 Received by IP Australia: lime 17:49 Date 2005-10-24 24/10 '05 MON 17:40 FAX 61 2 9888 7600 WATERMARK @012 Ifn 6 0 O 5 financial transactions made through the payment terminal 1, The payment terminal 1 and the modem 2 (the modem 2 may form part of the payment terminal O 1) are also connected to a data collection host 6, the data collection host 6 being responsible for the acquisition and reporting of the product identification data.

The payment terminal 1 is not limited to any particular type of payment terminal. The payment terminal 1 in the present invention may be any type of electronic credit card or debit card terminal that allows the crediting or debiting of a customer's bank account electronically. This includes terminals suitable for magnetic stripe, smartcard or Internet based payments. However, the payment terminal according to the present invention is not intended to encompass integrated cash register and payment terminals which are linked to in-store IT systems, for example of the type employed by large retail stores and supermarkets. The payment terminal 1 may also have other existing functionality, for example loyalty schemes or stored payment schemes. Payment terminals, as is well understood, are generally required to operate in accordance with the standards and protocols appropriate for a given jurisdiction, and for the particular payment scheme. The details of payment operations per se do not form part of the present invention and will not be described in detail, as they are well understood by those skilled in the art.

Payment terminals are traditionally manufactured by a range of different companies. Each manufacturer generally has its own hardware and software configuration, different from terminals manufactured by other companies.. Whilst it would be possible to implement the present invention using terminals supplied by a single manufacturer, it is strongly preferred that it be implemented on a platform independent basis. Therefore, it is preferred that the operating system and software used to implement the present invention may be utilised by all payment terminals, regardless of the terminal's manufacturer.

The preferred operating system for implementing the present invention on a payment terminal 1 is broadly represented in figure 2. This preferred operating system is an abstraction layer, configuration/application management system, and a multi-acquirer payment system. The operating system is designed to run on any type of secure payment terminal.

COMS ID No:SBMI-01807428 Received by IP Australia: Time 17:49 Date 2005-10-24 24/10 '05 MON 17:40 FAX 81 2 9888 7600 WATERMARK [a013 tf 7 o 5 The operating system contains a set of functions/Application Programming c, Interface (API) which presents a generic interface to the payment application and O the Java Virtual Machine (JVM), The hardware library functions are hidden within this interface. This makes the multi-merchant payment application and JVM easily portable from one platform to another and independent of the terminal hardware and libraries provided by the hardware supplier.

The operating system supports multi-acquirers. Each acquirer is a ifl separate module. The payment module generates a generic payment message Sand expects a generic payment response. It is the responsibility of the acquirer 1 module to package the payment messages into acquirer specific messages.

The presence of the JVM to support a number of Java-based value added applications is where the biggest strength of this system lies. Applications written in Java are even more portable to other terminal platforms since they can be compiled once for all terminals. The same software image can be used on any terminal.

Figure 2 broadly describes one operating system that may be used with the present invention. The component labelled "FPCon" 7 provides a non-terminal specific interact to manipulate the screen text an graphics displays including prompts and menus, differing fonts and languages, screen prompts, timers and clocks, and event handling including smart cards, magnetic cards and port data detections.

The component labelled "FPPrt" 8 provides a non-terminal specific interface to print buffered text and graphics, and to report printer errors.

The component labelled "FPComms" 9 provides non-terminal specific functions to passively and actively open/configure a port, which is used by Value Added Applications 17. It also provides functions to connect and disconnect to a port, and send and receive to and from a port, update mobile signal strength, and report generic communication errors, The component labelled uFPAS2805" 10 provides non-terminal specific functions to convert an AS2805 message stream to native elements in a format that can easily be manipulated, and to convert native elements to an AS2805 message stream.

COMS ID No: SBMI-01807428 Received by IP Australia: Time 17:49 Date 2005-10-24 24/10 '05 MON 17:41 FAX 61 2 9888 7600 WATERMARK 1014 In 8 0 o 5 The component labelled "FPCrypto" 11 provides non-terminal specific functions to the storage of injected keys, encryption functions, store an derive Key 0 O Encrypting Keys (KEKs) and session keys. This specific functions of this component depends upon on the security requirement of the various acquirers programmed into the terminal.

The component labelled "FPMaint" and "FPUpgEng" 12 handles the TMS Engine message and communication. It also manages the configuration downloads and preservation during upgrade, manages non-destructive software ci downloads and manages VAA upgrades.

I'l The component labelled "FPUgd" 13 provides a non-terminal specific o 15 interface to perform last minute destructive upgrade of software.

The component labelled "FPEftpos" 14 provides a non-terminal specific interface to manage acquirer applets in the terminal, marshal data to various acquirer applets, provide access to data stored within the various acquirer applets, and analyses errors reported by the Acquirer applets and provide error descriptions to the terminal.

The component labelled 'AQBank" 15 provides a non-terminal specific interface to provide specific message streams required by the acquirer for various financial messages, analyses message streams from the acquirer and populates the appropriate data required by the payment application, and maintains configuration data for the acquirer.

The component labelled "KLBan"' 16 provides a non-terminal specific interface to inject bank keys and remove the applet after injection.

The component labelled "FPPay" 18 is a generic payment application that controls financial screen flows, reports, manual terminal configuration, activation of Value Added Applications 17, activation of profile maintenance 12, and activation of automatic settlement and logons.

The JVM 19 includes Java security which provides a native firewall to other Value Added Applications 17 and the payment application. The Value Added Applications 17 may include a wide range of applications depending upon the desire of the merchant, for example product data capture applications, loyalty scheme applications, or applications for the loading of telephone cards.One operating system that is available for use with the present invention is that COMS ID No: SBMI-01807428 Received by IP Australia: Time 17:49 Date 2005-10-24 24/10 '05 MON 17:41 FAX 61 2 9888 7600 WATERMARK M015

O

O 5 commercially available through the applicant of the present invention, Fox STechnology Pty Ltd.

O When a product is sold by a retailer, product identification data is -communicated to the payment terminal 1. Product identification data in its N broadest form represents any electronic means by which a particular product can be identified by a manufacturer, supplier, retailer or other party. Product identification data is preferably in the form of a specific code consisting of letters and numbers unique to a particular product. Most preferably, the product identification data is represented by a barcode on a product.

In the most preferred form, the barcode is communicated to the payment 0 15 terminal 1 through the use of a barcode scanner 3. The barcode scanner 3 will capture the barcode data, which will then be decoded in the usual manner to reveal the electrical output corresponding to the barcode data. This electrical output, ultimately corresponding to the product identification data, is communicated to the payment terminal 1 for sending to the data collection server 6.

The electrical output may be processed at the payment terminal 1 so the product details are visible on the payment terminal 1, (ie the payment terminal will display "600ml Coca-Cola bottle"). Alternatively, the product details may remain in coded format until the details are processed at the data collection host 6. In this way, the processing of the product data may be done behind the scenes, without the retailer's specific knowledge.

The barcode scanner 3 may communicate directly and solely with the payment terminal 1. Alternatively, the barcode scanner 3 may communicate solely with an electronic cash register 4. In the latter case, the electrical output from the barcode may then be communicated to the payment terminal 1 through a connection with the electronic cash register 4. Preferably, the barcode scanner 3 will communicate with both the electronic cash register 4 and the payment terminal 1 simultaneously by splitting the input signal. Signal splitting may be achieved by using a cable such as that shown in figure 3. The scanned data is captured by the barcode scanner 3 and communicated to two outputs, both the electronic cash register 4 and the payment terminal 1.

COMS ID No: SBMI-01807428 Received by IP Australia: Time 17:49 Date 2005-10-24 24/10 '05 MON 17:41 FAX 61 2 9888 7600 WTRAKIji WATERMARK 1210j.6 01 For items purchased that do not contain barcodes, for example petrol, it is CA preferable that product information data can be communicated to the payment o terminal 1 through alternative means. This may be done by entering in a unique code for the specific item using the keypad on the payment terminal 1.

Alternatively, the product information data may be initially entered into the electronic cash register, and a specific code may then be automatically or semiautomatically communicated from the electronic cash register to the payment terminal1.

Each specific location, for example each convenience store, has its own In location identity data. This may be any form of data that allows each location to be uniquely identified. Preferably, this data will be in the formn of a string of ci numbers and/or letters.

The location identity data is stored in the payment terminal 1 for utilisation by the software. When product identification data is communicated to the payment terminal 1 ready to be communicated to the data collection server 6, the product identification data is first aggregated with the location identity data. This aggregated data is then processed by the payment terminal 1 to form a message ready to be communicated to the data collection server 6, It is preferred that the aggregated data is further aggregated with timing data prior to being communicated to the data collection server 6. The timing data represents the date and time when the product identification data was communicated to the payment terminal 1, thereby enabling the exact date and time of the product purchase to be determined and used in further information provided to a supplier (or similar), for example for marketing purposes.

When the data message has been aggregated and processed by the payment terminal 1, it is ready to be communicated to the data collection server 6. A communication device, most preferably a modem 2, is used to communicate the data from the payment terminal 1 to a data collection server 6. The preferred implementation uses a broadband connection to enable always-on operation of product capture, so as to provide real time product purchase data to be communicated to the data Gollection server 6. This prevents the need to store large amounts of data on the payment terminal I. This also allows the data collection server 6 to process the data dynamically and provide reports at any COMS ID No: SBMI-01 807428 Received by II' Australia: Time 17:49 Date 2005-10-24 24/10 '05 MON 17:42 FAX 81 2 9888 7800 WTRAKII1 WATERMARK 1210.17 moment in time. However, if desired, the present implementation could be N configured on a store and forward basis with periodic connection to the data o collection server 6. Adequate memory would need to be present in the payment terminal. A disadvantage of this app roach is the loss of near real-time data at the server 6.

Figure 4 is a screen shot of a sample report of the communicated data after it arrives at the data collection server 6. The information outlined in the rectangle 19 is the aggregated product identification data, location identity data and timing data. This information shows what product or products were the store or location the products were purchased from; and (3) the date and time the products, were purchased.

N Once the aggregated data has arrived at the data collection server 6, it is then processed into a readable form. The data collection host 6 will have stored a database of product identification data and location identity data to process the data received from the payment terminal 1 into a report suitable for use by a supplier. The report may then be sent to a supplier or the like Preferably, the reports will include details of products sold at certain locations during certain time periods. It may consist of a list of all products sold per location, or a specific product sold per location, or specific products sold during a certain period of time or on a certain day. The exact detail and format of the reports will be determined by the needs of the suppliers, The reports can be communicated to the suppliers (or similar) at any point in time, depending upon the specific needs of the supplier. For example, a report may be produced and communicated to the supplier each hour, or alternatively at the end of each day, week or month.

The supplier is able to then use the information provided in the reports for marketing purposes. For example, the supplier can determine those areas where a particular product is achieving the least sales, and commit specific marketing resources to that area to build up the product sales. This information is very difficult to readily achieve for small businesses under existing arrangements. The supplier may also use this information for automatic stock reordering for small businesses. Being able to automatically manage stock levels and ordering may COMS ID No: SBMI-01 807428 Received byiPl Australia: Time 17:49 Date 2005-10-24 24/10 '05 MON 17:42 FAX 61 2 9888 7600 WTRAKII1 WATERMARK 121018 In 12 reduce the need for human resources to perform such a task, and thereby increase efficiency and profits.

o A preferred feature of the method and system is to include a customer loyalty system operated through the payment terminal 1 and managed by the ci data collection host 6. The customer loyally system will allow a specific merchant to reward customers for continued purchases and will be conducted through the payment terminal 1.

In Merchants will be provided with customer reward cards from the data N collection host 6. The merchants will obtain customer information, such as the customers name and address, which will be provided to the data collection host 6 for entering into a database connected to the specific merchant. The customer information may be utilised by either or both the merchant and the suppliers for marketing purposes.

Each time a customer makes a purchase from the specific merchant's store, the customer hands their customer reward card to the merchant. The merchant can enter the details of the customer, preferably by swiping the customer reward card, into the payment terminal 1, This is entirely conventional, as for magnetic stripe credit cards and the like. The payment terminal I will have software enabled on the terminal to allow this function to be performed. The software enabled on the payment terminal I is preferably a Java application.

The specific amount of the purchase made by the customer may then be entered into the payment terminal 1, the amount of which will then be added onto the customer reward card. The purchase amount may be typed in manually to the payment terminal 1 using the keypad, or alternatively may automatically be transferred to the payment terminal 1 through an electronic cash register 4.

Alternatively, the purchase amount may be entered automatically when the barcodes on the products are scanned into the payment terminal 1 by the signal splitting method as described above.

The specific amount of the purchase is added onto the customer reward card. Each time the customer makes a purchase at the particular merchant, the purchase amount is added onto the customer reward card. When the customer reaches a certain amunt on their customer reward card, for example $100, the customer may be provided with a reward, for example a $10 voucher. The loyalty COMS ID No: SBMI-01807428 Received by IP Australia: Time 17:49 Date 2005-10-24 24/10 '05 MON 17:42 FAX 61 2 9888 7600 WATERMARK 12019 IC) 13 0 O 5 scheme preferably allows the merchant to adjust the value of the redemption as he or she sees fit. It is preferably the loyalty scheme is entirely configurable for O individual merchants. While the make up of the specific prize is not defined in the present invention, it is preferred the customer receives a voucher that may be i redeemed in that particular merchant's shop at a later time. The voucher may be printed off the payment terminal 1, with the data collection host 6 being responsible for the management of the system. It is preferred that each merchant Ic has a set purchase amount threshold, such that when a customer reaches the i specific threshold, the system will automatically generate a redemption voucher to 1 the value of the merchant-set reward amount. The data collection host 6 will O 15 automatically calculate and tally a customer's purchase amount, and a customer's reward amount. It is preferred the purchase and reward amounts may be extracted from the data collection host 6 for use by a merchant.

The data collection host 6 may provide the merchant, supplier, or any other person authorised to be given the customer's details, a print out of that customers purchasing activity. An example report that may be provided to one of these parties is shown in figure 5. These parties can then use this collection of information for marketing, sales or advertising purposes.

The core data for the loyalty scheme is stored on the data collection host 6. Basic data is stored on the payment terminal 1 and this stored data may then be settled up either daily or immediately, depending upon the opportunity for the terminal to communicate with the data collection host 6. The loyalty transactions are stored on the data collection host 6.

The embodiment discussed has focussed upon an implementation using magnetic strip cards for loyalty identification, barcodes for product identification, and broadband wired Internet connections. However, the present invention may be implemented with a wide range of technologies. For example, smartcards or other data tokens could be used as data carriers. The payment terminal may be adapted to accept smart cards, stored value cards or other loyalty reward cards in addition to magnetic stripe cards. Product identification could be by entry of a manual identifier, or detection of an RFID or similar device. Any suitable communication system, for example wireless broadband, GPRS or satellite could be substituted for cable or ADSL broadband.

COMS ID No: SBMI-01807428 Received by IP Australia: Time 17:49 Date 2005-10-24

Claims (12)

1. 2. A method according to claim 1, said method including the further step of o aggregating said product identification data and said location identity data with timing data.
2. 3. A method according to any one of claims the above claims, wherein product identification data includes a barcode on a product,
3. 4. A method according to claim 3, wherein the barcode is communicated to thie payment terminal by a barcode scanner. S. A system for acquiring and communicating product data, said system including: a payment terminal; means for receiving product identification data at the payment terminal; means for aggregating said product identification data with at least location identity data to form a message; means for communicating said message via a network to a server.
4. 6. A system according to claim 3, said system further including means for aggregating said product idenfification data and said location identity data with timing data.
5. 7. A payment terminal enabled to acquire product data, said payment terminal incoluding: COMS ID No: SBMI-01807428 Received by IP Australia: ime 17:49 Date 2005-10-24 24/10 '05 MON 17:43 FAX 61 2 9888 7600WARARIi02 WATERMARK 121021 o means for receiving product identification data; means for aggregating said product identification data with at least o location identity data to form message; means for communicating said message via a network to a remote Ni server.
6. 8. A payment terminal according to claim 7, said payment terminal further including means for aggregating said product identification data and said location identity data with timing data.
7. 9. A payment terminal according to claim 7 or 8, wherein said payment terminal further includes means for enabling a loyalty scheme. A payment terminal adapted to acquire product data and facilitate a loyalty scheme, said payment terminal including: Data means for receiving price information data; Data means for receiving identity data of a customer;, processing means for generating at least loyalty data messages including at least said identity data, said price information and location identity data; and communicating said data to a remote server; said processing means being responsive to messages from said remote server to provide a loyalty benefit to a customer.
8. 11. A payment termninal according to claim 10 wherein the price information data is collecled directly on the payment terminal.
9. 12. A payment terminal according to claim, 10 wherein the price information data is collected on the payment terminal through data inputted on a sales toerminal.
10. 13. A payment terminal according to any one of claims 10 to 12 further including means for enabling the selective redemption of loyalty points. COMS ID No: SBMI-01807428 Received bylP Australia: Time 17:49 Date 2005-10-24 24/10 '05 MON 17:43 FAX 61 2 9888 7600WAE AR i02 WATERMARK [a 022 o14. A payment terminal according to claim 13 wherein the redemption of loyalty points is at a customers choosing. A computer program for acquiring product data through a payment terminal, said program including: executing means for receiving product identification data at said payment terminal; executing means for aggregating said product identification data with at least location identity data to form a message; executing means for at least initiating communication of said message via a network to a server.
11. 16. A computer pmogram according to claim 7, said program further including executing means fur aggregating said product identification data and said location identity data with timing data.
12. 17. A method for acquiring marketing information, including the steps of; At a merchant premises, receiving product identification data at a payment terminal, aggregating said product identification data with at least location identity data to form a message, and communicating said message via network to a server; At said server, processing a plurality of said messages so as to provide marketing information. DATED this 24th day of October 2005 FOX TECHNOLOGY PTY LTD WATERMARK PATENT TRADE MARK ATTORNEYS 290 BURWOOD ROAD HAWTHORN VICTORIA 3122 AUSTRALIA NF4I\}\ P592&W COMS ID No: SBMI-01807428 Received by IP Australia: Time 17:49 Date 2005-10-24