NL9201152A - Auction information system - Google Patents

Abstract

Computerized auction information system provided with a central unit 1 and one or more user systems 3, which can be connected to the central unit 1, for example via the telephone network or via a direct link, and which in each case comprise at least reproduction means 9 and a keyboard 8, the auction system furthermore comprising auction clocks 2 which are connected to the central unit 1, the user systems 3 being arranged in such a way that a user, by using the keyboard 8 can retrieve information present in the central unit 1, which can be reproduced on the reproduction means 9. <IMAGE>

Description

Auction information system.

The invention relates to a computerized auction system comprising at least computer means and one or more user systems, which, for example via the telephone network, can be connected to the computer means and each comprise at least display means and a keyboard.

Such a computerized auction system is known from FR-A-2,585,166. The known system aims to enable bidders to advertise their bids remotely for products for sale. So the bidders no longer necessarily have to come to the auction to be able to bid. To this end, a large screen has been placed in the auction hall and bidders can access individual terminals by means of push buttons make their offer known, via telephone lines the centrally stored information about the products for sale can also be sent to distant places to be displayed there on auxiliary screens. It is not provided to remotely request current and / or historical information about random products. The information displayed remotely is communicated centrally by the sales manager. The system is also not linked to auction clocks present at the auction.

The aim of the auction system according to the invention is to provide a system which, at the request of users, provides current and historical information about products traded on the auction.

To this end, the system of the type referred to in the opening paragraph is characterized in that the auction system further comprises auction clocks connected to a central, which central comprises said computer means, the user systems being arranged in such a way that a user can operate the keyboard by operating the keyboard. the control center can request available information which can be displayed on the display means.

The system according to the invention makes it possible to provide users of remote information about the products sold at auction in a simple and relatively inexpensive manner.

In a first preferred embodiment of the invention, the computerized auction system is characterized in that the exchange is arranged to store current auction clock data for said clock in said computer means, such as data about the name of an article, the supply of that article, the remaining quantity, the clock price and its average price.

In a further embodiment of the invention, the computerized auction system is characterized in that the exchange is further arranged to store historical auction clock data, for example of the previous days or weeks, for each clock in the said computer means, such as data about the name of an article, the supply of that article, the remaining quantity, the clock price and the average price thereof.

In another embodiment of the invention, the computerized auction system is characterized in that the auction system further comprises an administrative computer, which is connected to the exchange, for making available information not linked to the clocks, such as auction entries and auction middle prices.

In a further embodiment of the invention, the computerized auction system is characterized in that the exchange is further arranged to communicate grower's statements, buyer notes or auction notices to the user systems.

In a further embodiment of the invention, the computerized auction system is characterized in that the exchange and the user systems are arranged in such a way that communication during use takes place between them via the following steps: a. A user selects using the keyboard a login choice from a main menu; b. the user system connects to the exchange, for example via the telephone network; c. the exchange asks the user to provide an access code; d. the user communicates an access code; e. the exchange checks the access code sent and requests the access code again in the event of an error; f. the user is given a predetermined number (eg 2) of opportunities to communicate a new, correct access code; if the newly communicated access code is still incorrect afterwards, the exchange will disconnect; otherwise: g. the exchange sends an acceptance message to the user and disconnects the call; h. the exchange itself establishes a connection with the relevant accepted user, for example via the telephone network; i. the user requests the desired information from the central unit via the keyboard, which information is displayed to the user by the user system via the display means.

In a final embodiment of the invention, the computerized auction system is characterized in that each user system is arranged to display at least the current auction clock data together with the historical auction clock data on the display means.

The invention will be elucidated hereinbelow with reference to some drawings, which are intended to illustrate the invention and are not to be taken in a limiting sense, and in which: figure 1 shows a general overview of the system according to the invention; Figure 2 shows a flow chart of the data processing of product supply messages; Figure 3 shows a flow chart of data processing data related to product sales; Figure 4 shows a flowchart of establishing a connection between a user and the message exchange center; Figure 5 shows an example of a main menu as presented to a user; Figures 6 and 7 show overviews of, for example, a TV screen, through which information about the auction is communicated to the user.

