WO2002091307A2

WO2002091307A2 - Ticketing system

Info

Publication number: WO2002091307A2
Application number: PCT/US2002/014748
Authority: WO
Inventors: David Wainwright; Leonard Levy; Robert David Mcintosh
Original assignee: Entertainment International Ltd.
Priority date: 2001-05-09
Filing date: 2002-05-09
Publication date: 2002-11-14
Also published as: GB0111286D0; WO2002091307A3; GB0317362D0; WO2002091307A9; GB2391101B; EP1388076A2; GB2391101A; JP2004530981A

Abstract

A method for issuing a ticket to a user of a communication interface for communicating with a data server over a publicly accessible communication network (4) and formatting data received from the server (7) and of a printer (10) capable of printing information formatted by the communication interface, the method comprising: generating a code number for the ticket; formatting an image file of an image file format, the image file representing an image in that format of a bar code corresponding to the code number; and providing to the communication interface over the publicly accessible communication network (4) by means of a data server ticket data defining the appearance of a ticket, the ticket data including the image file.

Description

TICKETING SYSTEM

This invention relates to a ticketing system.

One method of issuing tickets for entertainment or sports events etc. is to have buyers contact a central sales point which also generates the tickets. The tickets are then sent by post to the buyers. This system has the disadvantages that a buyer experiences a delay in obtaining the ticket, and that the ticket issuer must set up a facility for generating the tickets. However, issuing tickets centrally has the advantage that the tickets can incorporate machine readable features such as magnetically encoded strips that can store details of the ticket. When a suitable reader is available at the event these features make it much quicker and easier to validate the ticket. This is especially important at large events, when there is a particular need to process tickets swiftly.

It is becoming increasingly common for tickets to be bought using the internet. Typically a ticket issuer will operate web site which provides the facility for a buyer to enter the details of the ticket he requires. Once the details of the ticket have been entered the web site server verifies the details to check that a corresponding ticket can be issued and then transmits a confirmation number to the buyer as part of a web page. The buyer can print out the web page for reference. ^"When the buyer arrives at the venue he can identify himself to the organiser by means of the confiπnation number and receive a conventional ticket for admission, or be admitted simply on the basis of the confirmation number. This system overcomes the problem of delay in the issuance of the tickets, and can optionally circumvent the need for the ticket issuer to set up a facility to physically generating the tickets. However, the procedure for validating the tickets is laborious. Even if the buyer does print out the confiπnation number, the number is not reliably readable by machine so staff must be provided at the venue to read the confirmation numbers, enter them into a ticketing system for verification and then issue conventional tickets if necessary.

Tickets issued in these ways can be for entertainment or sports events, travel and restaurants. WO 00/74300 describes an internet ticketing system in which the user is presented with a ticket including a bar code, which he can then print off and present at a venue. The bar code is generated as the result of a hash function intended to permit the ticket to be authenticated. WO 00/74300 teaches that the user's browser encodes the bar code.

In principle, tickets bearing bar codes offer the advantage that they can be printed by the buyer of a ticket and machine read reliably at a venue. However, the inventors of the present invention have found that in practice, the accuracy with which the printed bar code can be read can be highly dependant on the set-up of the buyer's computer and printer system. For example, one way to generate bar codes, which is particularly convenient if the code is to be generated at the user's browser as taught in WO 00/74300, is to use a bar code font. Bar code fonts arc available from www.bizfonts.com and other suppliers. The inventors of the present invention have found that bar codes generated in a user's browser this way can often not be read rehab ly. In particular, the operating system used by the user's computer has a significant effect on the form in which the bar cede is printed.

There is therefore a need for a system that allows tickets to be generated conveniently by a user, in a form that can be reliably machine read-

According to one aspect of the present invention there is provided a method for issuing a ticket to a user of a communication interface for communicating with a data server over a publicly accessible communication network and formatting data received from the server, and of a printer capable of printing information formatted by the communication interface, the method comprising: generating a code number for the ticket; forming an image file of an image file format, the image file representing an image in that format of a bar code corresponding to the code number; and providing to the communication interface over the publicly accessible communication network by means of a data server ticket data defining the appearance of a ticket, the ticket data including the image file.

