MOBILE TERMINAL

The present disclosure relates to an access authentication method and to a system for implementing the method. The method may find use, in particular, in the context of ticketing.

When demand for tickets to live events (sport, music, festivals, theatre, etc.) exceeds supply, ticket touting (also known as scalping) frequently occurs. The touts are normally criminal gangs, industry insiders or opportunists. Money is made by buying tickets and reselling them for a profit. In some cases, for extremely high-demand events, tickets are resold by touts at many times the face value.

Event organisers typically appoint one or more primary ticket agents to sell tickets to their live event. Touts compete with genuine fans to acquire tickets, but are often more successful than the fans at obtaining tickets due to the methods that they employ, which include the following:

1 . Tickets are obtained by insiders and never even enter the primary market, they are only ever listed on secondary websites.

2. Touts use botnets to rapidly buy tickets from the primary websites and relist on the secondary websites.

3. The secondary websites buy tickets from the primary websites and list them on their sites.

4. Opportunists purchase more tickets than they require with the intention of reselling at least some of them to make a profit or to cover the cost of the ticket(s) that they want to use themselves.

Such practices are facilitated by the current ticketing mechanisms, including the form of ticket issued (which is generally a conventional paper or electronic ticket that may be readily transferred between parties) and a lack of authentication at purchase.

Fans are becoming extremely angry at the inherent problems with the present system. Additionally, an increasing number of artists both resent the touts who make money from their talent without contributing anything beneficial to the process, and have genuine empathy for their fans not being able to obtain tickets. It is not unusual for 20% of tickets to an event to be touted and in extreme scenarios it can be that as much as 80% of tickets are touted. It is further noted that aside from conventional ticketed live events, such as concerts, sports matches, etc, touting exists in respect of all manner of alternative live events, from train tickets being touted in India, to doctors' appointments being touted in China. These have obvious socio-economic implications that current systems do not appear able to deal with.

It is to be noted that the term live event as used in the present application is intended to cover any event, the timing of which is predetermined or outside the control of the user.

During a consideration of the problems with current ticketing systems, the inventors arrived at the access authentication method and system of the present invention, which are ideally suited to ticketing applications. Whilst this disclosure focuses on ticketing, the present invention will be suited to further uses, as will be appreciated by those skilled in the art. Its use is not to be limited to ticketing.

According to the present invention in a first aspect, there is provided an access authentication method comprising: authenticating a user account; establishing account holder verification by detecting a predetermined biometric input from the account holder to establish the presence of the account holder at a user terminal; and, in dependence on successful account holder verification, providing an access means that is readable at the user terminal for authenticating account holder access.

The method may be configured such that the account holder verification is not always required for authenticating account holder access. The requirement for account holder verification may be linked to a risk profile associated the account holder and/or to a risk profile associated with an event to which the account holder is seeking to obtain authorised access and/or to environmental conditions proximal the user terminal at the time of authentication.

In particular, prior to the step of establishing account holder verification by detecting a predetermined biometric input, a risk profile associated with the account holder and/or a risk profile associated with an event to which the account holder is seeking to obtain authorised access and/or environmental conditions proximal the user terminal at the time of authentication may be reviewed, and the step of establishing account holder verification by detecting a predetermined biometric input will be required or bypassed in dependence on the results of such review.

The risk profiles may comprise collated information held in a ticketing platform database and/or external databases.

The environmental conditions may be sensed using sensors on the user terminal and/or may be retrieved from the Internet or another data source separate to the user terminal.

The type of biometric input required to establish the presence of the account holder at the user terminal may be varied in dependence on the environmental conditions.

The access means may be user (i.e. manually) readable or machine readable. The access means most preferably comprises a machine readable visual element that is displayed on a screen of the user terminal, which may comprise a mobile phone. In such case, the provision of the access means comprises the rendering of the visual element. Authentication may occur by a scanning of the visual element at an access terminal that is local to the user terminal.

The access means preferably comprises a ticket. The ticket is preferably inextricably linked to a single unique user account. With the access means readable local to the terminal and the user's presence at the user terminal verified, a secure ticketing system may be provided.

Further, preferred, features are presented in the dependent claims.

According to the present invention in a further aspect, there is provided a ticketing system implementing the access authentication method defined above.