The auction information system according to the invention (in short KD2S, Clock-Data-Distribution-System) offers users two options: a) retrieving historical auction clock data with regard to supply data and sales data; b) being able to follow one or more auction clocks of the auction in real time.

The system is auction bound. This means that the system is connected to the auction clocks of that one auction. On this basis, only information from that auction will be available in the system.

Figure 1 shows the structure of the system. The system mainly consists of two (main) parts. The first part 1, which will be further referred to as the KD2S exchange (or the exchange for short), consists of a computer system that is connected to all auction clocks 2 of the auction.

The other part is the user system 3. The user system 3 can be connected to the exchange 1 and then request data and / or follow the auction clocks 2. Communication with the exchange 1 is via public telephone lines 6 (although the system also works with fixed 2 or 4-wire line connections). For establishing the connection, each user system comprises a telephone 4 and a terminal 5, the latter of which is at least provided with a keyboard 8 and display means 9.

In a first embodiment of the system according to the invention, only auction clock data are made available. This data includes both real-time data and historical data, for example, arranged by day and item number, regarding deliveries and sales data.

In a second embodiment of the invention, the exchange 1 is also connected to the administrative computer 7. This connection offers the possibility of communicating administrative data to users, such as (auction) middle prices and (auction) supplies. It is also easy to make grower's statements, buyer notes and other auction notices available.

In the following, the arrangement of the exchange 1 and the user system 3 is discussed separately.

Concerning the central 1, the following six topics will be discussed successively: master files, communication with the clocks 2, database / mutation files, data processing, communication with one or more user systems 3 and maintenance of the master files.

Central 1 comprises at least two master files: the (national) article file and the participant file. The article file contains an overview of articles ordered by products, whereby articles are defined as sorts of a product. A product is, for example, a green pepper, which has different grades (depending on origin and quality, for example). Each sort is an "item" and has its own unique item number. Thus, a product may include several articles, so that each product number unique to each product may include more than one article number. The article file is a directly accessible file with the following data elements: - article code (value 1 to 65000); - product code (value 1 to 999); - short article description (8 characters); - long article description (24 characters); - product name (16 characters).

An index file is maintained based on the product code.

The participant database contains an overview of all participants connected to the auction information system, who each have their own unique access code and their own telephone number. The participant file is an indexed file with the following data elements: - grower number (value 1 to 10000) - access code (5 alphanumeric characters); - telephone number (area code, subscriber number); - array of up to five product code numbers (value 1 to 999).

The grower number acts as a key (index file).

The second topic, to be discussed with regard to central 1, concerns communication with clocks 2. Communication with auction clocks 2 consists of five messages: • price message; • delivery message; • purchase notice; • correction message; • push-through message.

A possible layout of these messages is given below. In one embodiment, messages are transmitted from clocks 2 based on asynchronous "terminal" communication. This means that, without any control of transmission errors, messages are sent at a rate of 1200 BPS (Bits Per Second), 8 data bits, 1 stop bit, none parity. The messages consist exclusively of so-called printable ascii characters. Other forms of communication are of course also possible and the invention is not limited to the exemplary embodiment given above.

Characteristic of the messages is that each message starts with a "<" sign and ends with a ">" sign. The layout of the messages is geared to the messages that most clocks 2 already generate in the context of the national purchasing information system (I2S). Therefore, messages at a single point can house an irrelevant "field"; in such a case it will be indicated as "filler".

Below is the layout of the five messages mentioned: a. The price message is as follows: "<" (start of text); vnr (auction number; 2 characters); "P" (message identification); filler (1 character); artnr (article number; 6 characters); pr (price in cents; 4 characters); ">" (end of text).

The total message length is therefore 16 characters.

It is noted that the price message has no relationship whatsoever with a stock. This message is forwarded directly to the user system 3 without any changes.