According to a second aspect of the present invention there is provided a ticket issuing system for issuing a ticket to a user of a communication interface for communicating with a data server over a publicly accessible communication network and formatting data received from the server, and of a printer capable of printing information formatted by the communication interface, the system comprising: a code generator for generating a code number for the ticket; an image formatter for forming an image file of an image file format, the image file representing an image in that format of a bar code corresponding to the code number; and a data server for providing to the communication interface over the publicly accessible conmuni cation network ticket data defining the appearance of a ticket, the ticket data including the image file.

According to a third aspect of the invention there is provided a method for issuing a ticket to a user of a communication interface for communicating with a data server over a communication network and of an output device capable of forming a portable information record, the method comprising: receiving an indication of a plurality of actions for which a voucher is required; generating a code for the voucher; storing in a remotely accessible data store the code in association with an indication of the said plurality of actions for which the voucher is to be valid; providing the code to the communication interface over the commiinication network by means of the data server; and outputting by means of the output device a portable information record carrying a record of the code.

Each action may be an even or may take another form, for instance a purchase of goods.

Preferably the method comprises the step of formatting the ticket data by means of the communication interface and printing the formatted ticket data including the image file by means of the printer. The ticket data may suitably be formatted according to a mark-up language such as HTML or XML

Preferably the method comprises the step of providing to the communication interface by means of the data server data instructing the user to print the formatted ticket data. That instructing data is preferably provided in a form suitably for display by the communication interface on a visual display unit. The method preferably comprises the step of storing in a remotely accessible data store the code number in association with an indication of an event for which the ticket is valid. The data store is suitably local to the data server.

The method preferably comprises the step of storing in the remotely accessible data store the code number in association with an indication of a plurality of events for which the ticket is valid. The method preferably comprises the step of storing in the remotely accessible data store the code number in association with at least one item of verification information. The verification information could be a personal identification number, payment information or other data.

The method suitably comprises the steps of: reading the bar code by means of a machine bar code reader associated with an event; comparing the read code with the data stored in the remotely accessible store to determine whether the read code is stored in association with an indication of the event with which the bar code reader is associated; and if the read code is stored in association with an indication of the event with which the bar code reader is associated permitting access to the event and otherwise denying access to the event. The method may include the step of the user providing the verification information to an entry device such as a keypad associated with the bar code reader, comparing the read code and the entered verification information with the data stored in the remotely accessible store to determine whether the read code and the entered verification information arc stored in association with an indication of the event with which the bar code reader is associated; and if they are permitting access to the event and otherwise denying access to the event.

Suitably the said comparison step is performed by a processor local to the remotely accessible data store and the method includes the steps of: transmitting an indication of the read code from the bar code reader to the processor; and transmitting an indication of the result of the comparison to an access control unit local to the bar code reader. Alternatively, the comparison step may be performed locally to the bar code reader. The contents of the store need not be directly accessible, although that is one possible implementation. The output device may be a printer or another form of device such as a magnetic stripe writer or a smart card writer.

The portable information record suitably acts as the voucher. The voucher may be a ticket

The code is preferably represented on the portable information record as a bar code.

The portable information record may conveniently be termed a ticket.

The method suitably comprises the steps at an event of: reading the code carried by the portable information record; comparing the read code with the data stored in the remotely accessible store to determine whether the read code is stored in association with an indication of the event; and if the read code is stored in association with an indication of the event with which the bar code reader is associated permitting access to the event and otherwise denying access to the event.

The code may be read at an access point to the event by a code reader associated with the event. If the event is a concert then the reader may be at an entrance gate to the concert venue. If the event is a travel event, such as a train journey then the reader may be at an access point to the station from which the journey begins or at a reader on a train.

Preferably, on being read, the read code is automatically transmitted to the remotely accessible store.

The or each event may take one of a number of forms. Forms of event include entertainment events such as concerts, plays and exhibitions; sporting events; and travel events such as train or plane journeys. The or each event is preferably characterised by an event character and an event time. An event character suitably indicates the nature of the service provided for the event, for example: "Wimbledon, Court 1" or "London Heathrow Airport to Munich Airport". An event time suitably indicates the time and/or date of the instance of the event, for example: "25 June 2001" or "3:34pm, 26 June 2001". An event may be specific to an individual person. Therefore a plurahty of events may comprise more than one instance of an event of a single character. In this way, bookings for more than one person at a single specific event can be made using a single ticket.