According to the present invention in a yet further aspect, there is provided an access authentication system comprising a user terminal; means for authenticating a user account; a biometric input device in communication with the user terminal for detecting and verifying a predetermined biometric input to establish the presence of the account holder at the user terminal; and means for providing an access means at the user terminal, in dependence on successful account holder verification, which access means is readable at the user terminal for authenticating account holder access. The access authentication system may be configured such that the account holder verification is not always required for authenticating account holder access. The

requirement for account holder verification may be linked to a risk profile associated the account holder and/or to a risk profile associated with an event to which the account holder is seeking to obtain authorised access and/or to environmental conditions proximal the user terminal at the time of authentication.

The type of biometric input required to establish the presence of the account holder at the user terminal may be varied in dependence on environmental conditions.

The system preferably further comprises an access terminal, which is local to the user terminal and comprises means for reading the access means. Non-limiting embodiments will now be described, by way of example only, with reference to the accompanying drawings, in which:

Figure 1 shows a schematic view of an access authentication system in accordance with a first embodiment;

Figure 2 shows a flowchart which indicates the steps in a biometric authentication forming part of the access authentication method according to an embodiment of the present invention;

Figure 3 shows a flowchart which indicates the steps in a human interaction verification process that comprises an access authentication method according to an embodiment of the present invention;

Figure 4 shows a flowchart which indicates the steps in a ticket rendering process that comprises an access authentication method according to an embodiment of the present invention;

Figure 5 shows a flowchart which indicates the steps in a primary ticket sale process, which incorporates an access authentication method according to an embodiment of the present invention;

Figure 6 shows a flowchart which indicates the steps in a secondary ticket listing process; and

Figure 7 shows a flowchart which indicates the steps in a secondary ticket sale process, which incorporates an access authentication method according to an embodiment of the present invention. With reference to Figure 1 , there is shown an access authentication system for implementing an access authentication method. The access authentication system of the present arrangement may, as discussed, comprise a ticketing system. The system comprises a user terminal 1 , which comprises a smartphone but could comprise any alternative personal computing device, as will be readily appreciated by those skilled in the art. The user terminal 1 connects through the Internet to a ticketing platform server 2. The ticketing platform server 2 accesses a ticketing platform database 3. The ticketing platform database 3 securely stores account details of any registered users of the ticketing platform, including biometric data and any purchased tickets associated exclusively with each of the ticketing platform accounts. The ticketing platform server connects through a service bus 4 to a third-party server 5. The third-party server 5 is associated with a ticket seller, which may comprise a primary sales agency or a reseller (who may be an individual or a company). An access terminal 6 is provided, which is local to the user terminal 1 at the point of authentication and may read an access means from the user terminal to grant access to the authorised user of the user terminal. The access terminal 6 may comprise a suitable scanning means for such purposes. The access terminal 6 connects through the Internet to the ticketing platform server 2 for validating the access means. It should be noted that whilst only a single user terminal 1 and a single access terminal 6 are shown, there will be multiple user terminals 1 within the system and may be multiple access terminals 6, in dependence on the size of the ticketed event. Moreover, there may be multiple third party servers 5 (which may belong to distinct ticketing agencies) connected to the service bus 4. The structure of the ticketing platform back end may be varied in any suitable known manner.

The architecture of Figure 1 represents an example arrangement only and the present invention is not to be limited to that shown. As will be readily appreciated by those skilled in the art, various alternative network arrangements may be implemented within the scope of the present invention.

The access authentication method allows for the secure distribution and

management of tickets through user terminals 1 on behalf of primary and/or secondary ticketing agents.

With such a ticketing platform access to events will be through a ticket on a user's smartphone 1 (or other user terminal). As will be described in greater detail below, the ticket may take any of a number of forms that are termed generally herein as access means. Most preferably the ticket will comprise a machine readable visual element on a screen of the user terminal, such as a linear or matrix barcode, which may be scanned with the access terminal 6 to permit access to a ticketed event.