b. The delivery message looks like this: (start of text); vnr (auction number; 2 characters); "A" (message identification); filler (1 character); artnrl (article number; 6 characters); complement (input; 6 characters); artnr2 (article number; 6 characters); supply2 (supply; 6 characters); artnr3 (article number; 6 characters); supply3 (supply; 6 characters); artnr4 (article number; 6 characters); supply4 (supply; 6 characters); artnr5 (article number; 6 characters); supply5 (supply; 6 characters); artnr6 (article number; 6 characters); supply6 (supply; 6 characters); ">" (end of text).

The total message length is therefore 78 characters.

c. The purchase message looks like this: "<" (start of text "); vnr (auction number; 2 characters);" K "(message identification); filler (1 character); artnr (article number; 6 characters); purchased (quantity bought; 5 characters); rest (rest of the lot; 6 characters); pr (price in cents; 4 characters); debinr (buyer's debtor number; 4 characters); (end of text).

The total message length is 31 characters.

d. The correction message looks like this: (start of text); vnr (auction number; 2 characters); "C" (message identification); filler (1 character); artnr (article number; 6 characters); bought (number bought; 5 characters); rest (rest of the batch; 6 characters); pr (price in cents; 4 characters); debinr (buyer's debtor number; 4 characters); ">" (end of text).

The total message length is 31 characters, e. The drill-through message looks like this: "<" (start of text); vnr (auction number; 2 characters); "D" (message identification); filler (1 character); artnr (article number; 6 characters); bought (number bought; 5 characters); rest (rest of the batch; 6 characters); pr (price in cents; 4 characters); debinr (rotary number; 4 characters); ">" (end of text).

The total message length is 31 characters.

The third subject within central 1 concerns the transaction files, which consist of two files, namely the supply data file and the sales data file. The two transaction files are filled on the basis of the messages received from the clocks. It is these files that contain the "historical" data for the users and can be retrieved as such. The files are filled by date. The layouts of the supply file and the sales file differ from each other.

The record layout of the supply file is as follows: - product code (value 1 to 999); - article number (value 1 to 65000); - flow (value 0 to 999999).

Two index files are kept for the supply file; one based on the product code and one based on the article number.

The record layout of the sales file, on the other hand, is: - product code (value 1 to 999); - article number (value 1 to 65000); - sold (value 0 to 999999); - product (value 1,000,000 * 1000); - average price (value 0 to 9999.9999); - rotate (value 0 to 999999).

Two index files are also kept for the sales file; one based on the product code and one based on the article number.

The next (fourth) topic to be discussed with regard to exchange 1 concerns data processing.

This section concerns the data processing of the messages received from the clocks 2 and which leads to the mutation files being filled.

There is a direct relationship between the messages and the mutation files. For example, delivery messages are only important for the delivery file; purchase report, correction report and transfer notice are important for the sales file.

Figure 2 shows a flow chart of the data processing of delivery messages.

If a clock supply message arrives (step 10), the product code is added to it in step 11 (can be found in the article file). Then, in step 12, it is checked whether a file of this auction day already exists. If not, a file is created in step 13, including the date in the name. The file name is Addmmjj.dta. Ddmmyy form the date (for example, August 12, 1992 is represented as 120892). Simultaneously with the creation of the file, the two index files are also created in step 14, namely one based on the product code and one index file based on the article number. A record is added to the file in step 15, of course containing the article number and the supply (see record layout of the supply file defined above); the index files are then updated in step 16. If it is determined in step 12 that a file with the correct date already exists, a record is added to that file (step 15) and, of course, the index file is also updated (step 16).

Since in the exemplary embodiment sketched here, the supply of (a maximum of) six article numbers can be included in a single supply message, it is therefore possible to add several (maximum six) records to the file per supply message. It is of course possible to change this maximum number of six article numbers into another maximum number without departing from the scope of the invention.

Figure 3 shows a flow chart illustrating the data processing of the sales data.

If a clock purchase, correction or roll-over message arrives (step 20), the product code is also added to this in step 21, which is retrieved from the article file. It is then checked whether a file already exists for this day (step 22). If not, a file is created in step 23 with the date included in the name. The file name is Vddmmjj.dta. Ddmmyy form the date (for example, August 12, 1992 is represented as 120892). Simultaneously with the creation of the file, in step 24 one index file is created based on the product code and one index file based on the article number.

A record is added to the file in step 25. When a purchase message arrives for the same file with the same article number, the product of the message fields "bought" x "price" is added to the value of the "product" field of the file. This sum is then written into the file, namely in the field "product" (step 26). In the "sold" field of the file, the sum of the value in that field, together with the value of "bought", is always written out of the message (step 27).

It will be clear that the "sold" and "product" fields allow the average price (until then) to be determined and stored (step 28). As soon as the K-message shows that the lot has been sold - the value of the "remainder" field is then zero -, the "average price" field can of course also be filled in. This field is also filled in when a forwarding message is received, because then the lot can also be considered sold out, in that situation the auction itself acts as buyer. By using a separate message, a distinction can then be made between the purchases (and mid-prices, etc.) of the "real" buyers and that which is unsaleable: after all, something that goes crazy is unsaleable, because there is no buyer who clock has stopped. Data from a push-through message do not affect the calculated mid-prices, nor the "sold" field.

Finally, the index files are updated in step 29.

Any correction message is treated as a counter-claim. For example, a correction message occurs if the auctioneer used the wrong debtor number when registering a purchase or if he entered an incorrect "purchased quantity". If an incorrect debtor number is used, the buyer, who can observe this directly in the auction room, will complain and ask the auctioneer to correct the mistake. The following happens in the clock: a. A message is initially sent with the wrong debtor number (purchase message); b. the same message is sent again, but with a different identification (correction message); c. again a purchase message is sent, but now with the correct debtor number.

By processing the correction message as a reversal, the initial purchase message is, as it were, canceled. The "bought" field from the message is counted down from the "sold" field from the file. Also, the product of "purchased" x "price" is counted down from the "product" field in the file. The second purchase report from step c. is ultimately important as "result data", because steps a. and b. cancel each other out.

An analogous correction takes place if the auctioneer has entered an incorrect "purchased quantity". With this "trick" it is easily possible to make several corrections to a once sent purchase message.

The communication of the exchange 1 with one or more users - the fifth subject - takes place via the flow chart illustrated in figure 4.

There are four facets of communication with the user: a) user registration; b) forwarding the clock messages; c) provision of historical data on request; d) communication protocol aspects.

