U.S. patent application number 14/726315 was filed with the patent office on 2016-12-01 for systems and methods for electronic ticket management.
The applicant listed for this patent is Yoti Ltd. Invention is credited to Duncan FRANCIS, Eleanor Simone Frederika LOUGHLIN-MCHUGH, Roman Edward SZCZESNIAK.
Application Number | 20160350547 14/726315 |
Document ID | / |
Family ID | 57397081 |
Filed Date | 2016-12-01 |
United States Patent
Application |
20160350547 |
Kind Code |
A1 |
LOUGHLIN-MCHUGH; Eleanor Simone
Frederika ; et al. |
December 1, 2016 |
SYSTEMS AND METHODS FOR ELECTRONIC TICKET MANAGEMENT
Abstract
A computer system according to certain aspects uses past ticket
usage data indicating a probability that a respective entity would
personally use a ticket issued to them based on a history of past
ticket usage. A ticket controller can respond to ticket requests by
determining whether a ticket should be issued to a requesting
entity based on the past ticket usage data associated with the
requesting entity's profile, and if so issue a ticket to the
requesting entity in electronic form. The system can receive a
ticket use notification and update the past ticket usage data
associated with the requesting entity's profile based on the ticket
use notification, where the updated past ticket usage data conveys
whether the requesting entity presented the ticket themselves.
Inventors: |
LOUGHLIN-MCHUGH; Eleanor Simone
Frederika; (London, GB) ; SZCZESNIAK; Roman
Edward; (London, GB) ; FRANCIS; Duncan;
(London, GB) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Yoti Ltd |
London |
|
GB |
|
|
Family ID: |
57397081 |
Appl. No.: |
14/726315 |
Filed: |
May 29, 2015 |
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
G06F 21/6218 20130101;
G06Q 30/06 20130101; G06Q 20/3274 20130101; G06Q 20/385 20130101;
G06Q 20/38215 20130101; G06Q 20/045 20130101; H04L 9/3242 20130101;
G06Q 2220/00 20130101; G07B 15/00 20130101; G06F 21/31 20130101;
H04L 67/306 20130101; G06Q 20/3827 20130101; G06Q 10/02
20130101 |
International
Class: |
G06F 21/62 20060101
G06F021/62; H04L 29/08 20060101 H04L029/08 |
Claims
1. A computer system, comprising: a data store holding: a plurality
of profiles, each of a respective entity and stored in association
with past ticket usage data indicating a probability that the
respective entity would personally use a ticket issued to them
based on a history of past ticket usage; a computer interface
configured to receive a ticket request from a requesting device via
a computer network, the ticket request identifying a profile of a
requesting entity; one or more processors configured to execute
code for managing tickets, the code configured when executed to
implement: a ticket controller configured to: in response to the
ticket request, determine whether a ticket should be issued to the
requesting entity based on the past ticket usage data associated
with the requesting entity's profile, and if so issue a ticket to
the requesting entity in electronic form via the network, a
receiving module configured to receive a ticket use notification
from a validating device via the network, the ticket use
notification indicating: identity data of the requesting entity and
identity data of a presenting entity that has presented the issued
ticket to the validating device, and a profile manager configured
to: update the past ticket usage data associated with the
requesting entity's profile based on the ticket use notification,
wherein the updated past ticket usage data conveys whether the
requesting entity presented the ticket themselves.
2. The computer system according to claim 1, wherein the updated
past ticket usage data indicates the identity data of the
requesting and presenting entities, and the one or more processors
is configured to use the updated past ticket usage data to compare
the identity data of the presenting entity with the identity data
of the requesting entity to detect whether they match, wherein the
ticket controller is configured to determine whether to reject a
future ticket request from the requesting entity based on said
comparison.
3. The computer system according to claim 1, wherein the identity
data of the requesting entity and the identity data of the
presenting entity are stored in the computer system and associated
with a ticket identifier of the ticket; and wherein the ticket use
notification comprises the ticket identifier and thereby indicates
the identity data of the requesting entity and the identity data of
the presenting entity.
4. The computer system according to claim 3, wherein the identity
data of the requesting entity forms part of the requesting entity's
profile.
5. The computer system according to claim 4, wherein the ticket
request comprises a credential bound to the requesting entity's
profile, and the one or more processors are configured to implement
a validation service for validating credentials, wherein the ticket
is issued only if the credential is valid.
6. The computer system according to claim 1, wherein the identity
data of the requesting entity and the identity data of the
presenting entity comprise a hash of at least part of a payment
account number issued to the requesting entity and a hash of at
least part of a payment account number issued to the presenting
entity respectively.
7. The computer system according to claim 1, wherein the identity
data of the requesting entity and the identity data of the
presenting entity each comprise a string unique to that entity.
8. The computer system according to claim 7, wherein the unique
string of the presenting entity is received from the validating
device in the ticket use notification, having been presented to the
validating device with the ticket by the presenting entity.
9. The computer system according to claim 1, configured to
associate a profile identifying a true owner of the ticket with the
ticket identifier, wherein an identifier of the true owner is
transmitted to and outputted by the validating device in response
to the ticket being presented to the validating device, and the
updating of the past ticket data is conditional on a user of the
validating device indicating via the validating device that the
presenting entity is the true owner.
10. The computer system according to claim 9, wherein the profile
of the true owner is associated with the ticket identifier in
response to receiving a change of ownership notification
identifying the ticket and the true owner.
11. The computer system according to claim 8, wherein the profile
of the true owner is the profile of the requesting entity.
12. The computer system according to claim 1, wherein the computer
system comprises an asset tracking system, and the identity data of
at least one of the entities forms part of a profile of the ticket
in the asset tracking system, the ticket use notification
identifying the profile of the ticket.
13. The computer system according to claim 1, wherein the computer
system comprises an asset tracking system, wherein a profile of the
ticket in the asset tracking system comprises a link to the
identity data of at least one of the entities, the ticket use
notification identifying the profile of the ticket and the link
being used to retrieve the identity data of the at least one
entity.
14. The computer system according to claim 4, wherein the one or
more processors are configured to implement an association module
configured, in response to the ticket request, to create an
association in the data store between the requesting entity's
profile and a ticket identifier of the issued ticket, and wherein
and the ticket use notification comprises the ticket identifier and
thereby indicates the identity data of the requesting entity; and
wherein the profile manager is configured to use the ticket
identifier received in the ticket use notification to retrieve the
identity data of the requesting entity for said comparison based on
the association created by the association module.
15. The computer system according to claim 2, wherein said
comparison is performed in response to receiving the future ticket
request.
16. The computer system according to claim 1, wherein the ticket
use notification indicates the identity data of the presenting
entity by identifying a profile of the presenting entity that
comprises that identity data
17. The computer system according to claim 1, wherein the ticket
use notification comprises the identity data of the presenting
entity and thereby indicates it.
18. The computer system according to claim 1, wherein the ticket
use notification comprises the identity data of the requesting
entity and thereby indicates it.
19. A method implemented by a computer system comprising a data
store holding a plurality of profiles, each of a respective entity
and stored in association with past ticket usage data indicating a
probability that the respective entity would personally use a
ticket issued to them based on a history of past ticket usage, the
method comprising: receiving a ticket request from a requesting
device via a computer network, the ticket request identifying a
profile of a requesting entity; in response to the ticket request,
determining whether a ticket should be issued to the requesting
entity based on the past ticket usage data associated with the
requesting entity's profile, and if so issue a ticket to the
requesting entity in electronic form via the network; receiving a
ticket use notification from a validating device via the network,
the ticket use notification indicating: identity data of the
requesting entity and identity data of a presenting entity that has
presented the issued ticket to the validating device; and updating
the past ticket usage data associated with the requesting entity's
profile based on the ticket use notification, wherein the updated
past ticket usage data conveys whether the requesting entity
presented the ticket themselves.
20. A computer system for detecting ticket touting, comprising: a
ticket issuer configured to selectively issue tickets to ticket
requesting entities; electronic storage holding, for each of
multiple issued tickets, an initial profile of that ticket in
association with a ticket identifier of that ticket; a computer
interface configured to receive ticket transfer notifications, each
ticket transfer notification identifying a respective one of the
issued tickets and a respective entity participating in a transfer
of the respective ticket; a profile manager configured to, each
time a ticket transfer notification is received, create in the
electronic storage a new ticket profile of the respective ticket
comprising an identifier of the respective participating entity; an
association module configured to, each time a new ticket profile is
created, associate the new ticket profile with the next most recent
profile of the same ticket, thereby creating multiple temporal
sequences in the electronic storage, each representing a chain of
transfer of one of the tickets; and an analyser configured to
analyse the temporal sequences to detect when an entity identified
in at least some of the temporal sequences satisfies a touting
condition, wherein the ticket issuer is configured to determine
whether to reject a ticket request received from that entity based
on said detection.
21. A method of detecting ticket touting, comprising: creating in
electronic storage, for each of multiple issued tickets, an initial
profile of that ticket in association with a ticket identifier of
that ticket; receiving ticket transfer notifications, each ticket
transfer notification identifying a respective one of the issued
tickets and a respective entity participating in a transfer of the
respective ticket; each time a ticket transfer notification is
received, creating in the electronic storage a new ticket profile
of the respective ticket comprising an identifier of the respective
participating entity; each time a new ticket profile is created,
associating the new ticket profile with the next most recent
profile of the same ticket, thereby creating multiple temporal
sequences in the electronic storage, each representing a chain of
transfer of one of the tickets; and analyzing the temporal
sequences to detect when an entity identified in at least some of
the temporal sequences satisfies a touting condition, and
determining whether to reject a ticket request received from that
entity based on said detection.
22. A computer program product comprising computer readable
instructions stored on a non-transitory computer readable storage
medium and which, when executed, configured to implement a method
comprising: receiving a ticket request from a requesting device via
a computer network, the ticket request identifying a profile of a
requesting entity; in response to the ticket request, determining
whether a ticket should be issued to the requesting entity based on
past ticket usage data associated with the requesting entity's
profile, and if so issue a ticket to the requesting entity in
electronic form via the network; receiving a ticket use
notification from a validating device via the network, the ticket
use notification indicating: identity data of the requesting entity
and identity data of a presenting entity that has presented the
issued ticket to the validating device; and updating the past
ticket usage data associated with the requesting entity's profile
based on the ticket use notification, wherein the updated past
ticket usage data conveys whether the requesting entity presented
the ticket themselves.
23. (canceled)
Description
INCORPORATION BY REFERENCE TO RELATED APPLICATIONS
[0001] This application relates to the following U.S. patent
applications the complete disclosures of which are incorporated
herein by reference in their entirety.
TABLE-US-00001 Application No. Title Date Filed ##/###,###
ELECTRONIC SYSTEMS AND May 29, 2015 METHODS FOR ASSET TRACKING
14/622,527 DIGITAL IDENTITY Feb. 13, 2015 14/622,737 DIGITAL
IDENTITY Feb. 13, 2015 14/622,709 DIGITAL IDENTITY SYSTEM Feb. 13,
2015 14/622,549 CONFIDENCE VALUES Feb. 13, 2015 14/622,740
AUTHENTICATION OF WEB Feb. 13, 2015 CONTENT
BACKGROUND
[0002] Field
[0003] The described technology is in the field of
computer-implemented data management.
[0004] Description of the Related Art
[0005] Historically, tickets to events would be issued in person,
for example at the venue of an event either beforehand or "on the
door" at the time of the event itself. However, nowadays, ticket
management is moving more and more into the digital domain, whereby
tickets are requested and issued via the Internet. Whilst this is
generally beneficial for users in terms of convenience, it
nevertheless comes with its own set of problems.
[0006] Where tickets are made freely available without restriction,
soon touts will follow. Ticket touting is the practice of an entity
(tout) acquiring a potentially large number of tickets to, say, an
event which they have no intention of using personally, i.e. where
they have no intention of attending the event themselves,
particularly for the purpose of selling them on at a premium.
Whilst popular, oversubscribed events in particular have always
been somewhat vulnerable to touting, historically the
inter-personal nature of ticket purchases kept touting in check to
some extent.
[0007] However the problem of touting is being exacerbated as
ticket management moves more and more towards Internet based
systems. Not only is this removing the inter-personal aspect of
ticket acquisition, but a specific problem that has arisen as
ticket management becomes digitized is the ever-increasing presence
of "bots". A bot is a software-implemented artificial intelligence
deployed on a computer network such as the Internet, in this case
acting as a tout i.e. programmed with a function of acquiring a
potentially large number of tickets en masse as soon as they become
available on the Internet, often in a very short space of time so
as to deprive legitimate (i.e. non-touting) users.
[0008] A problem also exists regarding ticket allocation and
identification. Sometimes a ticket seller or broker will mandate
that a ticket purchaser has to show up at the venue with some form
of identification (e.g. payment card) to prove that the person
showing up is the original purchaser of the tickets, or a
legitimate re-purchaser who has re-purchased the ticket(s) via the
broker's own system. However, in practice the time and effort this
involves, and the delays it would result in, means that this is not
enforced in practice. In other words, existing mechanisms for
linking identity to tickets are unworkable in practice. This is
particularly, though not exclusively true of physical tickets.
SUMMARY OF CERTAIN INVENTIVE ASPECTS
[0009] A problem solved by the described technology is one of
constructing an automated ticketing system that is robust to
touting but does not place undue restrictions on legitimate (i.e.
non-touting) users and requires minimal manual oversight.
[0010] A first aspect of the described technology is directed to an
automated ticketing computer system that implements a robust,
automated anti-touting mechanism. The mechanism detects touting
behaviour by entities, such as humans or possibly artificial
intelligence entities, within the system, based on historical
ticket usage, and can where necessary automatically inhibit future
ticket acquisitions for detected touting entities, without human
intervention being necessary to achieve this. The inhibition
mechanisms are targeted on detected touts, so as not to restrict
legitimate movement of tickets within the system unnecessarily. The
touting detection is made possible by linking digital identity to
tickets, so that each ticket has a clearly assigned owner within
the system.
[0011] In accordance with the first aspect a computer system
comprises: a data store holding: a plurality of profiles, each of a
respective entity and stored in association with past ticket usage
data indicating a probability that the respective entity would
personally use a ticket issued to them based on a history of past
ticket usage; a computer interface configured to receive a ticket
request from a requesting device via a computer network, the ticket
request identifying a profile of a requesting entity; one or more
processors configured to execute code for managing tickets, the
code configured when executed to implement: a ticket controller
configured to: in response to the ticket request, determine whether
a ticket should be issued to the requesting entity based on the
past ticket usage data associated with the requesting entity's
profile, and if so issue a ticket to the requesting entity in
electronic form via the network, a receiving module configured to
receive a ticket use notification from a validating device via the
network, the ticket use notification indicating: identity data of
the requesting entity and identity data of a presenting entity that
has presented the issued ticket to the validating device, and a
profile manager configured to: update the past ticket usage data
associated with the requesting entity's profile based on the ticket
use notification, wherein the updated past ticket usage data
conveys whether the requesting entity presented the ticket
themselves.
[0012] Both the issuing and the use of the ticket are tied to the
requesting entity's profile. The requesting entity may for example
be a purchaser of the ticket, purchasing it via the network (e.g.
Internet). "Ticket use" in this context means presenting the ticket
to the validating device, which is e.g. available to an event
organizer, to gain admission to a ticketed event.
[0013] By tying ticket issuing and use to the requesting entity's
profile in this manner, it is possible to detect when the
requesting entity is obtaining ticket(s) to an event, but not using
any of those ticket(s) themselves. This is indicative of touting
behaviour and where a profile is used to buy tickets for many
events but never (or hardly ever) used to gain admission to those
events, it can be concluded that that profile is of a touting
entity with a high level of statistical certainty. Conversely, it
is possible to detect when the same entity is both acquiring a
ticket (or a set of multiple tickets) and also using that ticket
(or one of that set of tickets) to gain admission to that event.
This is indicative of legitimate (i.e. non-touting) behaviour, and
where a profile is used to both to buy tickets for and gain
admission to multiple events, it can be concluded that that profile
is of a legitimate (i.e. non-touting) entity.
[0014] Tying the tickets to profiles also makes it harder for bots
to even gain access to tickets in the first place, particularly if
the profiles are tied to an official identity document such as a
passport.
[0015] In certain embodiments, no limits are placed on the number
of tickets that can be issued to a legitimate entity at all, nor
(in some cases) are any limits places on the transfer of tickets
between legitimate entities, so that only the activities of
identified touting entities are curtailed. In other embodiments,
some restrictions may still be placed on legitimate users, e.g. on
the number of tickets a legitimate user can purchase to ensure a
fair distribution of tickets across all legitimate users, though
generally these will be less stringent than those placed on
identified touting entities.
[0016] The past ticket usage data in a profile of an entity may for
example be in the form of a value pair (Nu, Na) or a ratio Nu/Na or
other metric function m(Na,Nu) of NA and Nu. Here Na represents the
number times that profile has been used to acquire tickets (for
example by acquiring them directly from a ticket issuer or
indirectly from another entity(s) e.g. through a re-sale), and Nu
represents the number times that that profile has been used both to
acquire tickets and to gain admission to the corresponding events
i.e. the number of times the entity has actually shown up at events
they have bought tickets to. For legitimate users, Nu will equal or
be close to Na i.e. a ratio close to 1; for touting entities, such
as human touts or touting bots, Nu will be equal or close to zero
i.e. a ratio close to 0. In some cases, the ratio may be biased
initially to give entities the benefit of the doubt e.g. Na and Nu
may be initialized as, say, Na=Nu=50 to lessen the effect of the
entity's first actions on the ratio. Alternatively, Na may
represent the number of times the entity has bought tickets but not
shown up, so that for legitimate users Nu is equal or close to
zero, and for touts it is equal or close to Na. Alternatively the
past ticket usage data may, for example, convey the probability
indirectly--e.g. it may comprise, for each event for which that
profile was used to buy tickets, a respective flag indicating
whether or not that profile was also used to gain admission to that
event.
[0017] When the profile manager detects that the identity data of
the presenting entity does match that of the requesting entity
(indicating the presenting entity and the requesting entity are the
same person i.e. the requesting entity is a person who has shown up
at the event), the past ticket usage data may be updated so that
the probability indicated thereby increases. Conversely, where the
profile manager detects that the identity data of the presenting
entity does not match that of the requesting entity (indicating
that the requesting entity has not shown up at the event), the past
ticket usage data may be updated so that the probability indicated
thereby is decreased.
[0018] A key aspect is that identify is being validated at the same
time as the ticket, in a non-intrusive and practicable way. The
identity of the person presenting the ticket is validated by the
system as well as validating the ticket itself, and checked against
the identity of the original ticket purchaser. This is in contrast
to, say, scanning a barcode on a conventional electronic or paper
ticket, as this only validates the ticket itself and not the person
presenting it.
[0019] Note, where an entity acquires a set of multiple tickets for
a single event, the probability that the entity would personally
use a ticket issued to them means the probability of the user using
any one of the tickets in the set (giving the remainder e.g. to
friends or family).
[0020] In embodiments, the updated past ticket usage data may
indicate the identity data of the requesting and presenting
entities, and the processor(s) may be configured to use the updated
past ticket usage data to compare the identity data of the
presenting entity with the identity data of the requesting entity
to detect whether they match. The ticket controller may be
configured to determine whether to reject a future ticket request
from the requesting entity based on said comparison. For example
said comparison may be performed in response to receiving the
future ticket request.
[0021] The identity data of the requesting entity and the identity
data of the presenting entity may be stored in the computer system
and associated with a ticket identifier of the ticket, and the
ticket use notification may comprise the ticket identifier and
thereby indicates the identity data of the requesting entity and
the identity data of the presenting entity.
[0022] For example the identity data of the requesting entity may
form part of the requesting entity's profile. E.g. the ticket
request may comprise a credential bound to the requesting entity's
profile, and the processor(s) may be configured to implement a
validation service for validating credentials, and the ticket may
be issued only if the credential is valid.
[0023] The identity data of the requesting entity and the identity
data of the presenting entity may comprise a hash of at least part
of a payment account number issued to the requesting entity and a
hash of at least part of a payment account number issued to the
presenting entity respectively.
[0024] Alternatively or additionally the identity data of the
requesting entity and the identity data of the presenting entity
may each comprise a string unique to that entity. For example, the
unique string of the presenting entity may be received from the
validating device in the ticket use notification, having been
presented to the validating device with the ticket by the
presenting entity.
[0025] The computer system may be configured to associate a profile
identifying a true owner of the ticket with the ticket identifier.
An identifier of the true owner may be transmitted to and outputted
by the validating device in response to the ticket being presented
to the validating device, and the updating of the past ticket usage
data may be conditional on a user of the validating device
indicating via the validating device that the presenting entity is
the true owner. For example, the profile of the true owner may be
associated with the ticket identifier in response to receiving a
change of ownership notification identifying the ticket and the
true owner. Alternatively, the profile of the true owner may be the
profile of the requesting entity.
[0026] The computer system may comprise an asset tracking system,
and the identity data of at least one of the entities may form part
of a profile of the ticket in the asset tracking system of, the
ticket use notification identifying the profile of the ticket.
[0027] The computer system may comprise an asset tracking system,
and a profile of the ticket in the asset tracking system may
comprise a link to the identity data of at least one of the
entities, the ticket use notification identifying the profile of
the ticket and the link being used to retrieve the identity data of
the at least one entity.
[0028] The processor(s) may be configured to implement an
association module configured, in response to the ticket request,
to create an association in the data store between the requesting
entity's profile and a ticket identifier of the issued ticket. The
ticket use notification may comprise the ticket identifier and
thereby indicate the identity data of the requesting entity. The
profile manager may be configured to use the ticket identifier
received in the ticket use notification to retrieve the identity
data of the requesting entity for said comparison based on the
association created by the association module.
[0029] The ticket use notification may indicate the identity data
of the presenting entity by identifying a profile of the presenting
entity that comprises that identity data. Alternatively or in
addition, the ticket use notification may comprise the identity
data of the presenting entity and thereby indicates it.
[0030] The ticket use notification may comprise the identity data
of the requesting entity and thereby indicates it.
[0031] A second aspect is directed to a method implemented by a
computer system comprising a data store holding a plurality of
profiles, each of a respective entity and stored in association
with past ticket usage data indicating a probability that the
respective entity would personally use a ticket issued to them
based on a history of past ticket usage, the method comprising:
receiving a ticket request from a requesting device via a computer
network, the ticket request identifying a profile of a requesting
entity; in response to the ticket request, determining whether a
ticket should be issued to the requesting entity based on the past
ticket usage data associated with the requesting entity's profile,
and if so issue a ticket to the requesting entity in electronic
form via the network; receiving a ticket use notification from a
validating device via the network, the ticket use notification
indicating: identity data of the requesting entity and identity
data of a presenting entity that has presented the issued ticket to
the validating device; and updating the past ticket usage data
associated with the requesting entity's profile based on the ticket
use notification, wherein the updated past ticket usage data
conveys whether the requesting entity presented the ticket
themselves.
[0032] A third aspect is directed to a computer system for
detecting ticket touting comprising: a ticket issuer configured to
selectively issue tickets to ticket requesting entities; electronic
storage holding, for each of multiple issued tickets, an initial
profile of that ticket in association with a ticket identifier of
that ticket; a computer interface configured to receive ticket
transfer notifications, each ticket transfer notification
identifying a respective one of the issued tickets and a respective
entity participating in a transfer of the respective ticket; a
profile manager configured to, each time a ticket transfer
notification is received, create in the electronic storage a new
ticket profile of the respective ticket comprising an identifier of
the respective participating entity; an association module
configured to, each time a new ticket profile is created, associate
the new ticket profile with the next most recent profile of the
same ticket, thereby creating multiple temporal sequences in the
electronic storage, each representing a chain of transfer of one of
the tickets; and an analyser configured to analyse the temporal
sequences to detect when an entity identified in at least some of
the temporal sequences satisfies a touting condition, wherein the
ticket issuer is configured to determine whether to reject a ticket
request received from that entity based on said detection.
[0033] A fourth aspect is directed to a method of detecting ticket
touting comprising: creating in electronic storage, for each of
multiple issued tickets, an initial profile of that ticket in
association with a ticket identifier of that ticket; receiving
ticket transfer notifications, each ticket transfer notification
identifying a respective one of the issued tickets and a respective
entity participating in a transfer of the respective ticket; each
time a ticket transfer notification is received, creating in the
electronic storage a new ticket profile of the respective ticket
comprising an identifier of the respective participating entity;
each time a new ticket profile is created, associating the new
ticket profile with the next most recent profile of the same
ticket, thereby creating multiple temporal sequences in the
electronic storage, each representing a chain of transfer of one of
the tickets; and analyzing the temporal sequences to detect when an
entity identified in at least some of the temporal sequences
satisfies a touting condition, and determining whether to reject a
ticket request received from that entity based on said
detection.
[0034] In another aspect, a computer system comprises: a data store
holding a plurality of profiles, each of a respective entity and
comprising past ticket usage data indicating a probability that the
respective entity would personally use a ticket issued to them
based on a history of past ticket usage; a computer interface
configured to receive a ticket request from a requesting device via
a computer network, the ticket request identifying a profile of a
requesting entity; one or more processors configured to execute
code for managing tickets, the code configured when executed to
implement: a ticket controller configured to: in response to the
ticket request, determine whether a ticket should be issued to the
requesting entity based on the past ticket usage data of the
requesting entity's profile, and if so issue a ticket to the
requesting entity in electronic form via the network, a receiving
module configured to receive a ticket use notification from a
validating device via the network, the ticket use notification
indicating: identity data of the requesting entity and identity
data of a presenting entity that has presented the issued ticket to
the validating device, and a profile manager configured to: compare
the identity data of the presenting entity with the identity data
of the requesting entity to detect whether they match, and update
the past ticket usage data in the requesting entity's profile based
on said detection.
[0035] A fifth aspect is directed to a computer program product
comprising code stored on a computer readable storage medium and
configured when executed to implement any method or system
functionality disclosed herein.
BRIEF DESCRIPTION OF THE DRAWINGS
[0036] For a better understanding of the described technology and
to show how the same may be carried into effect, reference is made
by way of example only to the following figures in which:
[0037] FIG. 1 shows a block diagram of a computer system for
tracking an asset;
[0038] FIG. 2 shows functional modules of an asset tracking system
interacting to create a set of initial profiles of an asset;
[0039] FIG. 3 shows functional modules of an asset tracking system
interacting to create a new profile of an asset in response to a
change of ownership;
[0040] FIG. 4 illustrates a use case of a temporal sequence of
profiles of a ticket;
[0041] FIG. 4A shows an asset tracking system and digital identity
system responding to the same asset transfer;
[0042] FIG. 4B shows a relationship between profiles of an asset
and profiles in a digital identity system;
[0043] FIG. 5A shows a ticket purchase transaction;
[0044] FIG. 5B shows a ticket being used by someone who originally
purchased it;
[0045] FIG. 5C shows a ticket being transferred to another
user;
[0046] FIG. 5D shows a ticket being used by someone who did not
originally purchase it;
[0047] FIG. 6 shows a preferred mechanism by which a legitimate
ticket holder can use their ticket.
DETAILED DESCRIPTION OF CERTAIN INVENTIVE EMBODIMENTS
[0048] FIG. 1 shows a computer system 1 for tracking an asset. In
the following example the asset is a ticket. Tickets are not
normally handles as assets in conventional asset tracking systems.
To date they have not been considered an asset to be tracked. One
important benefit of the described technology is to provide a
system which has universal application to multiple types of
entities that can change their status with time.
[0049] The computer system 1 comprises at least one processor 2
executing asset tracking code 4, electronic storage 6 accessible to
the processor 4, and at least one network interface 8 via which the
processor 2 is connected to a network 10 such as the Internet. For
example the computer system 1 may be formed of a set of one or more
interconnected server devices, each configured to run at least a
respective part of the code 4.
[0050] Also shown connected to the network 10 are first and second
user devices 14i, 14ii of, i.e. accessible to and operated by,
first and second users 12i, 12ii respectively, referred to as Bob
12i and Alice 12ii respectively. The user devices 14i, 14ii are
computer devices, for example smart devices (e.g. smartphones,
tablet computers etc.), laptop or desktop computers, wearable
computer devices etc. Each of the user devices 14i, 14ii can
communicate with the computer system 1 via the network 10.
[0051] FIGS. 2, 3 and 4 between them show the following functional
modules, each representing functionality implemented by executing a
respective portion of the asset tracking code 4 on the processor 2:
a profile manager 22, an association module 23 a label generation
module (labeler) 24, a ticket generation module 28, and an analyser
29. As explained in further detail below, the profile manager 22,
association module 23 and labeler 24 interact with one another to
create and manage a set P of profiles of an asset in the electronic
storage 6. The profiles of the set P are all profiles of the same
asset, and represent ownership of the asset at various stages of
the asset's lifetime. The functional modules 22-26 and set of
profiles P constitute an asset tracking system 20 implemented by
the computer system 1.
[0052] By way of example, an asset in the form of a ticket to an
event--such as a concert, gig, music or other festival--is
considered in the following.
[0053] FIG. 2 illustrates steps of an initial asset purchase
transaction, in which the ticket is initially purchased by the
first user 12i from a seller of the ticket such as an event
organizer. The transaction is mediated by a broker computer system
19 operated by a broker. The seller may for example be a company or
an individual; the same is true of the broker.
[0054] The first user 12i has a payment card number, sometimes
referred to as a payment account number (PAN), that has been issued
to them by a bank or other card issuer. The first user's payment
card number is denoted PANi. The payment card number PANi is
unique, and can be used by the user to effect a transfer of funds
to or from a monetary account against which the payment card has
been issued, such as a debit account or credit account.
[0055] The first user's card number PANi together with their face
form the basis of an identity of the first user 12i within the
system. As explained below, a user's face can be incorporated by
way of an image captured with a camera etc.
[0056] For example, the Applicant's co-pending U.S. patent
application Ser. Nos. 14/622,527, 14/622,709, 14/622,549,
14/622,737, 14/622,740--incorporated herein by reference--describe
a digital identity system, in which a user can, for example, create
a profile of their digital identity (referred to therein as a
"uPass") based on an identity document, such as a passport, and a
self-captured image of their face ("selfie"). Various user profiles
are referred to hereinbelow, which may in embodiments be uPass
profiles.
[0057] At step S2 the first user 12i uses their device 14i to
instigate an electronic ticket request message to the broker system
19 via the network 10. The request 30 indicates the following to
the broker system 19: an event identifier eID of the event for
which they are attempting to secure a least one ticket, an
authentication code ACi of the first user 12i, and a visual image
of the first user's face Si ("selfie"), e.g. as captured with a
camera of their device 14i. For example, the request 30 may
comprise one or more of these elements and/or it may comprise a
link(s) to one or more of these elements i.e. data identifying a
memory location at which one or more of these elements are held and
from which they may be retrieved by the broker system 19. E.g. the
link may be a URI.
[0058] As an particular example, the request 30 may comprise a link
to a profile of the first user 12i (e.g. a link to a published
version of a uPass profile) that constitutes a digital identity of
the first user 12i, and this profile may include a selfie Si
previously captured by the first user 12i e.g. when they created or
updated the profile. For example, the profile could be a Google,
Facebook or other such profile. This saves the first user 12i the
inconvenience of having to capture the selfie when sending the
ticket request. In some cases, the request 30 may comprise a
credential(s), such as a one-time pad, bound to the profile, and
the relevant information may only be retrievable from the profile
if the credential(s) is valid.
[0059] The authentication code ACi of the first user 12i is a
keyed-hash message authentication code (HMAC). A HMAC is computed
based on both a cryptographic hash function and a cryptographic
key, and when applied properly can be used both to integrity
protect data, i.e. to enable an check as to whether the data has
been altered, and to authenticate the data, e.g. to demonstrate
that an originator of the data is who he, she or it claims to be,
the originator being the first user 12i in this example. A HMAC is
defined in RFC 2140 "HMAC: Keyed-Hashing for Message
Authentication" as:
HMAC(K,d)=H([KXORopad].parallel.H([KXORipad].parallel.d)) (1)
in which K is a cryptographic key; d is the data to which the HMAC
is being applied; H is a cryptographic hash function; XOR means the
logical operation of bitwise exclusive-OR; and S1.parallel.S2 means
a concatenation of strings S1 and S2. In equation (1), opad and
ipad are outer and inner padding bits, defined in RFC 2014 as B
repetitions of the bytes 0x5c and 0x36 respectively where H is
configured to operate on data blocks of length B bytes, e.g. B=64
(though in general other set(s) of zero of more padding bits can be
used).
[0060] The authentication code ACi of the first user 12i is
generated as ACi=HMAC(K1, PANi) i.e. by applying the HMAC function
to the user's back card number PANi (or at least to a value derived
therefrom) with key K1. This operation is irreversible in the sense
that it is, in practical terms, impossible to ascertain the user's
card number PANi from the authentication code ACi alone. The key K1
can be provided by the user 12i, or generated by the system on
their behalf and provided to them. Either way, it is a shared
shared between the user 12i and the asset tracking system 20. A
different key K1 may be uniquely generated each time it is
needed.
[0061] To provide additional security, a seed may be added e.g. so
that ACi=HMAC(K1, PANi.parallel.seed).
[0062] The authentication code ACi of the first user 12i
constitutes an identifier of the first user, as does their face
image data as captured in the selfie Si.
[0063] The authentication code ACi of the first user 12i is used
within the system to identify the first user 12i. This does not
carry any security risk as, although the authentication code ACi is
derived from the first user's back card number PANi, the latter
cannot be derived from the former. Moreover, because every payment
card number is unique, when authentication codes are generated in
the same way for other user's they are guaranteed to be unique.
[0064] Note that, to this extent, the first user's card number PANi
is not being used to access the monetary account against which it
has been issued--rather, to this extent, its uniqueness is simply
exploited to generate a unique identifier that is tied to the first
user 12i. The card number PANi can be used in this way even if the
ticket which the first user 12i is attempting to secure is
free.
[0065] Conversely, the authentication code ACi cannot be used to
access the first user's monetary account against which the card
number PANi is issued. Thus in the case that payment is required
for the ticket, the necessary payment card details 30b must also be
included in the request 30 in a form suitable for whatever purchase
mechanism is being used to transfer the appropriate funds to the
broker in the conventional manner.
[0066] It is not essential for the authentication code ACi to be
generated at the first user device 12i, though it is preferable
from a security perspective.
[0067] At step S4, in response to the request 30, the broker system
19 instigates a ticket query to the asset tracking system 20, to
query whether the first user's request 12i can be accommodated. For
example, where the first user 12i has requested a number of tickets
(one or more), the broker system 19 may query whether that number
of tickets is available. Step S4 may be conditional on one or more
criteria assessed by the broker system 19; for example, the broker
system 19 may refuse the request if more than a maximum permitted
number of tickets is requested. In response to the query, the asset
tracking system 20 instigates (S6) a ticket identifier (ID) request
to the ticket generation module 28. The ticket ID request
identifies the event, for example by comprising the event
identifier eID, and requests one or more tickets to the event as
appropriate.
[0068] Assuming the request can be accommodated, e.g. as may be the
case if the event has not yet reached capacity, the ticket
generation module responds (S8) to the ticket ID request from the
asset tracking system 20 with a unique ticket identifier tID for
each requested ticket. A respective profile sequence is created in
the tracking system 20 for each ticket identifier. In the following
example, it is assumed that only one ticket is requested; where
multiple tickets are requested, the relevant steps can performed
for each requested ticket as will be apparent.
[0069] The ticket ID may for example be generated as a combination
(e.g. concatenation or convolution) of a vendor identifier and a
randomized sequence, for example a random number in a fixed field.
The ticket number is unique and may be large, e.g. it may be a
GUID, CSPRNG etc. It may be a prime number (or the randomized
sequence may be prime). Alternatively, it may be entirely
randomized.
[0070] Note where a ticket identifier is used as a device ID (see
below), it is the randomised part that is used alone and not the
vendor ID part.
[0071] The ticket identifier tID is supplied to the profile manager
22, and in response the profile manager 22 instigates the creation
of the set of profiles P in the electronic storage.
[0072] When first created, the set P is made up of three initial
profiles of the asset: an initial sale profile p(0,0), an initial
asset brokering profile p(1,0), an initial purchase profile p(2,0).
Each initial profile is associated with the ticket identifier tID
in the storage 6.
[0073] The initial sale profile p(0,0) records the initial sale of
the asset by the seller. It comprises an identifier of the seller
(e.g. event organizer) and metadata, such as a location of the
seller, time of the transfer, device metadata (e.g. device ID) of a
device used by the seller to conduct the sale. For example, the
profile p(0,0) may comprise a link to a profile of the seller
themselves, that includes details of the seller, e.g. company
details or details of an individual seller as applicable.
[0074] The broker profile p(1,0) records the fact that the initial
sale has been brokered by a third party (the broker). It comprises
an identifier of the broker and metadata, such as a location of the
broker, time of the transfer, device metadata (e.g. device ID) of
the device of the broker system 19 that brokers the sale. For
example, the profile p(1,0) may comprise a link to a profile of the
broker, akin to that of the seller.
[0075] The initial purchase profile p(2,0) comprises an identifier
IDi of the first user 12i, and thereby identifies the first user
12i as the first purchaser of the ticket. The profile p(2,0) also
comprises metadata, such as a location of the purchaser, time of
the transfer, metadata (e.g. device ID) if the purchaser's device
14i.
[0076] The identifier IDi of the first user 12i comprises at least
one of: [0077] the authentication code ACi of the first user 12i;
[0078] the first user's selfie Si, or a link to the selfie Si;
[0079] a link to identity data of the first user 12i stored
elsewhere, such as a link to a profile of the first user 12i (e.g.
a link to a published version of a uPass profile of the first user
12i, published as part of a uPass transaction in which the ticket
is purchased). Preferably it comprises both the authentication code
ACi of the first user 12i, and the selfie Si or a link to the
selfie Si.
[0080] The labeler 24 also generates a respective label L(0,0),
L(1,0), L(2,0) for each of the profiles p(0,0), p(1,0), p(2,0). The
labels L(0,0), L(1,0), L(2,0) are also HMACs, and may for example
be generated by applying the HMAC function of equation (1) to data
of the profiles p(0,0), p(1,0) and p(2,0) respectively. Once
generated, each label L(0,0), L(1,0), L(2,0) is attached to (i.e.
associated with in the storage 6) its respective profile p(0,0),
p(1,0), p(2,0).
[0081] At step S11, an answer message 32 is returned to the broker
system 19 from the asset tracking system 20. The answer message 32
comprises the ticket identifier tID and the authentication code ACi
of the first user 12i, thereby indicating that a ticket identified
by the ticket identifier tID has been issued to that user.
[0082] At step S12, a ticket 31 is transmitted to their device 14i
via the network 10 in electronic form. The ticket 31 may comprise
the ticket identifier tID. Alternatively, the first user may not be
granted direct access to the ticket identifier tID--in this case, a
separate identifier may be used as a proxy for the ticket
identifier tID instead proxy ID). For example, the first user's
authentication code ACi may be used as a proxy for the ticket
identifier.
[0083] Where a proxy ID is used, a mapping 19a between the proxy ID
(e.g. ACi) and the ticket identifier tID is stored at the broker
system 19. All access to the ticketing system 20 may be mediated by
the broker in this case.
[0084] FIG. 3 illustrates steps of recording a transfer of the
ticket from the first user 12i to the second user 12ii.
[0085] At step S22 a ticket transfer notification 32 is received by
the profile manager 22. The ticket transfer notification 32
comprises or otherwise indicates: the ticket identifier tID, and an
identifier IDii of the second user 12ii.
[0086] The identifier IDii of the second user comprises at least
one of: [0087] an authentication code ACii of the second user 12ii,
generated from a card number PANii of the second user 12ii in the
same manner as the authentication code ACi of the first user 12i,
but using their own key K1'; [0088] a selfie Sii of the second user
12ii, or link to the selfie Sii; [0089] a link to identity data
e.g. a profile of the second user 12ii. Preferably it comprises
both the authentication code ACii and the selfie Sii or a link to
the selfie Sii.
[0090] The ticket transfer notification 32 also comprises
identifiers of the seller, in this case Bob 12i, and a broker of
the sale (which may be the same broker or a different broker, e.g.
Bob himself or even Alice).
[0091] The ticket transfer notification 34 may for example be
instigated by the first user 12i from their device 14i, or from the
second user 12ii from their device 14ii with the permission of the
first user 12i, for example as part of a uPass transaction. In
either case, the transfer may be mediated by the broker system 19
as indicated in FIG. 3. When used, the mapping 19a stored at the
broker system 19 may be updated to change the proxy ID e.g. to the
authentication code ACii of the second user 12ii instead.
Alternatively, as shown in FIG. 3, the mapping 19a may not be
updated and the first authentication code ACi may continue to be
used as the proxy ID. This provides an additional way of linking
the initial purchase of the ticket from the original seller back to
the first user 12i.
[0092] In response to the notification 34, the profile manager 22
creates three new profiles p(0,1), p(1,1), p(2,1) of the ticket.
The profile p(0,1) is a new seller profile and comprises the
identifier of the seller IDi (Bob in this example). The profile
p(1,1) is a new broker profile and comprises the identifier of the
broker. The new profile p(2,1) is anew seller profile and comprises
the identifier IDii of the second user 12ii, and thereby identifies
the second user 12ii as a new owner of the ticket.
[0093] The association module 23 associates each of the new
profiles p(t,1)--t=0,1,2--representing the three types of
profile--of the ticket with the corresponding initial purchase
profile p(1,0) of the ticket, so that three ordered sequences (in
the mathematical sense) of profiles (p(t,0),p(t,1)) are created
with p(t,1) as the most recent purchaser profile in the relevant
sequence at this point in time.
[0094] Each profile p(t,1) comprises the same type of metadata as
the corresponding initial profile p(t,0), e.g. location/time of the
transfer to which it relates, device metadata of device used in the
transfer etc.
[0095] To do this, the association module 23 generates association
data in the storage 6. For example, the label L(t,1) or other
identifier of profile p(t,1) may be mapped to, i.e. associated with
in the storage 6, the label L(t,0) or other identifier of profile
p(t,0). As will be appreciated, this is just an example any
suitable data structure can be used to associate the profiles
p(t,1), p(t,0) so that they constitute an ordered sequence.
[0096] The labeler generates a labels L(t,1) for each of the new
profiles p(t,1), which is attached to that new profile p(t,1).
[0097] More generally, each time such a ticket transfer
notification, identifying the ticket and a new owner thereof, thee
new profiles p(t,n) are created. The new profile p(t,n) is
associated with the next most recent profile p(t,n-1) of the same
type i.e. the new seller (t=2) profile with the next most recent
seller profile etc.
[0098] A label L(t,n) for the new profile p(t,n) is created.
Preferably the label L(t,n) is a HMAC of data of both the new
profile p(t,n) and the profile p(t,n-1) with which it is
associated. For example:
L(t,n):=HMAC(K2p(t,rt).parallel.L(t,n-1)) (2)
wherein the label L(t,n-1) of the profile p(t,n-1) is used to seed
content of the profile p(t,n) before hashing. Equation to applies
to all n>1. Once generated, the label L(t,n) is then attached to
the profile p(t,n).
[0099] The labels L(t,0) are L(t,0):=HMAC(K2,p(t,0)).
[0100] To provide additional security, a different key K2(l,n) may
be used for each new profile p(l,n).
[0101] The sequence S is constitutes a micro-database specific to
one particular ticket. A separate micro-database in maintained in
this manner for every ticket that is issued (and more generally
every asset that is tracked by the system 20).
[0102] An access module (not shown) implemented by the code 4
provides access to the sequence S. At least where a proxy ID is
used, the access is mediated by the broker system 19.
[0103] In particular, the access module can, upon request, identify
the current owner of the ticket to an entity requesting this
information. The current owner is the one identified in the most
recent profile in the sequence S.
[0104] Software executing on a user device may be configured to
render the ticket identifier (or a proxy identifier) as a barcode,
for example a matrix barcode e.g. QR code, on display of the
device. A user of the user device can then present the barcode at
the event itself to gain admission to the event, for example to a
member of door staff. The ticket identifier is sent to the access
module from a device operated by the door staff. The access module
returns an identifier of the current owner--preferably a selfie
from the most recent profile in the sequence S--to that device, so
the door staff can check whether the user presenting the ticket is
indeed the current legitimate owner of the ticket. The fact that
the owner has actually shown up may be recorded in attendance data
of the most recent profile of the sequence so that thereafter the
last profile in the sequence not only identifies the last owner of
the ticket but also records the fact that they did turn up to the
event themselves. For example, this may be in response to the event
owner sending an electronic message to the system 20 (e.g. via the
broker system 19) from their device that the person who has turned
up does indeed match the returned selfie and has thus been
permitted to enter.
[0105] The last profile in each sequence is denoted p(t,N) below
and in FIG. 4, the final sequence being (p(t,0), . . .
,p(t,N)).
[0106] As indicated, in some embodiments, at least some of the
profiles p(t,n) in each sequence may include a transfer time,
indicating a time at which the asset was transferred as part of the
profile metadata (see above). For example, a time at which the
profile p(t,n), or the preceding/following profile
p(t,n-1)/p(t,n+1), was created or a transfer time extracted from
the relevant transfer notification 34.
[0107] FIG. 4 illustrates how an analysis may be performed based on
one or more temporal sequences of ticket profiles P by the analyzer
29 of the asset tracking system 20. For the purpose of analysis,
the analyzer 29 has access to at least one temporal sequence of
profiles of a ticket 31, though preferably it has access to
multiple temporal profile sequences of different tickets, and most
preferably it has access to all three profile sequences (seller,
broker, purchaser) for multiple tickets. The analyser 29 is
configured to analyze the sequence(s) to which it has access.
[0108] The various hashing mechanisms described above provide a
level of integrity protection for each chain of ownership that
afford it a high level of confidence, thereby significantly
strengthening any analysis of which they form a basis.
[0109] Tracking the full ownership history of each tickets in this
manner across its entire lifetime also enables undesirable activity
to be detected within the system. For example, to detect ticket
touting. Ticket touting is the practice of acquiring a potentially
large number of tickets that the tout has no intention of using
personally, but is selling on usually at a premium. Increasingly, a
tout may not be a user at all but may be a "bot". A bot is a
software-implemented artificial intelligence deployed on a computer
network such as the Internet, in this case acting as a tout i.e.
programmed with a function of acquiring a potentially large number
of tickets en masse as soon as they become available on the
Internet, often in a very short space of time so as to deprive
legitimate (i.e. non-touting) users.
[0110] To this end, an analysis of multiple profile chains may be
performed by the analyzer 29 to detect an identifier of an owner
that appears in multiple ones of the analyzed chains in a manner
that satisfies a touting condition, indicating that the identified
owner is likely to be a tout.
[0111] In this respect, the following observations have been made
by the inventors: [0112] 1. Touts at best use a small number of
tickets they buy, and are far more likely to transfer them on;
[0113] 2. Touts rarely use tickets themselves [0114] 3. Legitimate
(non-touting) users may also transfer tickets on, e.g. give or sell
them to friends--but they will generally only do so to a small
group of people closely related to them, whereas touts will
generally sell to much larger groups of people to whom they have no
personal links; [0115] 4. Touts may prefer to use anonymous brokers
[0116] 5. Touts will but larger numbers of tickets than legitimate
users on average A touting detection algorithm can be configured to
factor in one or more of these. For example: [0117] 1. can be
factored in by looking for entities that appear in multiple
seller/purchaser sequences, but always transfer tickets on [0118]
2. can be factored in by looking at actual attendance data (see
below) [0119] 3. can be factored in by including a network
analysis, i.e. spotting touts based on the size of the network of
users in which their tickets are spread [0120] 4. can be factored
in by looking at the broker chains [0121] 5. can be factored in by
counting how many times the same entity appears across different
profile sequences
[0122] A particular advantage of maintaining three full profile
chains (seller, broker, purchaser) is that it provides a sufficient
depth of information for a suitably configured touting analysis
algorithm to reliably spot touting behaviour, as it indicates who
is selling to whom, and in what manner (the latter indicated by the
broker chain).
[0123] FIG. 4 also shows a digital identity system 40. Profiles
42i, 42ii of the first and second users 12i, 12ii in the digital
identity system 40 are shown, each profile 42i, 42ii comprising
that user's respective selfie Si, Sii, or a link to that user's
selfie Si, Sii. As indicated, an individual profile of a ticket may
identify an owner of the ticket by a link to the relevant profile
42i, 42ii in the digital identity system 40. A profile 42i, 42ii
may be specific to an event (or group of events e.g. related
events), so that there is one profile per user per event (or event
group); accords multiple events, the profiles for these events may
be grouped together into an event profile group. Alternatively, a
user may have a ticket buying profile 42i, 42ii, which the use to
purchase and record ownership of all of their tickets.
Alternatively the user could even have one profile 42i, 42ii per
ticket, though this is less preferred. Alternatively, though this
is also less preferred, the user could have one general purpose
profile 42i, 42ii that is not specific to events or tickets.
[0124] The profiles 42i, 42ii may be uPass anonymous profiles, i.e.
so that the only user identity data they contain is the selfie Si,
Sii (no name, address, date of birth etc.).
[0125] The digital identity system comprises its own profile
manager 43 for managing user profiles 42i, 42ii.
[0126] When the ticket identifier is first generated: [0127] within
the digital identity system 40 the profile manager 43 associates it
with the profile 42i of the initial processor; [0128] within the
asset tracking system, the three initial profiles p(0,0), p(0,1),
p(02,) are created.
[0129] When a transfer of the ticket takes place: [0130] within the
digital identity system, the profile manager 43 "moves" the ticket
identifier from the current owner's profile 42i to the new owner
profile 42ii, by disassociating it from the former and associating
it with the latter; [0131] within the asset tracking system 20,
three new profiles p(0,n+1), p(1,n+1) and p(2,n+1) are generated
and associated within p(0,n), p(1,n) and p(2,n) respectively to
create the seller, broker and purchaser chains respectively.
[0132] As shown in FIG. 4B, each of the asset profiles p(0,n),
p(1,n), p(2,n) relate to the same asset transfer, and may comprise
a link to a published versions 41v, 44v, 42v of a seller profile,
broker rpofile and purchaser profile in the digital identify system
40--see FIG. 4B. These published versions may be immutable, to as
to provide a snapshot of the identities expressed by the seller,
broker and purchaser within the digital identity system 40 at the
time the asset transfer took place.
[0133] Thus as multiple asset transfers take place, within the
asset tracking system the transfer chains get longer whereas the
asset moves about between profiles within the digital identity
system.
[0134] Interactions between the asset tracking system 20 and the
digital identity system 40 are via a bridge system 75, which is not
shown in FIG. 4 but is shown in FIG. 4A. FIG. 4A shows an
alternative view of some of the interactions of FIG. 4. The bridge
system 75 may be an event system, operated by on or behalf of the
event organizer or multiple event organizers, which includes the
ticket generator 19. The electronic storage accessible to the asset
tracking system 20 is denoted 6a and the electronic storage
accessible to the digital identify system is labelled 6b.
[0135] Note: within the digital identity system 40, the ticket
identifier tID may not be used directly--a proxy ID may be used
instead (similar to the proxy ID used by users 12i, 12ii--see
above). In this case, the bridge system 75 stores an association
"tID<->proxyID" between the proxy ID used in the digital
identity system 40 and the ticket identifier tID used in the asset
tracking system 20. For example, this may be particularly suitable
is the ticket identifier is not globally unique, as it can be
mapped to a globally unique proxy ID used in the digital identity
system 40. This is particularly appropriate where the proxy ID is
treated as a device identifier in the digital identity system 40
(see below).
[0136] It will be understood that all description material
pertaining to the ticket identifier tID in the context of the
digital identity system 40 applies equally to a proxy identifier
when that is used instead.
[0137] Alternatively the same ticket identifier tID may be used in
both systems 20, 40.
[0138] User profiles 42i, 42ii in the digital identity system 40
may be modified based on the analysis performed by the analyzer 29.
For example, a profile in the digital identity system 40 may be
associated with what is referred to herein as an anti-touting
metric, indicating a probability that the user is a tout, which may
be updated based on the results of a tout detection analysis by the
analyzer 29.
[0139] This anti-touting metric may, for example, be used at step
S4 and/or step S6 as described above, and the relevant method steps
may be conditional on the outcome.
[0140] For example, when the first user 12i requests a ticket at
step S2, the broker system 19 may have a link to the first user's
profile 42i provided by the user in the request 30. The broker
system 19 can request the anti-touting metric--"ATM" in the FIGS.
5A-5D--associated with the user's profile metric via an API, in
response to which a metric generator 76 of the digital identify
system generates it based on past ticket usage data "UD" e.g.
accessed from the profile sequences P in the asset tracking system
20. The broker system 19 may refuse the request if the anti-touting
metric indicates a high probability of the first user 12i being a
tout--for example, if it is above a threshold. The broker is free
to set the threshold wherever they (or the ticket seller) choose.
For example the broker may decide to impose stringent conditions
(i.e. a low probability threshold) for very popular events,
rejecting requests if there is even a small probability that the
request has originated with a tout. For unpopular events, the
broker may be more relaxed about or even completely tolerant of
touting--that is entirely their choice; the present mechanism
allows them to make an informed choice.
[0141] Alternatively, or in addition, an equivalent check of the
first user's anti-touting metric associated with their linked-to
profile 42i may be made by the ticket generator 28. In this case,
the issuance of the ticket identifier on an equivalent criteria set
by the ticket generator 28. The ticket generator 28 may be operated
by the seller rather than the broker, so that the seller is free to
set their own anti-touting criteria independently of the
broker.
[0142] The anti-touting metric may for example comprise a ratio
Nu/Na--or more generally a suitable function--of the total number
of tickets a user has bought Na (indicated by the initial purchaser
profile p(2,0) of the relevant sequences) to the total number of
events that have actually shown up at Nu (as indicated by
attendance data in the final profiles p(2,N) of the relevant
sequences. Alternatively or additionally, the metric may comprise
ratio of the number initial purchaser profiles p(2,0) that identify
the user to the number of final profiles p(2,N) that identify the
user across multiple sequences, if actual attendance is less of a
concern. The ratio of function may be biased in the user's favour
to begin with, so that they cannot be labelled as a tout
immediately. As a simple example, Nu and Na may have non-zero
values initially, e.g. they may be both set to 50 so that over time
the ratio becomes 51/51 (shows up) or 50/51 (doesn't show up) etc.
More generally, the system 1 is configured as a learning system,
which assumes that entities are not touts to being with and learns
from any touting behaviour they exhibit over time.
[0143] Alternatively or additionally, the metric may be based on,
say, an average or other indicative amount of time for which the
user retains tickets, based on the asset transfer times in the
profiles of the analyzed sequence(s).
[0144] Note: in this context the actions user 12i could equally
performed by a bot, and they system may even permit this to a
controlled extent. The analyzer 29 may be configured to detect
whether or not this is the case, i.e. whether an asset requesting
entity is a human or a bot. The bot may also have an identity, for
example a profile(s), within the digital identity system 40. The
analyser may insert information into this profile which flags the
profile as being of an entity that is a bot, rather than a
human.
[0145] Use of the asset tracking system 20 by an entity, such as
the first user 12i, 12ii, may be conditional on that entity setting
up a digital identity system 40. That is, use of the digital
identity system 40 may be mandated if a transfer is to be recorded
using the asset tracking system 20, such that a link to a profile
in the digital identity system 40 is required to do so.
[0146] Within the asset tracking system 20, the ticket 31 has an
identity in the sense that it has profiles of its own. In one
sense, the asset tracking system 20 can be regarded as a separate
digital identity system but for assets.
[0147] Within the digital identity system 40, the ticket may by
contrast be treated as a virtual device, with the ticket identifier
tID or another ticket identifier of the ticket 31 being treated as
a device identifier within the digital identity system 40.
[0148] The digital identity system 40 may, for example, be
implemented as a uPass system (see co-pending applications, above).
Indeed, in some cases, the asset tracking system 20 and the digital
identity system 40 may be implemented as separate and largely
independent uPass systems or identity spaces. In this case, within
the asset tracking identity space 20, the uPass "entities" are
assets. Within the uPass identity space 40, the uPass entities are
humans, e.g. users 12i, 12ii, bots etc., and assets are treated at
least to some extent as devices.
[0149] For a uPass system, links to profiles are in the form of
links to published versions of profiles. The terminology "a link to
a profile" encompasses a link to a published version of a uPass
profile, and does not have to be a direct link to the underlying
master profile from which it has been published.
[0150] Advantageously, the architecture of the uPass system 40 can
be readily adapted to provide a robust anti-touting mechanism that
requires little or no manual oversight, and does not curtail
legitimate activity by non-touting users unnecessarily.
[0151] This is in contrast to existing anti-touting methodologies
that are somewhat crude, and often end up curtailing what most
would perceive as reasonable activity by legitimate users, such as
purchases on behalf of, and a certain amount of re-selling to,
genuine friends and family. Moreover existing methodologies tend to
involve a significant level of manual oversight.
[0152] For example, one existing methodology involves restricting
the number of tickets that can be bought on any given credit or
debit card, and/or that can be dispatched to any given address
(e.g. email or postal). This tends to be enforced by a ticket
provider simply revoking tickets, after they have already been
issued, should those tickets later turn out to have been issued in
violation of these limits. This generally requires at least a
degree of manual oversight in ultimately deciding whether or not an
already-issued tickets should or should not be revoked. Moreover,
it can be unduly restrictive: for example, occasionally a user may
wish to buy tickets for a large group of genuine friends with whom
they wish to attend the event, which in some cases an event owner
may wish to permit. Additionally, for less popular events, such
restrictions may be unwanted: for example, an event may be
over-targeted by touts i.e. by touts buying up tickets for which
there is in fact limited demand so that they are never in fact able
to sell them on. This can lead to an event not only selling out,
depriving those who genuinely do wish to attend the event--but are
(justifiably) unwilling to buy a ticket from a tout--of the
opportunity to attend, but also being poorly attended due to the
touts' unsold tickets being essentially wasted. From the
perspective of a tout, this may amount to an acceptable loss in the
context of their wider activities, whereas for an event organizer
the effect can be detrimental both to the event itself in the short
term and their reputation in the long term.
[0153] Problems also arise if less than the expected number of
attendees turn up: significant revenues are generated from
attendance, car parking, bad drops, food, drinks, merchandise etc.
Moreover, ticket increase does not reach the owner or venue
either.
[0154] Another example of an existing methodology is deterring
touts by restricting or even forbidding the transfer of issued
tickets between entities. This has been enforced by, for example,
requiring ticket holder to present the card they used to purchase
their ticket(s) to gain admission to a ticketed event. Notionally,
this mandates at least the purchaser of a ticket or group of
tickets to attend the event in person. However this again relies on
manual oversight by those managing the event, and at a busy event
such checks will often end up being neglected. Thus, in practice a
warning that a purchasing card is required for admittance may
amount to little more than a hollow and ineffective threat.
Moreover, there can be legitimate reasons why an entity may
occasionally wish to transfer a ticket they have purchased, for
example where they purchased it with the intention of attending but
are prevented from doing so by unforeseen circumstances, or where
they have purchased it on behalf of a genuine friend who for
whatever reason was unable to purchase it themselves. Thus such
tout deterrents may be not only ineffective but also impose an
unnecessary burden on legitimate users. Moreover, even where ID is
mandated, this is rarely enforced in practice as discussed. Major
events e.g. the world cup state they require photo ID, passports
etc. to be brought to the venues but in reality they are not
checked due to the impact on processing speed. In contrast, the
digital profiles of the described technology provide a much more
viable identity check mentalism.
[0155] Embodiments provide a solution to the problem of tout
detection by tying both ticket purchase and ticket use to an
entity's digital identity within the uPass system 40 across
multiple events. In so doing, it becomes possible to track the
ticket-related activity of entities within the system, and in
particular to detect those entities who are frequently purchasing
tickets within the system but never or rarely showing up to the
events themselves.
[0156] Actions within a uPass system 40 can be effected by uPass
transactions, in which a validation service 14b validates the
appropriate uPass credentials.
[0157] In some implementations, the mechanism by which the ticket
31 is purchased by the first user 12i (referred to as "Bob" below)
is a uPass transition. This will now be described with reference to
FIG. 5A.
[0158] FIG. 5A shows Bob buying a ticket from the seller via the
broker system 19. To do this, Bob presents (S3a) a credential 52i,
that is bound to his uPass profile 42i, to the broker system 19.
For example the credential 52i may be part of the ticket request
30.
[0159] The broker system 19 receives the credential 52i. At this
point the broker does not know whether or not it is willing to sell
a ticket to Bob as it has not seen Bob's profile. Therefore the
broker system 19 sends (S3b) Bob's credential 52i, together with
its own credential 54 to the validation service 14b. The broker's
credential may also be bound to a uPass profile of the broker 44 in
the uPass system 40. Assuming the credentials 52i, 54 are valid,
the validation service 14b causes a first receipt 64 to be sent to
the broker system 19 (S3c). The first receipt 64 contains a link to
a published version of Bob's profile 42i.v1. In this scenario, the
ticket is issued only if the uPass credentials are valid.
[0160] Bob's profile 34B is associated with past ticket usage data
UD, indicating the extent to which he has used (rather than e.g.
sold on) in the past. This past ticket usage data comes from the
ticket profile sequences in the asset tracking system 20, which in
turn link to published versions of his profile 42i for transactions
he has participated in.
[0161] A comparison module (functional module) in the form of a
metric generator 76 is shown, which generates an anti-touting
metric ATM based on the past usage data UD. This is generated upon
request by the broker system 19 via an API of the system 40, and
the requested anti-touting metric ATM is supplied to the broker
system 19 via the API.
[0162] The metric generator 76 may be implemented in either of the
systems 20, 40, and may for example represent part of the
functionality of the analyzer 29 of FIG. 29.
[0163] Details of the anti-touting metric ATM will be described in
due course. Suffice it to say, in this example, the anti-touting
metric UD indicates a probability that Bob is not a tout i.e. a
probability that, if the broker were to issue a ticket or tickets
to Bob, Bob will actually use one of these tickets himself rather
than, say, selling them all on. In this example the probability
that Bob is not a tout is 80%, which is high enough for the broker
to accept Bob's request and issue him with the requested ticket(s).
Each ticket comprises a ticket identifier or proxy identifier of
the kind discussed above, labelled tID in the various figures.
[0164] In the following examples, the ticket identifier tID is
issued to Bob directly. As will be apparent, the same steps apply
when a proxy identifier is used instead, and in this case all
interactions with the asset tracking system are via the broker
system 19 which translates the proxy identifier to the ticket
identifier tID used within the asset tracking system 20.
[0165] A less preferred alternative is that Bob's profile 42i
contains the anti-touting metric UD.
[0166] Within the uPass system 40, the ticket identifier is then
associated (enrolled) with Bob's profile 42i in a manner that will
be described later. Once this association has been created, Bob (or
more accurately Bob's profile 42i) is effectively registered within
the uPass system 40 as the owner of the ticket. Note this is a
separate mechanism from that used to record ownership changes
within the asset tracking system 20.
[0167] In this example, the instigation of the ticket query at step
S4 from the broker system 19 to the asset tracking system 20 is
conditional on Bob's anti-touting metric ATM being determined by
the broker system 19 to meet anti-touting criteria set by the
broker.
[0168] Bob also gets a receipt 62i, and Bob and the seller each get
a fresh credential.
[0169] Note: the outcome of FIG. 5A could also be achieved by the
Broker system 19 presenting its credential 54 to Bob (e.g. as a QR
code which Bob scans with his device 14i), and Bob's device sending
the two credentials 52i, 54 to the validation service 14b.
[0170] FIG. 5B shows a situation where Bob actually turns up at the
ticketed event himself. To gain admission to the event, Bob
presents the ticket identifier tID to a validating device 46 being
operated e.g. by a member of event staff such as a door supervisor
(S26). In turn, the validating device transmits a ticket use
notification 72 to the asset tracking system 20. The notification
72 comprises the ticket identifier tID. In response, the door
supervisor is granted access to the most recent profile in the
sequence of profiles P of the ticket in the asset tracking space
20--the original purchaser profile p(2,0) in this example--and can
thus see who the current ticket owner is. In this example, the
current ticket owner is indeed Bob so the door supervisor should
allow him into the event.
[0171] Attendance data AD in the most recent profile p(2,0) is
updated to indicate that the ticket owner identified in the profile
p(2,0) has attended the event. In some cases, this may be
conditional on the door supervisor notifying the asset tracking
system 20 from their device 46 that is the true current owner of
the ticket that has actually shown up (S30). E.g. an automated
feedback mechanism may present them with a simple "yes/no"
selectable option on their device 46, so that the effort involved
in providing feedback is minimal.
[0172] An alternative to adding the attendance data to the profile
p(2,N) is adding attendance data to the sequence, in the form of a
terminating P(t,N+1) profile that is added to each of the t=0,1,2
chains to indicate that ticket has been used. These profiles
P(t,N+1) may transfer the ticket back to the original owner (i.e.
the event organizer). Both types of attendance data are examples of
past ticket usage data.
[0173] The metric generator 76 of the uPass system 40 detects
whether an original purchaser of a ticket to whom the ticket is
initially issued is the same person as a presenter of the issued
ticket i.e. a human entity who is presenting a ticket to an event
manager (e.g. a volunteer or member of event staff who is "on the
door" at the event venue) in an attempt to gain admission to the
event to which it relates. The presenter and the buyer may be the
same person, or the presenter may be a different person to whom the
ticket has been legitimately transferred.
[0174] The metric generator 76 uses the sequence of profiles P of
the ticket in the asset tracking system 20 to compare identity data
of the original ticket purchaser 12i (i.e. Bob) with corresponding
identity data of the ticket presenter (i.e. the person who has
actually shown up at the ticketed event, which may or may not be
Bob). The identity data may for example comprise HMACs of a card
number or part of a card number issued to the relevant entity. For
example, the metric generator 76 may detect whether identity data
of the initial purchaser as indicated by profile p(2,0) of the
ticket in the sequence P matches corresponding identity data of the
user indicated by attendance data AD in a profile of the sequence P
to have actually shown up at the event. Note "corresponding" means
the sets of identity data of the same type i.e. comparing
like-for-like.
[0175] Alternatively or additionally, the identity data may
comprise a unique string (e.g. numerical string, alphanumerical
string, bit string etc.) provided by or allocated to Bob, that
constitutes a shared secret. The unique string may be communicated
to the validating device 76 wirelessly, e.g. via an NFC link or as
a displayed barcode (e.g. QR) code, and transmitted from the
validating device to the system 20 and stored so that it is
accessible to the metric generator 76 when needed.
[0176] A profile p of the ticket in the asset tracking space may
indicate identity data of an entity because it comprises that
identity data, or because it comprises a link to a uPass profile of
that entity from which that identity data can be retrieved (for
example).
[0177] In the example of FIG. 5B, in response to Bob showing up
himself, the past ticket usage data in the ticket relevant ticket
profile(s) stored in the asset tracking system 20 is updated in a
manner that, thereafter, the metric generator generates a more
favourable metric ATM for Bob's.
[0178] By contrast, FIG. 5C shows an example situation in which Bob
sells or otherwise transfers his ticket to the second user 12ii
(referred to as "Alice" below). This can be also be achieved by a
uPass transaction.
[0179] Bob presents a credential 52i' to Alice's device 14ii (S21),
and Alice transmits Bob's credential 52i' along with her own
credential 52iia and the ticket identifier tID to the uPass system
40. Alternatively the signalling flow may be reversed i.e. Alice
presents her credential 52iia to Bob's device 14i, which transmits
it with Bob's credential and the ticket identifier tID to the uPass
system 40. Within the uPass system 40, the ticket identifier tID
becomes enrolled with Alice's profile 42ii in response. This is
entirely legitimate--the system allows for transfer of tickets, and
Alice is now recorded as the rightful owner of the ticket within
the uPass system 40. Alice and Bob each get a receipt linking to
the other's profile and a fresh credential.
[0180] Again, this is separate from the ownership tracking
mechanism of the asset tracking system 20.
[0181] To enable tracking within the asset tracking system 20, the
asset transfer notification 34 is sent from Alice to Bob's device
(possibly via the broker system 19) to the asset tracking system
20, where a new profile p(2,1) is added to the sequence of profiles
P of the ticket identifying Alice as the new owner in the manner
discussed.
[0182] FIG. 5D shows Alice using the ticket, which she now
rightfully owns, to gain admission to the event. From the
perspective of Alice and the door supervisor, the process proceeds
in exactly the same way as FIG. 5B, by Alice presenting the ticket
identifier to the door manager's device 52M (S28). Alice is
identified to the door supervisor based on p(2,1). Attendance data
is included in the most recent profile p(2,1) to indicate that the
owner identified by p(2,1)--in this case Alice--has actually
attended the event. The attended data in p(2,1) is associated with
Bob's profile 42i by virtue of the fact that p(2,0) in the same
sequence of profiles (and thus associated with the same ticket
identifier) links to a published version of Bob's profile 42i.
[0183] In this instance, thereafter, this causes the metric
generator 76 to detect `behind the scenes` that the person who has
shown up to the event (Alice) is not the entity who purchased the
ticket. Thus in future it will generate a metric ATM that is less
favourable to Bob on the basis that he is more likely to be a tout
because he has transferred his ticket to Alice and Alice has used
it.
[0184] Each time this happens, the past ticket usage data UD used
to generate Bob's anti-touting metric ATM will be updated
accordingly. If Bob frequently buys tickets but never uses them,
there may come a point where his anti-touting metric UD is so
unfavourable that sellers may choose not to sell to him in the
future, or may place restrictions on what tickets he can buy. Again
that is their choice--but the digital identity system provides a
means by which they can make informed choices.
[0185] The past ticket usage data UD thus indicates a probability
that the buyer would personally use a ticket issued to them based
on a history of past ticket usage.
[0186] The metric ATM may comprise e.g. a ratio of the number of
times the buyer has bought tickets to events to the number of times
the buyer has actually shown up at any of those events, shown as a
percentage in the figures by way of example. This is just an
example and the past ticket usage data US can take a number of
different forms, such as other functions of these numerical
measures.
[0187] A uPass profiles 42i, 42ii is published by storing a version
of it to addressable memory location. The link to that version of
the profile identifies that location.
[0188] The broker's receipt 64 comprises a link to the published
version of the buyer's (i.e. Bob's) profile. In turn, the published
version of Bob's profile comprises a current version of the
anti-touting metric UD, which the broker system 19 can access by
following the link. The broker system 19 can then decide whether to
issue ticket to the buyer based on the metric UD, for example based
on a threshold. This may be entirely automatic.
[0189] For instance, where the probability of the buyer being a
tout (as indicated by the metric UD) is below a threshold, the
ticket request may be approved by the broker system 19 whereas if
that probability is above the threshold it may be refused.
Alternatively, where the probability is above the threshold and a
plural number of tickets have been requested, the ticket issuer may
only permit a number of tickets that is less than the number
requested to be issued (e.g. only one ticket).
[0190] The behaviour of the broker system 19 can be agreed with the
organizer of an event, who is the ticket seller in this context.
Subject to any agreement with the seller, the broker is free to
program their system 19 as they see fit. For example, they are free
to set and vary the threshold, or to change how the controller
responds when the probability is above or below the threshold. This
gives the event organizer the freedom to, say, implement strict
anti-touting criteria (low threshold and/or strict refusal of
tickets to any entity identified as a tout) for a popular event,
but less stringent or even no ant-touting criteria for an unpopular
event.
[0191] If a ticket request is approved, the broker system 19 issues
a ticket (or however many tickets have been approved) to the
buyer's device 14i in electronic form e.g. via the internet. The
ticket comprises the ticket identifier (labelled tID in the
figures).
[0192] The ticket identifier is, in turn, associated with the
buyer's uPass profile 42i in the uPass system 40. This can be
achieved using the same enrolment mechanism used to enroll a new
device within the uPass system 40. The buyer's device 14i submits
the ticket identifier to an account service 45 of the uPass system,
in the same way it would a device identifier of a new device that
the buyer 12i wishes to enroll based on the existing enrolment of
their current device 12B. The account service 45 is implemented by
the uPass profile manager 43, though this is not shown explicitly.
Within the uPass system 40, the ticket is realized as a virtual
device hosted on the buyer's device 14i, with the ticket identifier
constituting a device identifier of the ticket virtual device.
Subject to successful enrolment, a credential is issued to the
ticket virtual device and sent to the buyer's (physical) device 14i
hosting the ticket virtual device. Within the digital identity
system, this credential is bound to both the buyer's profile 42i
and to the ticket virtual device in the manner discussed, and thus
this enrolment process acts to associate the buyer's profile 42i
with the ticket identifier. This is similar to creating virtual
devices on servers (see above). Where a proxy identifier is used,
it may be enrolled in place of the ticket identifier.
[0193] When a change of ticket ownership takes place, that is
recorded in the uPass system 40 (separately from the asset tracking
system 20) by disassociating the ticket identifier from the
previous owners profile 42i, and reenrolling it as a device bound
to the new purchaser's profile 42ii. In this manner, the new owner
is recorded as the now true owner of the ticket in the uPass system
40.
[0194] All description material pertaining to "device identifiers"
herein applies equally to ticket identifiers when enrolled in this
manner as virtual devices. For example, where a credential is bound
to (i.e. associated with, in the digital identity system) a profile
and a ticket identifier, and that credential is presented in a
uPass transaction, that transaction may only be permitted to
complete if the credential is both valid and presented with a
matching ticket identifier (just as is the case for credentials
bound to physical devices with physical device identifiers).
[0195] In this context, the account service 49 constitutes an
association module for associating ticket identifiers with uPass
profiles.
[0196] The ticket identifier may for example be associated, in a
database of the digital identity system, with a network address of
the buyer's physical device 14i hosting the ticket virtual device.
The uPass system 40, separately from the asset tracking system 20,
may record transfers of the ticket virtual device to a different
physical device by changing the network address associated with it
in the database, for example to a network address of Alice's device
12ii when the ticket is transferred from Bob to her.
[0197] The credential bound to the buyer's profile and the ticket
identifier may also be associated with the ticket identifier and
the buyer's profile in a database of the digital identity system,
for example by storing the credential or preferably the ingredients
for generating this credential in association with these two
elements in the database.
[0198] The buyer's receipt 62i comprises a link to the published
version of the broker's profile 44, so that the buyer can also
verify that the broker is legitimate. For example, the broker's
profile 44 may include an identifier (e.g. logo, trademark etc.) of
the ticket seller and/or broker and be allocated a high confidence
value, indicating that within the digital identity system there is
a high confidence that the seller is who they say they are. Final
purchase of the ticket may, in some cases, only proceed once the
user has been given the opportunity to review the seller's profile
and decide whether or not they do indeed wish to proceed based
thereon.
[0199] Once a ticket has been issued, the buyer is free at least to
some extent to pass it on to other entities registered with the
digital identity system, for example as a gift or re-sale. Some
restrictions may be placed on this, for example restricting the
re-sale price, though this is not in fact necessary--rather, the
focus of the present anti-touting mechanism is not on preventing
movement of issued tickets, but rather on monitoring this movement
over time and making a future decision about whether to issue
another ticket to the buyer in the future based on this monitoring.
This monitoring is recorded by updating the anti-touting metric in
the buyer's profile 42i.
[0200] When a legitimate ticket transfer takes place from the buyer
to a different entity, within the uPass system 40 this is recorded
by a uPass transaction, which in this case causes the ticket
identifier to be associated with a profile of the new entity
instead. For example, the ticket identifier may be re-enrolled as a
virtual device, this time as a device of the different entity using
the same enrolment mechanism.
[0201] FIG. 6 shows a preferred mechanism by which a ticket owner
12 (e.g. Alice or Bob) and use a ticket that is rightfully theirs.
In FIG. 6 the identity of the ticket owner is conveyed to the
validating device 46 from the uPass system 40, rather than the
asset tracking system 20. The user sends the ticket identifier tID
from their device 14 along with their uPass credential to the
validating device 46. The validating device, in turn, sends the
ticket identifier tID, the user's credential 52 and their own
credential in the ticket notification 72, which is sent to the
uPass system 40 in this example. The validation service 14b
validates the credentials 52, 54 and provided they are both valid
and provided the user's credential 52 is bound to the same profile
42 as the ticket identifier tID has been enrolled with, it causes a
version of the user's profile 42v2 to be published. A receipt is
sent to the validating device 46, which comprises a link to this
version 42v2 so that the door supervisor can see the identity data
(e.g. selfie) of the ticket owner, and compare it against the
person 12 standing in front of them. If, on the other hand, the
user's credential 56 were bound to a uPass profile which does not
match a uPass profile with which the ticket identifier is enrolled
(meaning that the user is not the true ticket owner), the system 40
can detect that the user is attempting to use the ticket
illegitimately. Moreover, if the door owner were to indicate to the
system 40 via their device 46 that the person 12 in front of them
does not match the selfie of the true owner supplied by the system
40, they can inform the system 40 via their device that an
illegitimate ticket use has been attempted. In either case, the
system 40 may be configured so that the ticket does not expire as a
result of an illegitimate attempted use.
[0202] The uPass system 40 communicates with the asset tracking
system 20 via the bridge system 75 to add the attendance data to
the records in the asset tracking system 20.
[0203] The asset tracking system will also record the user 12 as
the true owner of the ticket in the profile p(2,N) for the ticket.
This profile also links back to the uPass system 40, as it
comprises a link to an earlier published version of the user's
profile 42v1, published in the uPass transaction conducted to
transfer the ticket to the user 12.
[0204] To provide additional robustness, the identity of the ticket
owner could be verified using both the uPass profile and the ticket
profiles in the asset tracking system 20, or the asset profiles
could be used as a fall back.
[0205] Currently, tickets for different events tend to be managed
in a disjointed and disparate manner using different bespoke,
non-interoperable ticket management mechanisms, in a manner that
would make it difficult to detect touting behaviour across these
different systems.
[0206] In contrast, in embodiments of the described technology,
ticket management for many events can implemented using a common
uPass system 40 and/or a common asset tracking system 20.
Harmonizing ticket management in this manner provides a central
source of ticket usage data, and thus ensures that a wider base of
data is readily available which can be used to detect touting.
[0207] In some embodiments, identity data of the buyer's uPass
profile 42i in the uPass system 40 is located in the system using
the ticket identifier received in the ticket use notification, as
that identifier has been previously associated by that profile 42i
by enrolling the ticket identifier as a virtual device of the buyer
when they purchased it.
[0208] If the compared sets of identify data do indeed match i.e.
if it is determined that the presenter and the original buyer are
the same person, then the anti-touting metric ATM of the buyer
changes to reflect this, in this example by increasing the
percentage (because this constitutes one more event the buyer has
shown up to). This increases the chance of the buyer being able to
buy tickets to events in the future within the digital identity
system.
[0209] Conversely, if the compared sets of identity data do not
match, i.e. if it is determined that the presenter is different
from the purchaser, then in some (though not in all) cases the
anti-touting metric ATM changes to reflect this, in this example by
reducing the percentage. A scenario in which the metric ATM may not
be changed is where the purchaser has purchased two or more tickets
to the same event, kept one for him or herself and legitimately
given or sold the other(s) to a friend, as mentioned earlier.
Preferably a mechanism for distinguishing between touts and
legitimate owners is provided, so that those who sell to genuine
friends (for example) are not labelled as touts. This mechanism may
be provided by the analyzer 29, and be based on a network analysis,
in particular based on the size of a network of entities in which
tickets are spread as mentioned previously.
[0210] In some embodiments, touting behaviour may also be detecting
in those who do may obtain tickets directly from the broker 19, but
rather indirectly from other entities e.g. through gifts or
re-sales that are recorded in the sequence of profiles P.
[0211] This allows for the detection of entities who are linked to
touts, for example where a tout buys 6 tickets (if initially
permitted to do so) and associates 5 of those tickets with
"friends" but none of those friends attend the event. Instead the
tout or the "friend" always sells on/transfers on the ticket to a
fan--either via a reseller site, or via a real-world (e.g. pub or
outside event) handover. In some cases, the system may also target
those who buy from proven touts, and make it harder for them to
obtain tickets in the future, so as to further discourage the
practice of touting.
[0212] If unique individuals seem to exhibit low use/temporary
`ownership` behaviour despite not originally purchasing the ticket,
some event owners will want to ban such non fans (fans usually go
to the events if they get a ticket, even if they didn't buy the
ticket). That is, the system may favour those who actually turn up
at events regardless of how they obtained a ticket, and penalise
those who don't.
[0213] The anti-touting metric UD in already published versions of
the buyer's uPass profile 42i in the uPass system 40 may not
modified--in some cases only the underlying master profile 34B is
modified, which can of course effect future publications of that
uPass profile 42ii.
[0214] All of the various functional modules described above and
shown in the figures are implemented as code 4 executed on the
processor(s) 2.
[0215] A uPass implementation of the digital identity system 40 is
just one example. In other embodiments, the digital identity could
for example be implemented as a single sign-on system. As an
example, the digital identity system 40 could be Google+. Examples
of other suitable profile-based digital identity system
technologies that could be used include: Jumio; CallSign; MiiCard;
VerifyMe; Facebanx; Identity.com; ThislsMe and RealMe. In this
respect, products in this field include IDScan, Paycasso TrustID,
Au10tix, Idology, and IdChecker
[0216] Note a ticket is just one example of an asset that can be
tracked using the system 20 of the present disclosure, and all of
the disclosure pertaining to tickets applies more generally to any
other type of asset. Examples of assets include: [0217] hospital
beds, which can be tracked from (say) ward-to-ward, room-to-room,
hospital-to-hospital etc.; [0218] computers, photocopiers or other
equipment, tracked from office-to-office, building-to-building,
floor-to-floor, person-to-person, company-to-company etc. [0219]
patient records. For example separate profile chains may be
maintained for diagnosticians, patients, attending physicians etc.
e.g. to identify the entity that identifies a condition, the entity
that has the condition, and the entity that treats the condition.
In this case an asset transfer is a transfer of patient between
responsible entities; [0220] shares e.g. share certificates; [0221]
contracts. Note: hereinabove, a number of hash functions are
applied to concatenations S1.parallel.S2 of bit strings e.g.
H(S1.parallel.S2). More generally, a hash function can be applied
to any suitable function of the strings f(S1,S2) that retains
sufficient information unique to each string, e.g. H(f(S1,S2)).
[0222] In the following, the term "initial profile" can be any
profile in the chain with which at least one new profile is
subsequently associated, and in general is not limited to, say, the
first profile in a chain or the very first owner (though neither is
excluded).
[0223] Another aspect is directed to a computer system for tracking
assets comprising an asset tracking system, a digital identity
system and a computer interface. The asset tracking system
comprises electronic storage and a profile manager. The electronic
storage of the asset tracking system holds an initial profile of an
asset in association with an asset identifier of the asset. The
digital identity system comprises a profile manager and electronic
storage configured to hold profiles of entities. The computer
interface is configured to receive asset transfer notifications.
Each asset transfer notification identifies the asset and a
respective entity participating in a transfer of the asset. The
profile manager of the asset tracking system is configured to, each
time an asset transfer notification is received, create in the
electronic storage a new profile of the asset comprising an
identifier of the respective participating entity. The new profile
of the asset is stored in association with the asset
identifier.
[0224] Entities own assets are tracked within the digital identity
system, whilst the full history of the asset transfers is made
available in the asset tracking system. An entity's own asset may
for example be an asset they own, or which they otherwise hold,
have some responsibility for, or relationship to. Thus two
perspectives on the asset are provided: not only does an asset
transfer change the identity of the participant within the digital
identity system, it also changes the identity of the asset within
the asset tracking system. The two systems are linked, in that they
are responsive to the same asset transfers. Linking them in this
manner ensures the two perspectives they provide are consistent. A
participant in an asset transfer may for example be a new owner of
the asset (more generally an entity newly responsible for, newly
associated with the asset etc.), or a seller of the asset or broker
of a sale or other transfer of the asset.
[0225] In preferred embodiments, the asset tracking system also
comprises an association module configured to, each time a new
profile of the asset is created, associate the new profile with the
next most recent profile of the asset, thereby creating a temporal
sequence of profiles representing a chain of transfers of (e.g.
chain of ownership of) the asset. The temporal sequence is stored
in association with the asset identifier.
[0226] Existing methodologies are ill suited to tracking individual
assets reliably in multiple different contexts. For example, a
system well suited to dealing with asset locations may be poorly
equipped to manage multiple ownership changes or other multiple
transfers. By contrast, the temporal sequence of the described
technology held against the asset itself provides an accurate
record of the chain of transfers for the asset, and constitutes a
micro-database that is specific to the asset in question. A
separate micro-database of this kind can be maintained for every
individual asset tracked by the system.
[0227] Existing tracking methodologies also lack robustness to
accidental or nefarious record alteration. In preferred embodiments
of the described technology, one or more labels are assigned to
respective profiles of the temporal sequence based on cryptographic
hashing in a manner that provides robust integrity protection of
individual profiles and/or the structure of the sequence as a
whole. Among other things, the labels provide a mechanism by which
any alteration of the profiles or sequence is detectable.
[0228] The system may comprise a label generation module configured
to generate a label for each new profile in the sequence, that is
then associated with that new profile, by applying a hash function
to input data comprising: [0229] (i) data of that new profile,
and/or [0230] (ii) data of another profile (e.g. an earlier
profile, such as the next most recent profile) in the sequence. (i)
provides integrity protection of the content of that new profile,
whereas (ii) provides integrity protection of the sequence as a
whole. That is, when the labels are generated from (i) it will be
evident if the content of a profile has been altered (e.g. tampered
with or accidentally compromised) as it will no longer match its
own label; when generated from (ii), it will be evident if the
structure of the sequence has been altered as at least one of the
labels will no longer match the structure of the modified sequence:
for example, consider a sequence of profiles (p0, p1, . . . ,p(n),
. . . ). If a label L(n) of a later profile p(n) is generated by
hashing data of the next most recent profile p(n-1), if the
sequence is tampered with to remove or move the earlier profile
p(n-1), whichever profile ends up at position n-1 in the modified
sequence will no longer match the label L(n) of the later profile
p(n). More generally (though this is less preferred) this can be
achieved by hashing data p (n.+-.m) to generate L(n). If every link
in the sequence is covered (which can be achieved by setting m to
one of many appropriate values), then the entire structure of the
sequence will be protected.
[0231] Preferably the label L(n) is generated by hashing both data
of p(n) and data of p(n.+-.m) (preferably n.+-.m=n-1), as in this
case the label L(n) provides both types of integrity protection
simultaneously. In the described embodiments, the data of p(n.+-.m)
that is hashed is its own label L(n.+-.m).
[0232] It can be detected whether the data to which any label
relates has been altered for example by rehashing the data in the
same way and checking whether or not the result matches the
original label.
[0233] Preferably each label is also generated based on a secret
key. For example, the key may also be included in the input data
that is hashed to generate that label. This helps to prevent label
forgery. As an example, the labels may be HMACs.
[0234] Alternatively or in addition, data of the earlier profile
may be used as a seed input to the hash function, and the data of
that new profile is used as a content input to the hash function.
For example, the label generation module may be configured to
generate a label for the initial profile by applying a hash
function to at least data of the initial profile.
[0235] In this respect, another aspect is directed to a computer
system for tracking assets comprising: electronic storage holding
an initial profile of the asset in association with an asset
identifier of the asset; a computer interface configured to receive
asset transfer notifications, each asset transfer notification
identifying the asset and a respective participant in a transfer of
the asset; a profile manager configured to, each time an asset
transfer notification is received, create in the electronic storage
a new profile of the asset comprising an identifier of the
respective participant; an association module configured to, each
time a new profile of the asset is created, associate the new
profile with the next most recent profile of the asset, thereby
creating a temporal sequence of profiles representing a chain of
transfers of the asset; and a label generation module configured to
generate a label for at least one profile in the sequence by
hashing input data which comprises data of the at least one profile
and data of at least one other profile at a known position in the
sequence (e.g. n-1 where n represents the location of the at least
one profile, or more generally .+-.m), and store the label in
association with the at least one profile.
[0236] In embodiments of aspects, the profile manager of the
digital identity system may be configured to disassociate the asset
identifier from a profile of the previous participating entity in
the digital identify system when it creates the association in the
digital identity system.
[0237] The computer system may be configured to store an
association between the asset identifier and a first proxy asset
identifier; and the association between the asset identifier and
the profile of the respective participating entity in the digital
identity system may be created by storing the proxy asset
identifier in the electronic storage of the digital identity system
in association with the profile of the respective participating
entity.
[0238] Alternatively or in addition the computer system may be
configured to store an association between the asset identifier and
a second proxy asset identifier, each asset transfer notification
comprising the second proxy identifier and thereby identifying the
asset.
[0239] The asset tracking system may comprise an access module
configured to, in response to receiving an asset owner identity
request identifying the asset: generate an electronic response
message identifying a current owner of the asset based on the most
recent profile in the sequence and/or based on the profile of the
current owner in the digital identify system, and transmit the
response message to an instigator of the request.
[0240] For example, the response message may render available to
the instigator a visual image of the current owner.
[0241] The initial profile may comprise an identifier of an initial
owner of the asset.
[0242] At least one (e.g. some or all) of the profiles of the asset
may comprise an identifier of a participating entity which
comprises: a visual image of the participating entity, and/or a
link to stored identity data of the participating entity, and/or a
hash of at least part of a payment account number issued to the
participating entity.
[0243] For example the link in the at least one profile of the
asset may be a link to a version of the participating entity's
profile in the digital identity system. E.g. the digital identity
system may comprise a publication module configured to publish the
participating entity's profile by storing a copy of it to an
addressable memory location, the link in the at least one profile
of the asset being a link to the addressable memory location.
[0244] Multiple temporal sequences of profiles may be stored in the
electronic storage, each representing a chain of transfers (e.g.
ownership) of a different asset.
[0245] The computer system may comprise an analyser configured to
perform an analysis of the multiple sequences e.g. the assets may
be tickets to one or more events, and the analysis may be performed
to detect whether a touting condition is satisfied by at least one
identifier of an owner that appears in at least some of the
analyzed sequences.
[0246] Another aspect is directed to a computer-implemented method
of tracking assets comprising: creating an initial profile of an
asset in association with an asset identifier of the asset in
electronic storage of an asset tracking system; and receiving asset
transfer notifications, each asset transfer notification
identifying the asset and a respective entity participating in a
transfer of the asset, wherein each time an asset transfer
notification is received, the method comprises: at a digital
identity system: creating in electronic storage of the digital
identity system an association between the asset identifier and a
profile of the respective participating entity, at the asset
tracking system: creating in the electronic storage of the asset
tracking system a new profile of the asset comprising an identifier
of the respective new owner, the new profile of the asset stored in
association with the asset identifier.
[0247] Another aspect is directed to computer-implemented method of
tracking assets comprising: storing an initial profile of the asset
in association with an asset identifier of the asset in electronic
storage; and receiving asset transfer notifications, each asset
transfer notification identifying the asset and a respective
participant in a transfer of the asset, wherein each time an asset
transfer notification is received, the method comprises: creating
in the electronic storage a new profile of the asset comprising an
identifier of the respective participant, and associating the new
profile with the next most recent profile of the asset, thereby
creating a temporal sequence of profiles representing a chain of
transfers of the asset; wherein the method also comprises:
generating a label for at least one profile in the sequence by
hashing input data which comprises data of the at least one profile
and data of at least one other profile at a known position in the
sequence; and storing the label in association with the at least
one profile.
[0248] The methods may comprise steps to implement any of the
system features described herein.
[0249] As used herein, a phrase referring to "at least one of" a
list of items refers to any combination of those items, including
single members. As an example, "at least one of: a, b, or c" is
intended to cover: a, b, c, a-b, a-c, b-c, and a-b-c.
[0250] The various illustrative logics, logical blocks, modules,
circuits and algorithm steps described in connection with the
implementations disclosed herein may be implemented as electronic
hardware, computer software, or combinations of both. The
interchangeability of hardware and software has been described
generally, in terms of functionality, and illustrated in the
various illustrative components, blocks, modules, circuits and
steps described above. Whether such functionality is implemented in
hardware or software depends upon the particular application and
design constraints imposed on the overall system.
[0251] The hardware and data processing apparatus used to implement
the various illustrative logics, logical blocks, modules and
circuits described in connection with the aspects disclosed herein
may be implemented or performed with a single- or multi-chip
processor, a digital signal processor (DSP), an application
specific integrated circuit (ASIC), a field programmable gate array
(FPGA) or other programmable logic device, discrete gate or
transistor logic, discrete hardware components, or any combination
thereof designed to perform the functions described herein. A
processor may be a microprocessor, or, any processor, controller,
microcontroller, or state machine. A processor also may be
implemented as a combination of electronic devices, such as a
combination of a DSP and a microprocessor, a plurality of
microprocessors, one or more microprocessors in conjunction with a
DSP core, or any other such configuration. In some implementations,
particular steps and methods may be performed by circuitry that is
specific to a given function.
[0252] In one or more aspects, the functions described may be
implemented in hardware, digital electronic circuitry, computer
software, firmware, including the structures disclosed in this
specification and their structural equivalents thereof, or in any
combination thereof. Implementations of the subject matter
described in this specification also can be implemented as one or
more computer programs, e.g., one or more modules of computer
program instructions, encoded on a computer storage media for
execution by, or to control the operation of, data processing
apparatus.
[0253] If implemented in software, the functions may be stored on
or transmitted over as one or more instructions or code on a
computer-readable medium. The steps of a method or algorithm
disclosed herein may be implemented in a processor-executable
software module which may reside on a computer-readable medium.
Computer-readable media includes both computer storage media and
communication media including any medium that can be enabled to
transfer a computer program from one place to another. Storage
media may be any available media that may be accessed by a
computer. By way of example, and not limitation, such
computer-readable media may include RAM, ROM, EEPROM, CD-ROM or
other optical disk storage, magnetic disk storage or other magnetic
storage devices, or any other medium that may be used to store
desired program code in the form of instructions or data structures
and that may be accessed by a computer. Also, any connection can be
properly termed a computer-readable medium. Disk and disc, as used
herein, includes compact disc (CD), laser disc, optical disc,
digital versatile disc (DVD), floppy disk, and Blu-ray disc where
disks usually reproduce data magnetically, while discs reproduce
data optically with lasers. Combinations of the above also may be
included within the scope of computer-readable media. Additionally,
the operations of a method or algorithm may reside as one or any
combination or set of codes and instructions on a machine readable
medium and computer-readable medium, which may be incorporated into
a computer program product.
[0254] Various modifications to the implementations described in
this disclosure may be readily apparent to those skilled in the
art, and the generic principles defined herein may be applied to
other implementations without departing from the spirit or scope of
this disclosure. Thus, the claims are not intended to be limited to
the implementations shown herein, but are to be accorded the widest
scope consistent with this disclosure, the principles and the novel
features disclosed herein.
[0255] Certain features that are described in this specification in
the context of separate implementations also can be implemented in
combination in a single implementation. Conversely, various
features that are described in the context of a single
implementation also can be implemented in multiple implementations
separately or in any suitable subcombination. Moreover, although
features may be described above as acting in certain combinations
and even initially claimed as such, one or more features from a
claimed combination can in some cases be excised from the
combination, and the claimed combination may be directed to a
subcombination or variation of a subcombination.
[0256] Similarly, while operations are depicted in the drawings in
a particular order, a person having ordinary skill in the art will
readily recognize that such operations need not be performed in the
particular order shown or in sequential order, or that all
illustrated operations be performed, to achieve desirable results.
Further, the drawings may schematically depict one more example
processes in the form of a flow diagram. However, other operations
that are not depicted can be incorporated in the example processes
that are schematically illustrated. For example, one or more
additional operations can be performed before, after,
simultaneously, or between any of the illustrated operations. In
certain circumstances, multitasking and parallel processing may be
advantageous. Moreover, the separation of various system components
in the implementations described above should not be understood as
requiring such separation in all implementations, and it should be
understood that the described program components and systems can
generally be integrated together in a single software product or
packaged into multiple software products. Additionally, other
implementations are within the scope of the following claims. In
some cases, the actions recited in the claims can be performed in a
different order and still achieve desirable results.
[0257] Unless the context clearly requires otherwise, throughout
the description and the claims, the words "comprise," "comprising,"
and the like are to be construed in an inclusive sense, as opposed
to an exclusive or exhaustive sense; that is to say, in the sense
of "including, but not limited to." The word "coupled", as
generally used herein, refers to two or more elements that may be
either directly connected, or connected by way of one or more
intermediate elements. Likewise, the word "connected", as generally
used herein, refers to two or more elements that may be either
directly connected, or connected by way of one or more intermediate
elements. Additionally, the words "herein," "above," "below," and
words of similar import, when used in this application, shall refer
to this application as a whole and not to any particular portions
of this application. Where the context permits, words in the above
Detailed Description using the singular or plural number may also
include the plural or singular number respectively. The word "or"
in reference to a list of two or more items, that word covers all
of the following interpretations of the word: any of the items in
the list, all of the items in the list, and any combination of the
items in the list.
[0258] Moreover, conditional language used herein, such as, among
others, "can," "could," "might," "can," "e.g.," "for example,"
"such as" and the like, unless specifically stated otherwise, or
otherwise understood within the context as used, is generally
intended to convey that certain embodiments include, while other
embodiments do not include, certain features, elements and/or
states. Thus, such conditional language is not generally intended
to imply that features, elements and/or states are in any way
required for one or more embodiments or that one or more
embodiments necessarily include logic for deciding, with or without
author input or prompting, whether these features, elements and/or
states are included or are to be performed in any particular
embodiment.
[0259] The above detailed description of embodiments is not
intended to be exhaustive or to be limiting to the precise form
disclosed above. While specific embodiments and examples are
described above for illustrative purposes, various equivalent
modifications are possible within the scope of the inventions
described herein, as those skilled in the relevant art will
recognize. For example, while processes or blocks are presented in
a given order, alternative embodiments may perform routines having
steps, or employ systems having blocks, in a different order, and
some processes or blocks may be deleted, moved, added, subdivided,
combined, and/or modified. Each of these processes or blocks may be
implemented in a variety of different ways. Also, while processes
or blocks are at times shown as being performed in series, these
processes or blocks may instead be performed in parallel, or may be
performed at different times.
[0260] The teachings provided herein can be applied to other
systems, not only the systems described above. The elements and
acts of the various embodiments described above can be combined to
provide further embodiments.
[0261] While certain embodiments of the inventions have been
described, these embodiments have been presented by way of example
only, and are not intended to limit the scope of the disclosure.
Indeed, the novel methods and systems described herein may be
embodied in a variety of other forms; furthermore, various
omissions, substitutions and changes in the form of the methods and
systems described herein may be made without departing from the
spirit of the disclosure. The accompanying claims and their
equivalents are intended to cover such forms or modifications as
would fall within the scope and spirit of the disclosure.
[0262] Whilst the above has been described with reference to
specific embodiments, these are exemplary and other variations may
be apparent to the skilled person. The scope is not limited by the
described embodiments but only by the following claims.
* * * * *