A user will create an account with the ticketing platform provider. Note that the account will preferably be independent of any ticket selling agency. At this time, they will register biometric data to be associated with that ticketing platform account. For example, they may take a self-portrait photo (a "selfie") using their smartphone. The biometric data may alternatively comprise fingerprint data, voice data, vein pattern data, retinal data, or any alternative biometric data suitable for recognition purposes. Such data will be stored in the ticketing platform database 3 and/or locally at the user terminal 1 for verification purposes both at ticket purchase and ticket authentication. With the account creation process completed before they purchase a ticket, the user can proceed to purchase their ticket(s) through a primary ticket agent. They will provide the primary agent with their ticketing platform account details and the tickets will be passed to their ticketing platform account when the sale is complete. When the user is preparing to attend an event, they will login to their ticketing platform account. To access the respective ticket associated with that account they verify their presence at their user terminal by providing a suitable biometric reading, such as taking a second "selfie". With their presence verified based on the biometric data, the ticket (access means) is rendered on/by the user terminal and the user can gain access to an event by presenting their user terminal to a suitable terminal at a venue, which may read the access means. If the user's presence cannot be verified the ticket (access means) will not be rendered on/by the user terminal and the user will not be able to access the event. A fail safe manual visual authentication process is preferably further provided in the event of verification problems, connection problems, or similar.