During registration, a user searches for connection to the exchange 1 by taking a certain choice from a so-called menu from the user system 3 (step 30). We will return to this when discussing the user system. The user computer calls the exchange in step 31. Once both computers are connected (step 32), the user system is prompted for an access code (step 33). This is done with the following message: "<" start of text; filler two characters; "X" message identification; end of text.

The user will enter the access code (step 34) on the basis of which the user system will send the access code to the control panel. The sending of the access code by the user system is done by the following message (message 1): "<" start of text; filler two characters "1" message identification; filler a sign; access code 5 characters (alpha-numeric); ">" end of text.

The control panel will look up the access code in the "participant database" in step 35. If the code is not found, an error message is sent to the user system (step 38). This happens in the following message: "<" start of text; filler two characters; "Y" message identification; ">" end of text.

The user is now given the opportunity to enter his access code again. However, if an incorrect access code is received three times, which the exchange checks in a test step 36, the exchange disconnects in step 37.

If a correct access code is received, the exchange 1 in step 39 sends an acceptance message (message "2", which will be defined below) to the user system. Subsequently, the exchange 1 disconnects in step 40. As a next step, the exchange 1 calls the telephone number indicated with the relevant access code (step 41). At the time of connection, message exchange can take place (step 43). Incidentally, from this moment on, the exchange keeps track of the connection time. On this basis, the auction could send the user an invoice regarding the telephone costs. At this point, the exchange "knows" with whom it is communicating. The user file contains the products that this user will be interested in. For example, as specified in the user file, each user can enter up to five products. Those users interested in more than five products have the opportunity to take out a second "subscription". This subscription has a different access code (but can of course have the same phone number).

