Note : Les descriptions sont présentées dans la langue officielle dans laquelle elles ont été soumises.
CA 02495515 2005-02-04
WO 2004/015917 PCT/FI2003/000597
Method and arrangement for authenticating a commodity of value delivered as
a digital message
The invention concerns generally the technology of electronically delivering
rela-
tively short and compact messages that represent a commodity of value.
Especially
the invention concerns the problem of how to ensure that such a message, when
pre-
sented for inspection, is an authentic one and not an illegal copy.
Electronically delivering various tickets, discount coupons and corresponding
commodities of value in the form of SMS messages (Short Message Service), MMS
messages (Multimedia Message Service) and similar compact, well-defined messag-
ing formats is rapidly gaining popularity. As an example we may consider the
known way of ordering and delivering public transport tickets (such as tram or
bus
tickets) to the mobile telephones of individual users. In fig. 1 we assume
that the
user of a mobile telephone 101 wants to order an electronically deliverable
bus
ticket. The mobile telephone 101 has a wireless communication connection with
a
base transceiver station 102, from which there is a further connection to a
core net-
work 103 of which an SMSC (Short Message Service Center) 104 constitutes a
part.
A ticket application server 105 is arranged to have a communication connection
with the SMSC. Conveying an order message from the mobile telephone 101
through the base transceiver station 102 and the SMSC 104 to the ticket
application
server 105 is schematically represented in fig. 1 as a series of steps O, ~
and O.
After having received the order message the ticket application server 105
generates
an electronic ticket and sends it back to the mobile telephone that ordered
it. Con-
veying a ticket back to the mobile telephone 101 is shown as steps ~, O and ~.
Charging for the electronically delivered ticket is most straightforwardly
accom-
plished by adding a certain fixed price to the telephone bill of the user of
the mobile
telephone 101. However, after the user has received the ticket message into
his mo-
bile telephone, it is usually possible for him to forward a copy of the ticket
message
to another mobile telephone, like that of a friend who took the same bus. The
price
for just sending another SMS message is typically considerably lower than the
ticket price that was charged of the original recipient of the ticket message.
A temp-
tation quickly arises to cheat the system by ordering a single ticket for one
of a
group of persons and distributing copies of the original ticket as ordinary
SMS mes-
sages to the other members of the group.
CA 02495515 2005-02-04
WO 2004/015917 PCT/FI2003/000597
2
It is of principal importance for the arrangement of fig. 1 to be plausible
that it is
possible to verify the authenticity of a ticket message at the moment when it
is pre-
sented for inspection at the user's mobile telephone. A known way of providing
au-
thenticity is to rely on the correctness of the sender information that
constitutes a
part of the ticket message. During the process of conveying an SMS message to-
wards the mobile telephone of a user the network adds the telephone number of
the
sender to the message. An off-the-shelf mobile telephone does not include any
means for forging the sender information in a received SMS message, so an ille-
gally forwarded copy can be recognized by noting that its sender is not the
ticket
application server.
The reliability of checking the sender is undermined by certain mobile
telephone
models having a feature that was originally introduced in good faith in order
to en-
hance user-friendliness. The user of the mobile telephone can use a freely
selectable
alphanumeric string as the identifier of an entry in the directory of stored
names and
numbers. On the other hand said certain mobile telephone models check the
sender's number from a received SMS message, and if the number matches that of
a
named entry in the directory, they only display the "name" or identifier of
that entry
as the sender of the message. So if we assume that the telephone number of the
ticket application server is 123456 and Tom instructs his mobile telephone to
store
Eve's number as belonging to somebody named "123456", the following scheme
becomes possible: Eve orders and receives an electronic ticket and forwards an
ille-
gal copy of it to Tom. When Tom's mobile telephone is inspected, it contains a
re-
ceived SMS message, which the mobile telephone only displays as having been re-
ceived from "123456". In other words Tom's illegal copy that he received from
Eve
appears to be an authentic ticket message directly received from the ticket
applica-
tion server.
In general, various approaches are known for authenticating electronically
distrib-
uted messages. Their drawbacks regarding applicability to the above-described
problem usually involve complexity either in required hardware or in resulting
mes-
sage content or both. If a relatively short message must represent a ticket,
it should
be easy both for ordinary users and for ticket inspectors to perceive it as
one. Elabo-
rate alphanumeric code strings in the message tend to raise a suspicion of the
sys-
tem being complicated and difficult to use. Additionally for an inspector to
be able
to quickly and unambiguously verify the meaning of a complicated code string
re-
quires that the inspector carries along an electronic reader and verifier
device. The
same is true if the message contains some kind of a bar code that the mobile
tele-
CA 02495515 2005-02-04
WO 2004/015917 PCT/FI2003/000597
3
phone can show on its display, which is one of the suggested message
authentica-
tion techniques.
A reference publication GB 2 361 570 is known to describe a general-purpose
elec-
tronic ticket delivery system, in which the ticket is delivered as an SMS
message or
in a browser-readable format. The SMS solution discussed in said publication
is
especially prone to the fraud scheme described earlier.
Another known prior art publication is WO 96/06505, which presents a general-
purpose method for reliably identifying the originator of an SMS message. The
drawback of this scheme is that it requires modifications to the standardised
basic
operation of conveying SMS messages, because it involves using at least two
differ-
ent addresses in calling a Short Message Services Centre.
It is an objective of the invention to provide a method and an arrangement
that en-
sure easy and reliable authentication of commodities of value that were
delivered
electronically in the form of digital messages. It is especially an aim of the
inven-
tion that authentication should require only little, if any, extra investment
in system
hardware.
2.0
The objectives of the invention are achieved by adding a time-dependent
extension
to the telephone number that the message transmission system includes into the
message as the number of the sender.
A method according to the invention has the characteristic features that are
recited
in the independent patent claim directed to a method.
The invention applies also to an arrangement, the characteristic features of
which
are recited in the independent patent claim directed to an arrangement.
Various embodiments of the invention are described in the depending claims.
The invention is based on the insight that cheating in the way described above
is
only possible if the telephone number of the ticket application server is
constant, so
that the potential cheater can store it beforehand into his mobile telephone
(or corre-
sponding mobile telecommunication device) as an identifier of his accomplice.
Every time when the telephone number of the ticket application server changes,
the
cheater must reprogram his mobile telephone. By making the telephone number of
CA 02495515 2005-02-04
WO 2004/015917 PCT/FI2003/000597
4
the ticket application server to change very often it is possible to make it
difficult or
impossible for the cheater to follow. Depending on the number and nature of
possi-
ble other network-generated field values in a message it may be possible to
apply a
similar authentication strategy also to other field values than just the
sender's tele-
phone number.
According to the invention, there exists a scheme for repeatedly changing an
identi-
fier value or identifier values that the network adds into an electronically
delivered
message. Preferably the scheme utilizes certain spare character locations that
have
been defined to constitute a part of a field in a transmitted message but are
not nec-
essarily needed for the transmission of information when the invention is not
ap-
plied. Also it is preferable that the changing values are somehow related to
another
network-generated value in a well-defined field of the message, so that the
message
becomes self-sustaining regarding verification: for someone who knows the
rules
according to which the changing values behave, it suffices to compare the
contents
of the changing-value field to some other field in the message to see whether
the
message has been appropriately generated and delivered.
The most straightforward candidate for the changing-value field is the field
for the
sender's telephone number. Typically it comprises relatively many character
loca-
tions, to reckon with exceptionally long telephone numbers used in certain
systems.
If the telephone number assigned to a ticket application server is not as long
as the
maximum length of the sender's number field, the spare character locations can
be
used to insert a repeatedly changing extension. A simple and workable rule for
gen-
crating repeatedly changing extensions, that also correlate with the value of
another
field in the same message, is to utilize as an extension a part of or a
derivative from
the time value that is inserted into the message as transmission time.
The novel features which are considered as characteristic of the invention are
set
forth in particular in the appended claims. The invention itself, however,
both as to
its construction and its method of operation, together with additional objects
and
advantages thereof, will be best understood from the following description of
spe-
cific embodiments when read in connection with the accompanying drawings.
Fig. 1 illustrates a prior art setup for electronically ordering and
delivering bus
ticket messages,
fig. 2 illustrates a principle of using message parts according to the present
in-
vention,
CA 02495515 2005-02-04
WO 2004/015917 PCT/FI2003/000597
fig. 3a illustrates a process of exchanging messages according to an embodi-
ment of the present invention,
fig. 3b illustrates a process of exchanging messages according to another
embodiment of the present invention,
5 fig. 4 illustrates the operation of a ticket application server according to
an em-
bodiment of the invention,
fig. 5 illustrates the operation of an intelligent messaging gateway according
to
an embodiment of the invention and
fig. 6 illustrates certain structural aspects of a ticket application server
accord-
ing to an embodiment of the invention.
The exemplary embodiments of the invention presented in this patent
application
are not to be interpreted to pose limitations to the applicability of the
appended
claims. The verb "to comprise" is used in this patent application as an open
limita-
tion that does not exclude the existence of also unrecited features. The
features re-
cited in depending claims are mutually freely combinable unless otherwise
explic-
itly stated.
Fig. 2 illustrates schematically a message 201, which we may designate as a
multi-
media message for the sake of generality. Features of the messages that are
impor-
tant to the invention are that it is electronically deliverable from a network
to the
terminals of individual users and that it has a well-defined and standardized
struc-
ture that makes it acceptable and usable for an extremely wide population of
mobile
terminal users. A further feature of the message 201, which is also important
to the
present invention, is that its standardized composition defines a network-
generated
part 202 in addition to a user-defined part 203. Considering the widely used
SMS
message as an example, the network-defined part 202 consists of the parameter
val-
ues that a network (typically an SMSC) adds to the message, while the user-
defined
part 203 consists of the (originally maximum of 160) payload characters that a
user
or a message-generating computer program at a content provider's server puts
in.
The network-generated part 202 typically comprises fields, of which fields 204
and
205 are shown in fig. 2, into which the network inserts certain values. We
assume
that at least one of these fields has a certain maximum length that has been
selected
to accommodate the longest possible values that can be inserted into that
field, with
some marginal so that typically the whole length of the field is not needed.
As an
example we may say that field 204 is a field for the sender's telephone
number.
Telephone numbers of various lengths appear in different telephone systems
around
CA 02495515 2005-02-04
WO 2004/015917 PCT/FI2003/000597
6
the world, so the length of the sender's number field 204 must have been
selected to
accommodate also relatively long telephone numbers. Typically when the present
invention is applied, a telephone number that identifies a ticket application
server
(or other instance that is to generate messages that represent a commodity of
value)
is shorter than the maximum length of the field 204, so after said telephone
number
has been inserted as a field value 206, spare space 207 remains in the field
204.
Again as an exemplary assumption only we assume that the length of the spare
space 207 corresponds to three alphanumeric characters.
Another field 205 also appears in the network-generated part 202 of the
message
201. We assume that field 205 is the transmission time field, into which the
SMSC
should insert a value 208 that represents the moment of time at which the
message
was originally sent by its sender.
According to a preferable embodiment of the invention, the spare space 207 of
the
sender number field 204 is used to carry a code, the value of which has a
certain re-
lationship to the transmission time value 208 in the appropriate field 205.
Taken our
exemplary assumption of the spare space 207 being three characters long, an
easy
option would be to insert a certain fixed character into the spare space 207,
followed
(or preceded) by a two-digit number that matches the minute count, i.e. the
two-
digit number that represents minutes, in the transmission time value 208.
Another
option would be to select said two digits to match the second count in the
transmis-
sion time value 208. A third option would be to use two digits of the spare
space
207 to match the minute count and a third digit to match the number that
represents
tens of seconds in the transmission time value 208. It is not important to the
inven-
tion, what is the exact way of mapping the transmission time value into a code
value
in the spare space 207; the following considerations should anyway be taken
into
account:
* The mapping algorithm should make the code value to change often enough to
make it difficult for a potential cheater to follow. The cheating mechanism ex-
plained earlier requires the cheater to store into his mobile telephone a
whole new
identifier string as the name of his accomplice before forwarding the honestly
ob-
tained ticket message. It is reasonable to assume that making the code value
change
once per minute is enough to curtail at least large-scale cheating.
* The mapping algorithm should be robust against typically occurring time
fitter
and transitional phenomena in the operation of the network devices. If two
different
devices or processes are responsible for generating the transmission time
value and
CA 02495515 2005-02-04
WO 2004/015917 PCT/FI2003/000597
7
the code value, it should be ensured that they synchronize to each other
tightly
enough so that no contradictory value pairs (that would suggest that cheating
had
been attempted) are genet ated at the first place.
~' It is advantageous if the mapping algorithm changes, even relativaly
slightly,
every now and then so that a potential cheater would be confused. For example
if
the minute count approach is used, there could be a certain fixed offset value
that is
agreed upon e.g. once a week: this week the two digits in the code match the
trans-
mission time minute count plus 11, next week it is the minute count minus 05,
and
so on. It is easy to understand that the way of changing the algorithm should
be kept
secret from everybody else than those who have the task of running the system
and/or checking the validity of delivered ticket messages.
The message may naturally include also other parts and other fields than just
those
shown in fig. 2. If there is not enough spare space in one previously
determined
field and/or if it is considered advantageous for increasing security, code
values can
also be distributed into more than one field. It is likewise possible to make
a single
code value depend on more than one other value in more than one other field.
In the
process of defining a completely new message format it would naturally be
possible
to define a dedicated code value field for the insertion of a code value;
however it is
a major advantage of the present invention that the code value is "smuggled"
in a
previously defined field, moreover so that every ordinary mobile terminal will
han-
dle and display the code value in an exactly similar way with absolutely no
addi-
tional definitions for message handling. The mobile terminals are not even
aware of
there being any code values involved: they will just handle and display the
code
value of the present invention as a part of the value that belongs to the
appropriate
field, which is field 204 in fig. 2.
Fig. 3a illustrates a process of exchanging messages in a system that
comprises a
mobile terminal, an SMSC that implements the so-called CIMD protocol (Computer
Interface to Message Distribution), a messaging gateway and a ticket
application. At
step 301 the terminal generates a ticket ordering message as a response of a
user
telling the terminal to do so. At step 302 the terminal transmits the message,
and at
step 303 the SMSC receives it. Forwarding the message further towards the
ticket
application may involve certain processing 304 at the SMSC, after which a
further
transmit/receive step 305 and 306 takes place between the SMSC and the
messaging
gateway. The latter inspects the incoming message at step 307 enough to find
out
that it is a ticket ordering message, and passes it further to the ticket
application in
steps 30S and 309. The ticket application generates the ordered ticket message
at
CA 02495515 2005-02-04
WO 2004/015917 PCT/FI2003/000597
8
step 310. Up to this point the operation proceeds exactly like in known prior
art
electronic ticketing applications.
At step 311 the ticket application generates an authentication code that is to
be
added to the ticket message generated at the previous step. Certain more
detailed
ways of generating the code will be described later. At step 312 the ticket
applica-
tion transmits the completed ticket message to the messaging gateway, which re-
ceives it at step 313 and selects, by using appropriate known methods, the
SMSC
through which the ticket message should be delivered to the terminal that
ordered it.
A feature of the CIMD protocol is that the SMSC does not need to receive a
sender's telephone number from the application that generated a message or the
gateway that forwarded it to the SMSC: the SMSC has been configured to
otherwise
know a sender's telephone number that it adds to the message as a part of the
proc-
ess of sending the message towards the terminal. It is possible to provide a
sender's
telephone number to the SMSC according to CIMD, but the SMSC will still use
the
configured number and only add the number that came from the application
server
into the sender's number field after the configured number. In order not to
have the
same sender's number repeated twice in the message, the messaging gateway -
after
having recognized the appropriate SMSC as one that implements CIMD - strips
off
the actual telephone number value from the message at step 315 before sending
the
message to the SMSC at step 316. The SMSC receives the message at step 317 and
executes its conventional processing at step 318: as a part of the last-
mentioned it
takes the code value that remained in the sender's number field after step 315
and
appends it to the end of the sender's number field of the final message. Steps
319
and 320 represent transmitting the ticket message from the SMSC to the mobile
terminal in a known way.
Fig. 3b is otherwise the same as fig. 3a, but now we assume that the SMSC
imple-
ments the so-called Content Gateway interface towards message-generating
applica-
tions in the network. An important difference to CIMD arrangements is that
accord-
ing to the Content Gateway specifications, the SMSC will not use any
configured
numbers but will accept and use any sender's number that came with the
messsage
from an application server. Steps 301 to 314 take place exactly in the same
way as
in fig. 3a. However, after noticing now at step 314 that the SMSC implements
Con-
tent Gateway rather than CIMD, the messaging gateway now preserves at step
315'
the contents of the sender's number field as they were in the message that
came
from the ticket application. Step 318' proceeds in the SMSC according to the
Con-
CA 02495515 2005-02-04
WO 2004/015917 PCT/FI2003/000597
9
tent Gateway specifications, so the SMSC reads the whole contents of the
sender's
number from the message it received from the messaging gateway at step 317 and
reuses it as such in the message it transmits to the mobile terminal at step
319.
Fig. 4 illustrates the operation of a ticket-generating application according
to an
embodiment of the invention. At step 401 the application receives a ticket
order
message from an SMSC, typically through a messaging gateway. At step 402 the
application extracts the sender's telephone number or corresponding sender
identifi-
cation from the order message and stores it for later use as an identifier of
the in-
tended recipient of a generated ticket message. At step 403 the application
generates
the actual ticket message according to some preprogrammed instructions that de-
scribe how a ticket message should look like and what should it contain. At
step 404
the application inserts the sender identification extracted at step 402 into
the mes-
sage as an identifier of the intended recipient. At step 405 the application
takes its
own telephone number or corresponding identifier and inserts it into an
appropriate
sender identification field in the ticket message as a prefix of a complete
identifier
value. Up to this point the process has executed itself similarly as in prior
art elec-
tronic ticketing applications.
According to the invention, at step 406 the application reads a code value and
in-
serts it into the sender identification field in the ticket message as a
suffix that com-
plements the prefix inserted at step 405 to constitute a complete identifier
value. If
we assume that the code value is simply some part of the number string that
indi-
cates current time, possibly altered with a fixed offset, an advantageous way
of exe-
cuting step 406 is to read current time from a local clock, extract the
appropriate
numbers from the time value read, refer to a database for finding the
currently valid
offset value, perform the summing (or other calculational) operation between
the
extracted numbers and the offset, and write the result into the ticket message
under
construction. If run-time calculations are to be avoided and/or if the
relationship be-
tween a time reading and a corresponding code value is more intricate than a
pure
sum, the database may also include a look-up table prepared beforehand, from
which the application finds directly a modified code value by using the local
time
reading as a key.
At step 407 the application reads once more (if necessary) the local time
value and
inserts it into an appropriate field in the ticket message as an indicator of
original
message transmission time. At step 408 the application transmits the completed
CA 02495515 2005-02-04
WO 2004/015917 PCT/FI2003/000597
ticket message towards an SMSC, typically through a message gateway. Steps 407
and 408 are again similar to corresponding steps known from prior art.
Fig. 5 illustrates the operation of a message gateway functionality according
to an
5 embodiment of the invention when it conveys a completed ticket message from
a
ticket-generating application towards an SMSC. At step 501 the message gateway
receives a ticket message from the application, and at step 502 it selects the
appro-
priate SMSC according to certain rules. Typically there is a default SMSC for
each
subscriber to a mobile telecommunication system and the identity of the SMSC
can
10 be derived from the subscribers IMSI (International Mobile Subscription
Identifier),
fo typically the message gateway reads the recipient identifier at step 502
and uses
some simple logic to select the appropriate SMSC. Steps 501 and 502 take place
ac-
cording to practices known from prior art.
At step 503 the message gateway checks, whether the selected SMSC runs CIMD or
not. To be more general, we may say that at step 503 message gateway checks,
whether the selected SMSC runs a messaging protocol that will only use a
possibly
transmitted sender's telephone number as a suffix to a preconfigured sender
identi-
fier (as in CIMD) or whether the selected SMSC runs a messaging protocol under
which it is possible to send a complete sender identifier to the SMSC together
with
the message. A positive finding at step 503, which means that CIMD or a corre-
sponding protocol is in use, causes a transition to step 504 at which the
message
gateway deletes the prefix part from the sender identifier that the
application has in-
serted. It is easy to understand that the message gateway need certain
unambiguous
preprogrammed instructions of how to decide the number of characters to be de-
leted; assuming our example of always having three characters in the suffix an
un-
ambiguous instruction may be as simple as to delete all but the three last
characters
in a sender identifier string.
A negative finding at step 503 results in a transition to step 505, into which
the
process also goes after having executed step 504 when needed. Step 505 is a
straightforward transmitting step at which the ticket message is transmitted
towards
the appropriately selected SMSC.
The methods of figs. 4 and 5 do not take any position regarding at which step
or de-
vice should charging for the ticket be accomplished. Charging is not a matter
of in-
terest regarding the present invention, and we may just assume that some known
CA 02495515 2005-02-04
WO 2004/015917 PCT/FI2003/000597
11
methods or methods that at the priority date of this patent application are
still to be
invented are used for charging.
Fig. 6 is a general block diagram of a system 601 according to an embodiment
of
the invention, in which the message gateway functionality 602 has been
integrated
into a single system with the ticket-generating application 603. At the
disposal of
the latter is a database 604, which can be used for various purposes. Closest
of these
to the present invention is the use of the database 604 as a storage of the
currently
valid code value. The system includes a web interface 605 through which it is
pos-
sible to examine and change certain configuration information stored in the
database
604. There may also be direct connections for exchanging information between
the
web interface 605 on one hand and the message gateway functionality 602 and
the
ticket-generating application 603 on the other hand. As a way of adminstering
the
database 604 there is a collection of scripts 606, some of which may have been
con-
figured to execute automatically at the fulfilment of certain criteria while
others
must be manually triggered through the web interface 605.
Illustrating all functionalities of fig. 6 in an exemplary way as existing
within a sin-
gle system 601 does not exclude other possible implementations. Parts of the
sys-
tem may be implemented even very far from each other, physically in clearly
sepa-
rate systems, as long as the communication connections between the different
func-
tionalities are realised appropriately. For example, it is relatively common
that a
message gateway functionality exists as a standalone system that serves to
selec-
tively connect a number of SMSCs with a number of application servers that run
a
wide variation of different service applications that utilize messaging.
In the description above we have repeatedly referred to "tickets" and "ticket
genera-
tion" as an application of the invention. However, the applicability of the
invention
is not limited to tickets in the sense of admission tickets or travel tickets.
The con-
cept of a "ticket" must be understood widely to cover all such instants where
a user
must or may have at his possession some commodity of value, which ultimately
is
just a piece of information that proves that the user has committed a certain
transac-
tion in a prescribed manner.
We have also mainly described an embodiment of the invention where the code
value is derived from the transmission time of the ticket message and inserted
into
the sender identification (sender's telephone number) field, while the
transmission
time is inserted into the well-defined transmission time field of the same
message.
CA 02495515 2005-02-04
WO 2004/015917 PCT/FI2003/000597
1~
In principle it is possible to use only the transmission time field for the
transmission
of both the transmission time and the code value, if the system is allowed to
slightly
break the conventional rules of handling the transmission time field. An
example of
this kind is to make the ticket-generating application manipulate the
transmission .
time value so that the minute count and second count would always be the same,
or
differ from each other by the currently valid offset value, in validly issued
ticket
messages. Even if a cheater found out that this week the proof of
authentication is
the fact that the second count is seven more than the minute count in the
transmis-
sion time value, he would have hard times trying to time the transmission of
an ille-
gal copy to his accomplice exactly on the correct second.