In the context of a ticketing platform, it is acknowledged that touts may want somebody else (i.e. the person they've sold the ticket to) to access their account and may do everything they can to help them do so. In order to prevent circumvention of the biometric authentication, the access authentication method may have additional security features included. These may include one or more of the following techniques, which may be used together or in combination: 1 . Changing the ticket code frequently - To prevent a tout going through biometric authentication themselves to render a ticket's details, then sending a screenshot to the person who's bought the ticket from them, the ticket code may be changed frequently, for example every few seconds. The screenshot will be obsolete before it can be used.

2. Rapid timeout (when the ticket comprises a graphic element) - The amount of time the ticket is rendered on screen before it times out and requires re-authentication can be limited. This will force the ticket holder to be very close to a venue's access point during the authentication process. The closer a person is to the venue's access points, the closer they are likely to be to the venue's security personnel who can observe any suspicious behaviour.

3. Forcing a manual inspection the first time an account is used on a device - the first time a given user tries to go through biometric authentication on a given device to render a ticket they could be referred for a manual inspection.

4. Geolocation/Beacons - Using either geolocation or beacon technology, the ticketing platform provided could check whether the device that is rendering the ticket is physically located close to the venue access point. This would help to prevent spoofing of screen-captured tickets. Users of devices that fail this check could be made to go through a manual security check, including the use of further biometric authentication. 5. Random head and facial movements (when a "selfie" is used) - In order to ensure that a real person is being authenticated rather than simply a photo, facial recognition software may check for liveness. For example, this could be the requirement to blink on request. Any alternative random movements or sequences of movements to check for liveness e.g. (moving head side to side, up and down, etc.) could be introduced as a requirement. This will also help to prevent a pre-recorded video from being used to fool the system.

The access authentication method is also of particular use for an anti-botnet system. In the context of ticketing, by the introduction of an effective human interaction verification step, botnets can be prevented from scooping up tickets in vast quantities at high speed. A user may be provided with a code that is only given out when they have passed a biometric authentication test. This code would be input into the primary or secondary ticketing website by the user and that website would verify with the ticketing platform that it is a valid code, and therefore the user is genuine, prior to allowing completion of a purchase.

This anti-botnet feature, whilst described herein primarily in the context of a ticketing system could also be offered as a stand-alone service as an alternative to solutions like CAPTCHA™, wherever it is important to know that a web-based process is being used by a real human being.

With reference to Figure 2, detail of the biometric authentication is now provided, which biometric authentication forms part of the access authentication method.

Biometric authentication may only occur following the setting up of a user account. As part of the user account setup process, biometric data is recorded (preferably at the user terminal 1 , which runs a client software package in the form of a user application or otherwise), and is uploaded to the ticketing platform server 2 for secure storage in the ticketing platform database 3 in association with the user account.

The user when performing subsequent actions on their account, including purchasing tickets, validating tickets or selling or transferring tickets will be required to confirm their presence at the user terminal 1 , wherein such action is performed by providing the suitable recorded biometric input. It should be noted that the client software package may also securely store the biometric data locally on the user terminal 1 , such that biometric authentication may occur at the user terminal 1 without an Internet connection. Alternatively or additionally, the client software package may instruct a communication with the ticketing platform server 2 to validate a biometric input at the user terminal 1 .

The biometric input may, for example, comprise one or more of: fingerprint recognition, voice recognition, facial recognition, vein pattern recognition or retinal scanning.

In order to perform the biometric authentication, a user will first login to the client software package, which may comprise inputting a username or password, or similar. Such action represents the authentication of the user account. The user may then initiate the biometric authentication by performing a predetermined biometric input step in dependence on the stored biometric data associated with their user account. In the case of facial recognition, for example, the user may take a self-portrait photo (a "selfie") using a front facing camera of the user terminal 1 , which is checked against a stored photo. A liveness detection step may be required, or not, as a further security measure in addition to the biometric verification. As discussed below, alternative/additional security measures may be implemented in addition to the biometric verification or in addition to the biometric verification and liveness detection. Moreover, no further security measure may be included, that is the biometric verification may not be supplemented by any additional security measure.

The liveness detection step may comprise detecting an ancillary predetermined user input from the account holder to establish the account holder's presence at the user terminal 1 . The detection of the predetermined biometric input and the detection of the ancillary predetermined user input may be carried out in a single combined step or in separate steps.

In the case of facial recognition, the ancillary predetermined user input may comprise detecting a particular facial expression or head or body movement. Irrespective of the predetermined biometric input, the ancillary predetermined user input could alternatively or additionally comprise, for example, one or more of: detecting a particular combination of fingers on a scanner, detecting a particular phrase or pattern of phonemes, keypad input of a pin code, or the electronic capture of the user's signature.

Following successful authentication, with or without the liveness detection step, the user may perform an action on their account.

There may be a maximum predetermined time period from the initiation of the biometric authentication to it successful completion. There may be a maximum number of failed authentication attempts permitted before the user account is locked. Additional security steps may also be implemented.

With reference to Figures 3 and 4, two complete exemplary access authentication methods are presented. Figure 3 shows a human interaction verification step, which represents an anti-botnet system as described briefly above, and which may be

implemented independently of any ticketing system. Figure 4 shows a ticket rendering step, which represents the provision of an access means (comprising a ticket) as again described briefly above. In the example of Figure 3, the scenario of a website requiring human validation is considered. A user receives a request from the website for a human verification. The user with a user account formed as above (although not necessarily for ticketing purposes) will login to the client software package using a user terminal 1 and request an access means, which will comprise a user/manually readable visual element to be displayed on a screen of the user terminal 1 . Following successful biometric authentication, performed in accordance with the discussion of Figure 2, the access means will be provided, which comprises a passcode in Figure 2. The passcode is manually entered into the website. The website verifies the passcode and, upon successful verification, grants access to the user.

The visual element may, for example, comprise an image, word, number or code for direct manual input (or for prompting a suitable manual input) by the user. Such input may occur at the user terminal 1 , or at a secondary terminal, in dependence on the device being used to access the website. A user may for example use a laptop computer to access the website and a smartphone for the access means generation, alternatively all steps may be taken using the smartphone.

In Figure 4, the provision of an access means, which comprises a ticket to obtain access to a live event, is considered. The user with a user account formed as above will login to the client software package using a user terminal 1 and request the access means. The step of requesting the access means comprises navigating to a part of the client software package on the user terminal 1 that provides access to information corresponding to previously purchased (but unused) ticket(s). For example, a graphic element relating to a specific ticket may be selected to request the display of the ticket on the screen of the user terminal. Upon requesting the access means (subject to any optional predetermined timing requirements being met, as discussed below) the user will be prompted to complete the biometric authentication. Following successful biometric authentication, performed in accordance with the discussion of Figure 2, the access means will be provided at/on the user terminal 1 .

Data corresponding to the access means, on the basis of which the access means is generated, is securely stored in association with the user account. It is preferable that the access means generation data is inaccessible to the user and that outside of a

predetermined time period the ticket may not be rendered on/at the user terminal 1 . The access means generation data may be stored locally on the user terminal 1 following a ticket purchase such that the ticket may be accessed without an Internet connection on the user terminal 1 at the time of ticket rendering. Alternatively, and less preferably, the access means generation data may be stored on the ticketing platform server 2 only in which case an Internet connection will be required for ticket rendering. Where the access means comprises a ticket that authenticates access to a live event, the access authentication method may only provide the access means within a first predetermined time period within which the live event starts. For example, the method may prevent the rendering of a ticket at/on the user terminal 1 earlier than 24 hours before the start of the live event. This time window may be set as desired. By preventing access to a ticket until the day of a live event or even until several hours or less before the start of an event, the possibility of sharing of ticket data to allow for touting is significantly reduced.

The access means may take numerous forms, including but not limited to a machine readable visual element on a screen of the user terminal or a predetermined wireless access signal for receipt by an access terminal. A machine readable visual element is presently preferred, whereby a conventional linear or matrix barcode may be generated based on the access means generation data for scanning in the manner of a conventional paper or electronic ticket to gain entry to an event. Existing access devices may be readily adapted to work with the method of the present application. Where the access means comprises a predetermined wireless signal, the client software package may instruct the transmission by the device of a suitable signal to be received by a suitable access terminal. The wireless signal may be transmitted by Bluetooth, WiFi, RFID (radio frequency identification), NFC (near field communication), or similar, using such suitable transmitter inbuilt to the user terminal 1 .

As discussed above, various optional additional security measures may be implemented for ensuring that the user associated with the ticketing platform account is present at the user terminal 1 at the point of entry to an event. Such measures may be implemented independently of one another or in any desired combination.

Where the ticket (access means) comprises a machine readable graphic element, to prevent a tout going through biometric authentication themselves to render the graphic element and sending a screenshot to the person who's bought the ticket from them, the ticket code may be changed frequently, which will render the screenshot obsolete before it can be used. In such an implementation, the data corresponding to the access means comprises an access means generation code and the client software running on the user terminal generates the graphic element based upon the access means generating code. A token generates the access means generating code at fixed predetermined intervals using an encoded random key. Here the key will be unique to the user account. The operation may, for example, be in accordance with operation principles of the RSA SecurelD authentication mechanism. The operation will, however, be based upon one or more algorithms that are unique to the ticketing platform. The amount of time the access means is readable before it times out and requires re- authentication can be limited, so as to force the ticket holder to be very close to a venue's access point during the authentication process.

In such an implementation, following account holder verification, the access means is readable at the user terminal for a second predetermined time period only that is shorter than the first predetermined time period (as discussed above with reference to Figure 4), after which second predetermined time period, a further account holder verification is required for the access means to remain readable. The second predetermined time period may be 15 minutes or less. Preferably the second predetermined time period is 1 minute or less. The period may be set as deemed appropriate.

The first time a given user tries to go through biometric authentication on a given device to render a ticket they could be referred for a manual inspection. The location of the user terminal may be verified. That is, it may be determined whether the user terminal 1 is within a predetermined area. Using either geolocation (including cellular triangulation, GPS (global positioning system), or similar) or beacon technology (including Bluetooth or RFID tags, or similar), at the time of ticket rendering, a check could be made whether the device that is rendering the ticket is physically located close to the venue access point. This would help, in particular, to prevent spoofing of screen-captured tickets. Users of devices that fail this check could be made to go through a manual security check, including the use of further biometric authentication. In one exemplary arrangement, each of the access terminals will be arranged to emit a signal to be received by the user terminals rendering tickets to establish the presence of those user terminals within a predetermined range of the access terminals. Such signals may be provided in accordance with known techniques, including but not limited to iBeacon technology developed by Apple, Inc. Data relating to a user account and/or a user terminal may be cross-checked against collated information held in the ticketing platform database and/or external databases as yet another additional security measure.

Non-limiting examples of this data include:

1 . Identity check - an identity look-up can be performed against various databases that check things like the electoral register, financial agreements, etc. If the person is positively and uniquely identified they are lower risk than if they're not, since touts will possibly create large numbers of fake accounts.

2. IMEI number - each time information is exchanged between the ticketing platform server and a smartphone (user terminal), the IMEI number can be detected. It would be expected to see some IMEI numbers used on more than one account, e.g. a parent with their children's accounts on their smartphone. But it would be unusual to see more than perhaps five on the one smartphone. If more than a predetermined number of accounts were to use the same IMEI number then this could trigger an alert. The predetermined number may be set as desired. For example, it could be set to 5, 10 or any other number.

3. Duplicate faces (when a "selfie" is used) - Due to accuracy limitations with facial recognition it may not be possible to be 100% certain that two faces are the same. However, if the same IMEI number is noted many times and the faces are compared and they also match, risk on the account is increased.

4. Credit card payment - when the user pays for their ticketing platform account, a check can be made that the address given for the credit card is the same as the address provided for the account. If they match it is lower risk than if they don't. With some security constraints, it can also be detected whether the same credit card is used for multiple accounts.

5. Access denied - if a person goes through biometric authentication and fails and then subsequently the person controlling an Access Control App denies them access because they don't match the photo on file then touting has occurred. Such information could be flagged on the account. 6. Whistle blowing - a whistle blowing feature may be included where somebody can report the fact they bought a ticket from a tout. Whilst there could be false allegations, such information can be captured to aid risk profiling. A generic whistle blowing feature where people can report others may also be provided.

When it is determined on the basis of any of the above data cross-checks that there is a high risk that an account is being used for the purposes of touting, an account may be blacklisted to prevent its continued use or, more preferably, constraints may be imposed on the account.

The imposition of constraints may, for example, comprise one or more of the following steps: a. High risk flag - accounts can be risk profiled and parties controlling ticketed events can decide to allow "advanced sales" to those with a low risk profile only. b. Limit tickets -the number of tickets a user can buy can be limited to a predetermined number, possibly as low as one. c. Limit Friends & Family - the number of Friends & Family a user can have or change can be limited to constrain their ability to move tickets around. (The notion of friends and family is described below). d. No resale on tickets - the buyer may be prohibited from reselling the ticket in any way. e. Ticket buyer must attend - the buyer of the ticket must attend the event and they must go through the ticket barrier before any of the other party members can.

The method/system may be configured such that the biometric account holder verification is not always required for authenticating account holder access. That is, in some circumstances for some account holders, the biometric account holder verification may be bypassed. This is likely to be of benefit, for example, to reduce the burden on low risk (i.e. trustworthy) account holders and/or to ease the flow of account holders entering large scale events. Low risk users may rarely need to go through the biometric account holder verification step, whilst high risk users will generally always need to go through the biometric account holder verification step. Local environmental factors may be taken into consideration as an additional part of the consideration.

The requirement for account holder verification may be linked to a risk profile associated with the account holder. For example, an account holder who is held to be low risk based on their risk profile may not need to go through the biometric account holder verification step for authenticating account holder access, whilst a user that is a high risk based on their risk profile will be required to do so. Such risk profiles may exist for all users. The risk profiles may comprise collated information held in the ticketing platform database and/or external databases. Such information may comprise any or all of the exemplary information presented in points 1 to 6 above, or alternative information indicative of the risks associated with account holders. In a specific example, if an account holder has passed the last five biometric authentications and the phone (user terminal) is the recognised IMEI number, then the situation is low risk and the biometric account holder verification step may be omitted, if on the other hand the account holder failed the last test and it's a new IMEI number the situation is high risk and the biometric account holder verification step will be required.

There may alternatively or additionally be risk profiles associated with events themselves, wherein the requirement for account holder verification may be linked to a risk profile associated with the event. For example, in dependence of the risk profile of an event all of the account holders attending an event or a predetermined subset of the account holders attending the event (based on their account holder risk profiles or otherwise) may be required to go through the biometric account holder verification step (or not) for

authenticating account holder access. The event risk profiles may comprise collated information held in the ticketing platform database and/or external databases. The risk profiles of account holders and events may be considered independently to one another or in combination with one another in determining which account holders must go through the biometric account holder verification.

The requirement for account holder verification may additionally or alternatively be linked to environmental conditions proximal the user terminal at the time of authentication. This is down to the fact that there are certain environmental factors that make it much harder to perform biometric authentication, e.g. low light for facial recognition and wet or cold hands for fingerprint recognition. Such environmental conditions may be considered independently or in combination with either or both of the risk profiles of account holders and events.

Environmental conditions may be determined locally or based on external data sources, such as the Internet. In a specific example, where a user is low risk and it is determined that it is dark (from a light sensor on the account holders smartphone) and is raining (from an Internet weather report), then the user may not be required to go through the biometric account holder verification step for authenticating account holder access.

The type of biometric input required to establish the presence of the account holder at the user terminal may be varied in dependence on environmental conditions. For example if it is determined to be dark then a user may be required to use a finger print sensor to perform the biometric account holder verification.

Figures 5 shows a primary ticket sale process, which implements the above described steps of authenticating a user account and, optionally, performing human interaction verification before permitting the transaction. The purchased ticket will be inextricably linked to a unique ticketing platform user account through which the purchase is made. The ticket will be accessible only through the user terminal 1 that is accessing the user account at the time of ticket rendering, i.e. the user terminal on which the user has completed the access authentication method according to any of the above described arrangements. In this regard, it should be appreciated that the user may access their account and associated tickets from any user terminal that facilitates completion of the access authentication method. For example, in the event a user's smartphone runs out of battery or breaks, they may use a friend's mobile phone to access their ticket and gain access to an event. Various scenarios and possibilities will be readily appreciated by those skilled in the art. It is commonplace for tickets to be bought in multiples by the same person. For example, someone might be buying two tickets for themselves and their partner, tickets might be bought by one person for a group of friends, or corporate bodies might buy groups of tickets for their employees. Additionally, touts currently buy multiple tickets with the express purpose of reselling them. This latter scenario is one of the key things that a ticketing system incorporating the access authentication method may be used to reduce. In order to allow genuine purchasers (i.e. not touts) to continue to buy multiple tickets, a Friends & Family feature may be implemented, which may work as follows:

1 . A user creates a ticketing platform account and invites other ticketing platform account holders to be members of their Friends & Family list. Data corresponding to the Friends & Family list will be held in association with the user account on the ticketing platform database. 2. The number of Friends & Family members that a user can have will be limited. The number of Friends & Family members may be limited to a

predetermined number. It may be limited to 5 or less, for example. The

predetermined number may be limited to an initial number that can change depending on how the account is conducted. For example, if a user maintains continuous membership of the ticketing platform and there is no suspicious activity on their account, they may earn the right to have more Friends & Family members. Various other possibilities exist, as will be appreciated by those skilled in the art.

3. The user buys multiple tickets through a ticket agency. All of the tickets are sent to the user's ticketing platform account.

4. The user may (and in some cases must) transfer the spare tickets to members of the user's Friends & Family. This transfer will only be allowed to Friends & Family members that have been added to the user's list prior to the ticket purchase.

5. Although the tickets have been transferred to Friends & Family, the tickets preferably remain under the control of the original user, such that the original user can recall the tickets at any time. Also preferably, a Friends & Family member who receives a ticket that has been transferred in this way cannot transfer the ticket to anyone else.

6. The ticketing system may require each ticket to be transferred to someone before it can be used. This is to counteract the scenario where a tout buys multiple tickets and simply attends the event themselves at the same time as the people that he/she has sold the tickets to. If the tickets must be transferred, then each of the tickets will require individual biometric verification of the ticket holder in the manner described herein. This is unlikely to be possible if the Friends & Family relationship had to be established before the tickets were first purchased because the tout is unlikely to have known the purchasers in advance and therefore had them on their Friends & Family list.

There are a number of reasons that the implementation of this Friends & Family functionality may be desirable, including the following: 1 . When a ticket is transferred to a Friends & Family member, it provides the ticketing platform owner with information about who the user of the ticket is, which is not available to the primary seller of the ticket. 2. It allows genuine ticket holders, who for legitimate reasons can no longer attend an event, to transfer the ticket to someone else that they know so that the ticket does not go unused and a refund does not have to be claimed. This replicates the genuine non-touting use case that exists today with tickets. Figures 6 and 7 show, respectively, a secondary ticket listing process and a secondary ticket resale process.

Since any ticket for resale is provided with a unique ticket identifier and may only be rendered for use by the user of the user account with which the ticket is inextricably linked by that user validating their presence at a user terminal 1 at the time of rendering the ticket, the resale of tickets may be strictly controlled. The resale of tickets may moreover be prevented, if desired. It is notable that in addition to preventing touting, as detailed above, this provides certainty over who possesses any tickets sold to an event, even when they have been resold. This is valuable since it allows the collation of precise data regarding the attendees of large scale events.

Each ticket is preferably provided with a data marker indicating whether resale is permitted. In this case, when any ticket is listed for re-sale there may be a check

implemented to ensure that ticket resale is permitted. The re-listing of a ticket may occur through a third party website. In which case, that third party website will have a server 5 that links to the ticketing platform server 2 in the manner shown in Figure 1 .

During a resale process, as shown in Figure 7, there will be introduced a further ticketing locking step, which following account authentication, and an optional human interaction verification step, will lock a ticket until completion of the resale process and the transfer to the new user account. Such a step will ensure the safe transfer of the ticket from one user account to another. Once the ticket is resold it will be inextricably linked to the new user account and it will only be possible for the user of that account to render the ticket by validating their presence at a user terminal 1 at the time of rendering the ticket.

Numerous modifications to the arrangements disclosed herein will be possible within the scope of the claims that follow.