As indicated above, in step 41, after an approved access code, the exchange calls the user system 3. As soon as a connection is established, the exchange 1 sends a message to the user system 3 containing the product numbers relevant for this user. This so-called acceptance message looks like this (message 2): "<" start of text; filler two characters; "2" message identification; filler a sign; prodcodel product code (value 1 to 999); prodcode2 product code (value 1 to 999); prodcode3 product code (value 1 to 999); prodcode4 product code (value 1 to 999); prodcode5 product code (value 1 to 999); ">" end of text.

The second facet of communication with the user is the forwarding of clock messages. Central 1 is connected to clocks 2 of the auction by separate RS232 lines. The original messages from the clocks 2 do not contain any information regarding the clock 2 from which the messages originate. However, the exchange 1 "knows" on the basis of the RS232 connection (cg.the communication channel number of the computer) from which clock 2 the message originates. This clock number is relevant for user system 3. Based on this number, the location for displaying data on the user screen of terminal 5 is determined (see figure 1). Of course, other than RS232 lines can also be used without departing from the scope of the invention.

By means of a choice, the user can ask the central 1 to forward the clock messages to the user system 3. This is done by sending the following message from the user system 3 (message 3): "<" start of text; filler two characters; "3" message identification; end of text.

The messages received from the clocks 2 are directly forwarded to the users who have connected to the exchange 1. The messages are extended with the "clock number". This clock number is - as an ascii sign - placed immediately after the identification field (ie instead of the first "filler field"), ie immediately after a "P" (price message), "A" (supply message), "K "(purchase message)," C "(correction message) or" D "(roll message).

The user system 3 can also send a message to the exchange 1 stating that the sending of the clock messages is no longer necessary. This is done with the following five-character message (message 4): "<" start of text; filler two characters; "4" message identification; ">" end of text.

Communication with the user also includes making historical data available (facet 3).

If the user wants to know which data of products relevant to him is stored in the central unit 1, he can enter this via a menu selection on the user system 3. He will also have to indicate the date on which he wants information. On the basis of the data provided by the user, the user system 3 compiles a so-called query message. This message looks like this (message 5): "<" start of text; filler two characters; "5" message identification; filler a sign; prodcode product code (value 1 to 999); date date in form ddmmyy; ">" end of text.

The total message length is therefore 15 characters.

The exchange 1 will collect the relevant data on the basis of this message and send it to the user system 3 in one or more so-called response messages. The response message has the following layout (119 characters) (message 6): "<" start of text; filler two characters; "6" message identification; filler a sign; prodcode product code (value 1 to 999); artnrl article number (value 1 to 65000); additional flow (value 0 to 999,999); sold sold (value 1 to 999,999); mid price mid price (9999.9999) (8 characters); pass through (value 0 to 999,999); artnr2 article number (value 1 to 65000); supply2 supply (value 0 to 999,999); sold2 (value 1 to 999,999); mid price2 mid price (9999.9999) (8 characters); drive through (value 0 to 999,999); artnr3 article number (value 1 to 65000); supply3 supply (value 0 to 999,999); sold3 (value 1 to 999,999); mid price3 mid price (9999.9999) (8 characters); pass through 3 (value 0 to 999,999); artnr4 article number (value 1 to 65000); supply4 supply (value 0 to 999,999); sold4 (value 1 to 999,999); mid price4 mid price (9999.9999) (8 characters); pass through (value 0 to 999,999); last_ber last message (value O = no; value 1 = yes); ">" end of text.

The exchange 1 will, incidentally, send so many response messages until all data of all requested product numbers and associated article numbers have been sent. Only in the last message the value of the field "lastjber" will be "1", in all other messages that value will be "0".

Finally, as the fourth facet of communication with the user, the communication protocol is discussed.

The communication between central 1 and user system 3 is preferably based on a half duplex protocol. The exchange is preferably asynchronous 9600 BPS, 8 data bits, 1 stop bit none parity. Naturally, other communication protocols can be used without departing from the scope of the invention.