The method may comprise copying data stored in the remotely accessible data store to a second data store local to the bar code reader. Authentication of tickets may then be performed in an analogous manner to that described above, but with use of the second data store instead of the remotely accessible data store.

The communication interface may be a web browser. The data server may be a web server. The publicly accessible communication network maybe the internet.

The method may comprise the steps of: storing data defining a plurality of available events; receiving at the data server from the communication interface an indication of at least one event for which a ticket is required; and receiving at the data server a financial authorisation number.

The formatted ticket data may include a humanly readable indication of the said at least one event.

The present invention will now be described by way of example with reference to the accompanying drawing, in which figure 1 is a schematic diagram of a ticketing system.

The system of figure 1 mcludes a ticketing control centre 1, a buyer's computer system indicated generally as 2 and a venue access control system indicated generally as 3. The ticketing control centre can communicate with the buyer's computer system and the venue access control system via the internet 4.

The ticketing control centre 1 includes a central processing section 5 and a ticketing data store 6. The processing section 5 is connected to the internet via a web server interface 7 and an interrogation interface 8. The buyer's computer system 2 includes a personal computer (PC) 9 which is connected to the internet 4. The PC is connected to a local printer 10 which can be used to print data displayed on the PC on to paper. The PC includes web browser capability for communicating with the web server 7 over an HTTP (hypertext transfer protocol) channel. The web browser acts as a communication interface with the web server and formats data received by the server into a visual representation of that data which can be displayed by visual display unit 23 or printed by printer 10. Preferably the PC and the server 7 are capable of communicating using a link such as HTTPS (secure HTTP) that incorporates security features.

The access system 3 includes a turnstile 11 which is arranged physically so that it can restrict access to the venue. The turnstile is connected to the internet. The turnstile includes a processing unit 12 which is connected to a barcode reader 13. The processing unit is also connected to a latch of the turnstile bail 14 whereby the processing unit can temporarily release the bail to allow access to the venue, practice, a number of similar turnstiles will preferably be provided at the venue.

In operation, details of the ticketing arrangements for a future event are stored in the data store 6 by means of entries made to the processing section 5. These details will typically include the specification of the event itself, for instance its date, time location and what is to be presented at the event, and the number of tickets that are available, their prices and (if relevant) their seat numbers. The web server 7 is arranged to serve web pages that provide details of ticket availability as derived from the data store 6, to permit a user browsing the pages to buy one or more tickets, and then to serve one or more pages of ticket data to the user together with instructions that those ticket pages are to be printed by the user. The user prints the pages using local printer 10. The ticket pages include a bar code generated by bar code generator 15 at the web server 7 and transmitted as an image file to the user's browser. A record of the ticketing operation is stored at the data store 6, and includes the code that was included on the ticket as a bar code and an indication of the venue, time, date etc. for the ticket. When the user attends the venue he presents a printed ticket page to bar code reader 13. The bar code reader 13 reads the bar code, and provides the read code to processing unit 12. The processing unit 12 interrogates the data store 6 via the internet 4 to determine whether the bar code that was read was included in a ticket for the venue at the present time. If it was then the processor releases the bail 14 to allow access to the venue. If it was not then the processor keeps the bail locked to prevent access until a valid ticket is presented.

When tickets are to be issued for a future event a new event record is created in the store 6. Each event record suitably includes a specification of the number of tickets that are available for the event and their prices, together optionally with some or all of the following information:

• Company identifier (name and barcode number)

• Event code