Because of the "real time" character, the so-called clock messages are not checked by the receiver for transmission errors (ie no acknowledgments, ack's, and non-acknowledgments, nak's). The sending side therefore does not wait for ack or nak. This means that no retransmission will be applied to the clock messages. Incidentally, the exchange 1 sends the clock messages with the highest priority to the user system 3.

In order to check whether the transfer of the data has been successful, two messages (totaling 3 characters) are added to each message - after the end-of-text character. The first data consists of two ascii signs. These are based on the following, relatively simple, so-called BCC calculation;

The sending computer sums the binary values of all characters that are between start-of-text and end-of-text. Overflow is not taken into account in the addition. The result is a binary value that includes a byte. Now the four most significant bits of the sum are transferred into a byte. This byte will now have a value between 00h (ex) and OFh. Adding 3Oh to this byte creates an ascii sign; this character is placed immediately after the end-of-text character. The same operation is also performed on the least significant bits to create a second ascii character, following the previous character in the message. Finally, an ascii character with the value "0" to "9" is added to the message. This sign can be considered as a message number. The first message is numbered "1", the second "2", etc. After "9", "0" follows; after "0" follows "1", etc. The receiving side can therefore see on the basis of the message number whether a message has been lost.

The sending side therefore sends messages containing a BCC and a serial number. As soon as the sending side has sent a message, it is waiting for a reply from the receiving side. The receiving side will calculate the BCC in the same way as the sending side and check whether it has the same result as the sending side. Likewise, the receiving side will check whether the received message has a sequence number one higher than the previous received message.

On the receiving end, four situations can arise from a message sent by the sender: a) both BCC and sequence number are correct; b) the BCC indicates that there is message corruption; c) on the basis of the serial number received, it must be established that a message has been lost (due to the semi-duplex character and the consistent sending and waiting for a reply, it is not possible for more than one message to be lost); d) the receiving side receives absolutely nothing.

The above situations are now being worked out.

ad a) In case of correct data transfer, the receiving party sends an ack message. This looks like this: "<" start of text; filler 2 characters; "!" chord; no 1 sign; serial number of received message; ">" end of text.

When the sending side receives this message, he knows that everything went well. He should now be able to send subsequent messages, if that is the case.

However, the sender may not receive the ack message or may be maimed. This also applies in all following cases. This situation will be discussed below - under point d) - point b) If the calculated BCC shows that message mutilation has occurred, the recipient sends the following so-called after message: "<" start of text; filler 2 characters; "?" not agreed; no 1 sign; serial number of received message; ">" end of text.

This message may also be lost. This is addressed under point d), point c) If the recipient determines that a message must have been lost, he / she also sends an after message as indicated under point b). The field "no" will then be "?" ad d) Both in the event that a message is not received at all, or in the event that ack or nak messages disappear entirely, there is a situation where the sender and receiver would wait for each other. In order to prevent this, the following is provided: the sending side waits for a certain time after the message has been sent for a reply from the receiving party. If no answer is received within that time, the sender sends the message again. This procedure is repeated a maximum of four times, for example. If no reply is received after four times, the transmitter will disconnect the connection.

It was realized that both central 1 and user system 3 can act as sending party. This depends on the status of the data exchange. For example, the user system is 3 transmitter if a supply or purchase request is sent. The exchange 1 is the transmitter if it sends, for example, the requested data.

Since there can be no misunderstanding with regard to the division of roles in the various phases, the data exchange through the protocol written above will also function perfectly.

The sixth and last topic to be discussed with regard to the central 1 concerns the maintenance of the master files. This concerns the two master files, being the article file and the participant file. Of course, facilities are provided for the maintenance of the files. For the maintenance of the article file it is important that this file is a directly accessible file. This means that this file has a fixed amount of records, namely 65000. The article number in the first record is 1, the article number in the second record is 2, etc. Using the article number, you can immediately retrieve the correct record. From the maintenance side it is necessary that the descriptions can be changed in records. In exceptional situations it may even be necessary to change a product number. The article file includes an index file based on the product code. Changes to the article file always result in this index file being updated automatically.

For maintenance of the participant file it is in principle necessary that all fields of a record from the participant file must be editable. Records must also be able to be added or deleted. Both the participant number and the access code must be unique. This is checked for mutations (no duplicate keys). Although not always necessary, making changes to the participant file always results in the index file being updated.

Subsequently, we proceed to the description of the user system 3. For this, the options from the so-called main menu of the KD2S are shown, which is shown in figure 5. This menu appears on the screen of the user system when the operating system is typed: KD2S.

If the user takes choice 1 ("log in to KD2S panel") from the main menu, the system will call the phone number of the KD2S panel. The number of the exchange is stored in the file "telephone.dta". Each auction will of course make its own number available for KD2S exchange 1. In order to prevent the user from changing the telephone number in the file, this file will not be mutable by the user.

As soon as a connection is established, the exchange 1 sends the message with identification "X". This asks for the access code. The user's screen will now ask "Enter your access code". When the access code is entered, the user system sends message "1", which is defined above in communication between control panel 1 and a user.

If the control panel accepts the access code, it will return "2". This lists the (maximum) five product numbers that are important to this user. Incidentally, in case the access code is not accepted, the control panel will return the message with identification "Y".

When the access code is accepted, the information screen appears on the user system as shown in figure 6.

the user has the possibility to make a number of choices by means of six "buttons" 50-55 (bottom left in figure 6).

The user can select a date using the selection button "next auction day" 51 and "previous auction day" 50. The date is displayed in the field 57 above it. If a date is selected, the data can be requested from central 1 using the selection keys "next product" 53 or "previous product" 52.

On the first "operation" of the button "next product" 53, the system will send the message with number "5" (inquiry message) to the central 1 containing the first product number. The control center will send one or more so-called response messages (message "6") containing all data of the product concerned. The user system stores all messages - as a record - in a file. This file is given a unique name. This name shows the product code and the date to which the messages relate. The name of the file looks like this: Gddmmjj.ppp. Here dd = day of the month, mm means month number and yy year. The "extension" ppp is the product number. The product name is shown in field 56.

Once the last entry of this product has been received, the data is sent to the screen and entered in the relevant columns. To this end, the screen comprises 7 columns 58-64. Column 58 contains the article name, column 59 the article number, column 60 the price, column 61 the supply, column 62 the quantity of sold articles, column 63 the average price and column 64 the number of items turned over. If there is more data than is available in the available space on the screen, the user can, as it were, browse the file.

If the user now again selects "next product" via button 53, the system 3 will ask central 1 for the data of the next product. That data is also stored in its own file of the user system 3. The operation is further as described above.

If the user selects "previous product" (key 52), the system 3 will first check whether data has already been received from the exchange 1 with regard to the previous product number. If so, the data from that file will be shown; if that file is not yet available, the user system will submit a request to the central about this product using message "5". In that message, of course, the relevant product number is included.

Key 55 is intended to request information from auction clocks 2. When key 55 is pressed for the first time, the user system 3 asks the central 1 to continuously send all clock data by means of message "3". This continues until the user presses the "clock on / off" key 55 again. In the latter case, the user system 3 sends the message with identification "4".

The clock messages are displayed in the top half 65 of the screen, which is further elaborated in Figure 7. On the screen shown in Figure 7, three rows are reserved for three clocks 2, respectively. This number may of course also be different. For example, each of the three rows contains six fields. The first field 66, 72, 78 indicates the clock number, the second field 67, 73, 79 the article name, the third field 68, 74, 80 the supply, the fourth field 69, 75, 81 the remaining quantity, the fifth field 70, 76, 82 the clock price and the sixth field 71, 77, 83 the average price. Of course, more or fewer fields per row can also be provided without departing from the scope of the invention. The clock messages are processed immediately upon receipt for display on the screen; these messages are not saved.