• Venue code (It might be possible to have a database of all venues' seating arrangements but these are likely to be variable dependent upon the nature of the event being staged)

• Scheduled start dates and times for the event

• Start and cut off point for sales of tickets for the event

• Cancellation details

• Refund details

The event record can also store the status of seats for the event. The status is suitably represented by a code that indicates whether the seat is available, allocated or sold. Seats that are available can be offered for sale to potential buyers. Seats that are allocated have been temporarily allocated to buyers who are in the course of a buying process. Seats that are allocated or sold can not be offered for sale to potential buyers. The data in the event record is accessed by the web server 7 to determine what tickets are available and to present information about events and available tickets to a user, as well as to store information on ticket status.

When a ticket is sold a ticket record corresponding to that sale is created in the store 6. The ticket record includes an indication of the event for which the ticket has been sold, which could be in the form of a link to the corresponding event record, and an indication of the code number allocated to the ticket. Alternatively, the equivalent of such a ticket record could be stored as part of the corresponding event record. The ticket record could also include additional verification information such as a PIN, the answer to a security question, details of the credit card used for payment, the name and/or address of the buyer, or a photograph of the intended user of the ticket. With a photograph, the user would preferably cither upload an appropriate photographic image of themselves to include in the record at the time of buying the ticket, or select an image that had previously been uploaded and stored at the data store 6.

The web server 7 is arranged to serve web pages, for example in HTML (hypertext mark-up language) and/or XML (extensible mark-up language). The web server suitably generates the pages on demand from data stored locally to the web server and from data derived by the web server from the data store 6. The pages are suitably generated by an ASP (active server pages) system, for example using server processor 21. The web server also includes instructions for generating a code number for each ticket. The code number could be generated by code number generator 22. When a ticket page is to be generated the web server 7 forms a code number for the ticket according to a predetermined algorithm In a simple algorithm, the code number could simply be a serial number for the ticket In a more complex algorithm the code number could include extra digits for authentication purposes, or a hashing function could be applied. Preferably there is no correlation between the cede number and the seat numbers so that it is difficult for a potential ticket forger to predict a bar code that could be used to gain entry to an event. The code number is represented on the ticket page by the bar code, which directly represents the digits of the code. Once the ticket has been issued, the code number is stored at the data store 6 as part of the record for that ticketing transaction so that the ticket can be authenticated when it is presented to reader 13. The web server could be hard wired to perform its functions, but it is typically more convenient to implement it by means of a suitably programmed general purpose computer.

An important feature of the system is the bar code image generator 15. The code number is passed to the bar code generator 15. The bar code generator forms an file in an image format, for example a GIF, JPEG, TIFF or bitmap file, that represents an image of a bar code corresponding to the code that was passed. The image could be generated by encoding the characters of a conventional bar code font in individual image format files, storing those files at the bar code generator, and then on receipt of the code number forming an overall image file by joining together copies of the stored files in the appropriate order to form a composite image file that represents the code. That file is returned to the body of the web server so that it can be served to the web browser of the buyer's PC 9 as part of a web page. It is preferred that the image format of the image file is one such as GIF that is capable of being displayed by a conventional web browser or like systems on a typical client PC, since tins increases the likelihood that the image will be displayed and printed correctly by the PC. It is also preferred that the image file encodes image data on each individual pixel of the image and/or losslessly, as in a GIF or bitmap format, rather than by blockwise and or lossy compression, as in a JPEG format, since this increases the likelihood that the image will be displayed and printed sufficiently accurately by the PC that it will be read by the reader 13. The image file could be a composite of a number of image blocks, for example a number of GIF image blocks, accompanied by code indicating the mutual relationship of the image blocks. Such code could, for example, be in a mark-up language such as HTML. It has been found that generating an image file at the server that represents the bar code that is to be included on a ticket and transmitting that image file to the client browser gives improved standardisation of the form of the barcode as printed, which greatly increases the likelihood that the barcode will be correctly read by the reader 13 in comparison to systems in which the bar code is generated at the client PC.

At the venue there is preferably a local storage unit 16 which includes a processing section 17 and a data store 18. The processing section is preferably arranged to download from the store 6 to the store 18 the ticket data for an event shortly before the event starts. The local storage unit is connected to the turnstile 11. If the connection over the internet 4 to the ticketing unit 1 fails when tickets still need to be validated by the turnstile 11, the turnstile 11 can access the store 18 to validate at least the tickets that had been sold up to the point at which the data was downloaded to store 18.

Furthermore, by storing information relating to the reading of the bar code scan, such as where and when the ticket is read, an audit trail is effectively generated. This information can either be stored centrally at data store 6 or locally at data store 18. Processing sections 5 and 17 can use this stored information to notify operators of possible fraudulent use via a retrieval page that can be displayed on PC 24. Preferably the PC 24 is arranged to attach to both processmg section 5 over the internet, and processing section 17 locally. The retrieval page may contain information on the vahd ticket holder, such as address, date of birth and credit card number, and where the ticket has been read. Any suspected fraudulent use can also cause the ticket to be rejected and the user referred to an operator, who can then verify the user by using the information on the retrieval page.

In the example of rail travel, the same ticket should not be read and access given twice at the same location. If this does occur, the ticket can be rejected and an automatic notification be sent to the PC 24 by one of the processing sections, thereby alerting the operator to a possible fraudulent use.

Similarly, the audit trail may also assist staff in locating a particular ticket user, to at least the area in which the user has gained access to by his last ticket read. In the example of an airline ticket, scanning points can be located in strategic places such as at check-in, security, lounge and boarding, allowing an operator to determine the location of the user by using PC 24.

For additional security, the ticket buyer may be informed of a personal identity number (PIN) at the time he buys the ticket. Alternatively the user could select a PIN, or an account that the user may have with the operator of the ticketing unit 1 could have a stored PIN associated with it. That number is preferably not related to the bar code, and could be generated randoroJy by the web server 7. The buyer is instructed to memorise the PIN. Preferably the PIN is not shown on the ticket page that is to be printed by the buyer, but is stored in the record for the ticket in store 6. When the buyer reaches the turnstile 11 he is instructed to enter the PIN ro keypad 19, which is connected to processor 12. The processor 12 or processor 5 then verifies both the bar code on the ticket and the PIN against the records in the store 6 and allows access only if both are match a record in the store for the event. Other means of verification could be provided. For instance, when buying a ticket the user could be asked to provide the answer to a security question such as their date of birth which is stored as part of the ticketing record in store 6 and must be entered at the turnstile and verified in order to permit access. Alternatively, the user's credit card details could be stored in store 6 for verification at the venue.

As an alternative to turnstile 11, staff charged with controlling access to the venue could be provided with bar code reader devices capable of communicating with store 6 and/or store 18 and providing an indication of whether the read bar code matches an appropriate record in the store(s).

If an access area is staffed, and if the user has taken advantage of the photographic verification facility by uploading an image of themselves onto the data store 6, then photograph verification can be utilised. When the ticket is read, the photograph stored on the ticket record can be downloaded by from data store and stored on a retrieval page that can be displayed on PC 24 or any other suitably a suitably arranged device such as a personal digital assistant (PDA) or laptop. A staff member can then use this photograph to verify the user before allowing them access. Such a photographic facility provides for validation of a user that is difficult to bypass fraudulently. _h

If a user of PC 9 accessing the web server 7 wants to buy tickets for more than oDe event, the web server preferably provides the user with the choice of having one ticket issued for each event or having a single combined ticket issued that will provide entry to all those events. If the user selects the former option then the web server sends the user a series of ticket pages in turn, each of which includes a different bar code and each of which is to be printed by the user. Separate records corresponding to each of those tickets are stored as described above in store 6 for later verification of the tickets. If the user selects the latter option then the web server sends the user a single ticket page which includes a single bar code. Then separate records, each corresponding to one of the events for which the combined ticket is valid but each including the same bar code, are stored in the store 6.

The ticket page to be printed by the user may include text that indicates the details of the event for which the ticket is valid, for instance the date, time, venue, seat number etc.. The text may include terms and conditions associated with the ticket.

The user may pay for the ticket by providing his credit card details to the web server 7 in the normal way. The web server can then pass those details to a payment processing unit 20 which communicates with a bank's electronic financial transaction server. The web server is preferably arranged so Lhat it does not issue the ticket until the payment processing unit 20 returns a signal indicating that the payment has been successful. One potential advantage of the present system over some prior art systems is that tickets can be issued and printed using the present system right up to the time of the event, and then verified automatically. There is no need for the tickets to be delivered by post, and hence delayed.

PCs and associated local printers could be provided at the venue so that tickets can be bought on the spot.

An example of the operation of the web server 7 will now be described.

Tn this example the web server generates web pages and serves them to the browser of a prospective buyer of a ticket. The order in which data is presented to the prospective buyer as he moves from one page to the next is as follows:

1. Opening screen

2. Selection of event

3. Selection of seats

4. Confirmation of order

5. Credit card verification

6. Ticketing options

7. Printing of tickets

The opening screen on the web site displays a welcome and invites the customer to enter some details to find an event for which they can buy tickets. A simplified example of the opening screen is shown below. Welcome to xxxxxxxx.com - where you get the tickets no

Please enter your selection criteria

Artist <Dτop down list of artists / perforrners>

Dates <Drop down calendar>

Venue <Drop down list of veπues

Location Drop down list of towns>

Price range <Singlc ticket budget>

<Search

The database of artist dates, venue, location and price may be generated using data extracted from the database of events in store 6 for which tickets are available.

Depending upon the selection criteria input, a list of events will be displayed.

After the user has entered data and triggered the search, the web server checks the database of events in store 6 for which tickets are available and generates a page to fist the results. The page is served to the user's browser. A simphficd example of the results page is shown below.

Results from your selection Events currently available

Date Artist Venue City

March 16 (Friday) Jerry White Harwell Park Birmingham March 16 (Friday) The Blue Boys Villa Park Birmingham

March 1 (Saturday) Jerry White Harwell Park Birmingham

March 17 (Saturday) Manuel Kay NEC Birmingham

March 17 (Saturday) Irene Brown Mission Centre Solihull

March 17 (Saturday) The Blue Boys Villa Park Birmingham

The screen will operate in typical hst mode. The customer will be able to scroll up and down, select any event from the hst or change the selection and start again.

On selecting an event the web server checks the database in store 6 to determine what tickets are available for the event and generates a page to list the results. The page is served to the user's browser. A simplified example of the page is shown below.

March 17 (Saturday) The Blue Boys Villa Park Birmingham

Seating plan

A graphical representation of the seating plan would normally be shown here

Pricing Section A £15.00

Section B £19.00

Section C £24.00

Section D £28.00

Section E £32.00

<Cancel selection> <Proceed> The user can select the seat he requires, taking into account the information displayed.

The web server could store a database of venues, with seating plans for each venue for different event types. Displays could include dimensions, exits, seat locations and numbers other customer type details. The ability to graphically see which seats are available is likely to be of great interest to customers and promoters.

The user selects one or more seats. In response the web server generates a page to confirm the details of the selected seat(s). The page is served to the user's browser. A simplified example of the page is shown below.

Your selection

March 17 (Saturday) The Blue Boys Villa Park Birmingham

2 seats Section D Seats 42G 42H . £56

Total £56

Once the seats have been selected, the web server transmits an indication of that fact to the processor 5. The processor then causes the seats to be switched from an available state to an allocated state in the store 6. The processor 5 is arranged to, if the seats are not sold within thirty minutes, switch them back to the available state so that they are released for sale again. Whilst the seats are in the allocated state they are not offered to other prospective buyers.

For the purposes of this example, only one selection of tickets will be shown. However, as described above, the user may select scats for more than one venue and combine them on the same ticket. Once the user has confirmed his seat selection the web server generates a page to accept the user's credit card details for payment. The page is served to the user's browser. A simplified example of the page is shown below.

Billing

Enter credit card details Visa/ MC / Amcx Card number Expiry

The customer enters details of credit card to facilitate payment and returns them to the server, preferably over a channel including security features, such as HTTPS. It may be necessary for additional details to be entered, such as name and address.

Once the payment details are verified, the web server proceeds to ticket issue. The web server generates a page to accept information from the user on how the ticket(s) are to be delivered. The page is served to the user's browser. A simplified example of the page is shown below.

Ticketing - - You may choose how you wish to receive the tickets

Printing your ticket directly will enable you to take your tickets directly to the venue and present it at the gate to obtain entry.

Delivery method «Courier> <Print now> <Collect>

Name: Address:

Please indicate the number of tickets you wish to print

All seats for same performance on <one ticket> <separate tickets>

Note that the quahty of the tickets is related to the quahty of your local printer. If you wish to confirm your printer's suitabihty, then <click here>

As indicated above, the page may optionally give the user an opportunity to test the quahty of their local printer, for example to check that it has ink and is configured correctly. The page may also give the user an opportunity to select separate tickets or a single combined ticket. As an alternative to printing the tickets the user could be offered the opportunity of having the tickets printed by the ticket issuer and delivered, or of collecting the tickets at the venue. These options may be valuable to users who do not have local printers.

If the user selects to print a ticket locally, the web server forms a ticket page for that ticket. To do this it generates a code number for the ticket, and passes that to the bar code generator 15 which returns a corresponding image file as described above. That image file is embedded in the ticket page and transmitted to the user's browser so that it can be displayed and printed as part of the page. An example of a ticket page is shown below. You must print this ticket page in order to gain access to the event.

March 17 (Saturday) The Blue Boys Villa Park Biπningham

Performance starts 19:00 Section D Seats 42G 42H £56 CCDD-SSAA

##### Bar code image here #####

Terms & Conditions

It is your responsibility to ensure that this ticket is not photocopied or re-printed in order to obtain entry illegally.

It is recommended that you bring along the credit card used to purchase the tickets to assist in confirming your identity.

Although it is preferable for the bar code image to be displayed on the page, it can also remain hidden from view until printing, and only be displayed on the printed ticket.

The present system can be used to issue tickets for a wide range of types of event, for instance entertainment or sports events, travel and restaurants. Although the issuance of tickets for seats has been discussed, the event need not involve the use of seats.

The system may also be advantageous when used on a company's internal network. The system could be used to allow an employee of the company to acquire tickets over a link to a ticket sales server internally in the company or connected to the company's mtemal network over a public or private connection. The user could book tickets by means of a transaction with the server and then receive information defining a bar-coded ticket to be printed out by him. Payment for the tickets could be made at the point when the tickets are acquired, or subsequently by means of a company account with the supplier of the event(s) for which the ticket is issued. The ticket could be for events of one or more types, and for one or more people.

In some aspects of the system the bar code could be transmitted other than as an image, for example as a font.

The ticket could take the form of a voucher. The voucher could provide access to services such as events or could even provide access to goods. One advantageous use of such a voucher is as a benefits voucher. An voucher issuing body such as a state social security department may wish to provide cash-equivalent benefits to people that are to be used for specific actions, such as the purchase of groceries or a specific train journey, with the intention that they are not to be used for unauthorised actions, such as the purchase of alcohol or tobacco. To achieve this the issuing body could issue vouchers each of which carries an identifying code. In a database administered by the issuing body the code of each voucher could be stored together with an indication of the action for which the voucher is to be used.

The action could also be printed in human-readable form on the voucher. The code is preferably printed on the form as a bar code. The voucher is issued to the recipient. When the recipient wishes to use the voucher he presents it at a place where the action is available he presents the voucher. Equipment there reads the code and verifies the action corresponding to the voucher in the manner described above. If the voucher does correspond to the action for which it is presented then it is accepted by the shop, train station etc. to which it has been offered. The operator of that venue claims back the value of the voucher from the issuing body. The claim could take place automatically when the voucher is validated: the issuing body's computer system that validates the voucher could recognise an identity of the claimant from the identity of the claimant's code scanner or system and the validation of the voucher could trigger payment by the issuing body to the claimant's accoimt. If the voucher is not validated then the action is refused by the provider of the action.

The apphcant draws attention to the fact that the present invention may include any feature or combination of features disclosed herein either implicitly or explicitly or any generalisation thereof, without limitation to the scope of any of the present claims. In view of the foregoing description it will be evident to a person skilled in the art that various modifications may be made within the scope of the invention.

Claims

1. A method for issuing a ticket to a user of a communication interface for communicating with a data server over a publicly accessible communication network and formatting data received from the server, and of a printer capable of printing information formatted by the communication interface, the method comprising: generating a code number for the ticket; forming an image file of an image file format, the image file representing an image in that format of a bar code corresponding to the code number; and providing to the communication interface over the publicly accessible communication network by means of the data server ticket data defining the appearance of a ticket, the ticket data including the image file.

2. A method as claimed in claim 1, comprising the step of formatting the ticket data by means of the communi cation interface and printing the formatted ticket data including the image file by means of the printer.

3. A method as claimed in claim 1 or claim 2, comprising the step of providing to the communication interface by means of the data server data instructing the user to print the formatted ticket data.

4. A method as claimed in any preceding claim, comprising the step of storing in a remotely accessible data store the code number in association with an indication of an event for which the ticket is valid.

5. A method as claimed in claim 4, comprising the step of storing in the remotely accessible data store the code number in association with an indication of a plurality of events for which the ticket is vahd.

6. A method as claimed in claim 4 or 5, comprising the steps of: reading the bar code by means of a machine bar code reader associated with an event; comparing the read code with the data stored in the remotely accessible store to determine whether the read code is stored in association with an indication of the event wi h which the bar code reader is associated; and if the read code is stored in association with an indication of the event with which the bar code reader is associated permitting access to the event and otherwise denying access to the event.

7. A method as claimed in claim 6, wherein the said comparison step is performed by a processor local to the remotely accessible data store and the method includes the steps of: transmitting an indication of the read code from the bar code reader to the processor; and transmitting an indication of the result of the comparison to an access control unit local to the bar code reader.

8. A method as claimed in any of claims 1 to 5, comprising: storing verification data associated with the ticket; reading the bar code by means of a machine bar code reader associated with an event; comparing the read code with the data stored in the remotely accessible store to determine whether the read code is stored in association with an indication of the event with which the bar code reader is associated; obtaining vahdation data from a user of the ticket; retrieving the verification data associated with the ticket; and if the read code is stored in association with an indication of the event with which the bar code reader is associated and the vahdation data matches the verification data permitting access to the event and otherwise denying access to the event.

9. A method as claimed in claim 8, wherein the vahdation data and the verification data comprise a personal identification code.

10. A method as claimed in claim 8 or 9, wherein the vahdation data comprises the appearance of the user and the verification data comprises an image of the user.

11_. A method as claimed in any of claims 8 to 10, wherein the verification data is stored at a data store remote from the machine bar code reader and in the said retrieving step the verification data is retrieved from the data store.

12. A method as claimed in claim 11, wherein the data store is co-located with the data server.

13. A method as claimed in any preceding claim, wherein the communication interface is a web browser.

14. A method as claimed in any preceding claim, wherein the data server is a web server.

15. A method as claimed in any preceding claim, wherein the publicly accessible communication network is the internet.

1 . A method as claimed in any preceding claim, comprising the steps of: storing data defining a plurahty of available events; receiving at the data server from the communication interface an indication of at least one event for which a ticket is required; and receiving at the data server a financial authorisation number.

17. A method as claimed in claim 16, wherein the formatted ticket data includes a humanly readable indication of the said at least one event.

18. A method for issuing a ticket to a user of a communication interface for communicating with a data server over a communication network and of an output device capable of forming a portable information record, the method comprising: receiving an indication of a plurality of actions for which a voucher is required; generating a code for the voucher; stormg in a remotely accessible data store the code in association with an indication of the said plurahty of actions for which the voucher is to be valid; providing the code to the communication interface over the commumcation network by means of the data server; and outputting by means of the output device a portable information record carrying a record of the code.

19. A method as claimed in claim 18, wherein the output device is a printer.

20. A method as claimed in claim 18 or 19, wherein the code is represented on the portable information record as a bar code.

21. A method as claimed in any of claims 18 to 20, wherein the portable information record is a ticket.

22. A method as claimed in any of claims 18 to 21 comprising the steps at an event of: reading the code carried by the portable information record; comparing the read code with the data stored in the remotely accessible store to determine whether the read code is stored in association with an indication of the action; and if the read code is stored in association with an indication of the action with which the bar code reader is associated permitting access to the action and otherwise denying access to the action.

23. A method as claimed in claim 22, wherein the code is read by a code reader associated with the action.

24. A method as claimed in claim 23, wherein on being read, the read code is automatically transmitted to the remotely accessible store.

25. A method as claimed in any of claims 22 to 24, wherein the step of comparing is performed locally to the remotely accessible store.

26. A method as claimed in any of claims claim 18 to 25, wherein each action is an event.