When key 54 ("to menu") is pressed, the first message "4" is sent to control panel 1 if the user has indicated at least that he wishes to receive the clock messages. Based on message "4", control panel 1 will stop sending the clock messages. The main menu (figure 5) is then shown on the screen again. It should be noted that choosing the first choice from this menu (sign up ...) will have no effect. Also menu options 3 and 4 cannot be activated (this is only possible after the connection to the exchange has been lost).

However, if the user chooses choice 7 in the main menu of figure 5 (back to information screen), the information screen (figures 6/7) is again displayed. If the user wants to follow the clock event again, he has to activate "clock on / off" again.

By selecting 2 in the main menu (figure 5), a user can log out from central 1. The selection is only active if the user is logged in to the exchange 1. In that case, the user system 3 will send the following message to the exchange 1, which informs them that no further communication is required via this connection ( message 7): "<" start of text; filler two characters; "7" message identification; ">" end of text.

This message contains 5 characters.

Both control panel 1 and user system 3 will both instruct their modem (not shown) to terminate the connection.

As described above, the user system 3 stores the requested data on disk, namely in files in which the date and product number are recorded. These files can be consulted if the user is not connected to the control panel 1. By selecting 3 from the main menu, the data stored on disk can be shown on the screen. After the user has made choice 3, the system will ask for a date and a product code. The file can then be found. If no data has been stored in this regard, the user will be notified.

The requested data can be printed via option 4 from the main menu (if data is available). The system will also test for the availability of a printer. If the printer is not available, a message is displayed on the screen.

Choosing option 8 from the main menu ("back to operating system") will close any open files. If the user system 3 is still connected to the exchange 1, message 7 is first sent to the exchange and then the modem is ordered to terminate the connection. Then the program KD2S is exited, which automatically returns to the operating system.

Claims (7)

Computerized auction system comprising at least computer resources and one or more user systems, which can be connected, for example via the telephone network, to the computer resources and each comprising at least display means and a keyboard, characterized in that the auction system furthermore includes auction clocks (2 ) which are connected to an exchange (1), which exchange (1) comprises said computer means, the user systems (3) being arranged such that a user is present in the exchange (1) by operating the keyboard (8) can request information which can be displayed on the display means (9). Computerized auction system according to claim 1, characterized in that the exchange (1) is arranged to store current auction clock data for said clock means in said computer means, such as data on the name of an item, the supply of that item, its remaining quantity, the clock price and its average price. Computerized auction system according to claim 1 or 2, characterized in that the exchange (1) is further arranged to store historical auction clock data, for example of the previous days or weeks, for said clock (2) in said computer means, such as information about the name of an item, the supply of that item, its remaining quantity, the clock price and its average price. Computerized auction system according to any one of the preceding claims, characterized in that the auction system further comprises an administrative computer (7), which is connected to the exchange (1), for making available unlinked to the clocks (2) information, such as auction entries and mid-auction prices. Computerized auction system according to one of the preceding claims, characterized in that the exchange (1) is further arranged to communicate grower's statements, buyer notes or auction notices to the user systems (3). Computerized auction system according to any one of the preceding claims, characterized in that the exchange (1) and the user systems (3) are arranged in such a way that the communication during use takes place between them via the following steps: a. A user selects using the keyboard (8) a login selection from a main menu; b. the user system (3) connects to the exchange (1), for example via the telephone network; c. the exchange (1) asks the user to provide an access code; d. the user communicates an access code; e. the exchange (1) checks the transmitted access code and requests the access code again in the event of an error; f. the user is given a predetermined number (eg 2) of opportunities to communicate a new, correct access code; if the newly communicated access code is still incorrect afterwards, the exchange (1) disconnects; otherwise: g. the exchange (1) sends an acceptance message to the user and disconnects the connection; h. the exchange (1) establishes a connection with the relevant accepted user, for example via the telephone network; i. via the keyboard (8) the user requests the desired information from the exchange (1), which information is displayed to the user by the user system via the display means (9). Computerized auction system according to any one of the preceding claims, characterized in that each user system (3) is arranged to display on the display means (9) at least the current auction clock data together with the historical auction clock data.