EP2118856A1

EP2118856A1 - Method, ticket handling apparatus, computer program product and product platform for a security mechanism of an electronic ticket

Info

Publication number: EP2118856A1
Application number: EP08709314A
Authority: EP
Inventors: Erkki JYLHÄ-OLLILA
Original assignee: Ejo Consulting; Ytv Paakaupunkiseudun Yhteistyovaltuuskunta
Current assignee: EJO CONSULTING; HSL HELSINGIN SEUDUN LIIKENNE
Priority date: 2007-02-09
Filing date: 2008-02-07
Publication date: 2009-11-18
Also published as: FI121323B; FI20075092A; FI20075092A0; EP2118856A4; WO2008096041A1

Abstract

In the invention, the file structures of an electronic ticket are protected by sealing. The file structure of the ticket includes the basic data of the ticket and the information of the ticket application. This file structure can be read, written and processed by ticket handling apparatus, and at least part of the information of the ticket application is protected by seals. In connection with the selling, the first seal is calculated by a ticket handling apparatus, using the basic data of the ticket and the information of the ticket application, and this first seal is written on the ticket. Some encryption method is used for calculating the seal. This seal protects the information by which it has been calculated. The second seal is calculated in connection with the stamping of the ticket by the ticket handling apparatus, using the basic data of the ticket, the updated information of the ticket application and the broken first seal. When the second seal and the updated information of the ticket application have been written on the ticket, the broken first seal is written in place of the intact first seal. When the ticket is being checked in the ticket handling device, it calculates a reference seal from the values read from the ticket, and compares it with the read seal. If the reference seal and the read seal correspond to each other, the ticket is accepted. If the ticket has been checked and accepted, the information on the ticket that is not protected by a seal can be updated. The ticket can be saved on a remote-readable travel card, a contact card, a one-time card with a memory or a mobile communication device.

Description

Method, ticket handling apparatus, computer program product and product platform for a security mechanism of an electronic ticket

The invention relates to a method, ticket handling apparatus, computer program product and product platform for an electronically readable ticket, which can be a travel ticket, entrance ticket or a corresponding voucher exchangeable for a commodity or service, where the purpose of the method, ticket handling apparatus, computer program product and product platform on which the ticket can be saved is to protect the authenticity and properties of the ticket and to implement a security mechanism.

A problem related to electronically readable tickets, which can be, for example, single tickets, smart cards or files in mobile communication devices, is that they should be both safe so that dishonest users would not be able to modify or copy the tickets and the information therein, and flexible to provide comfort of use so that, for example, the ticket would not become valid before it is stamped, and it could be acquired in advance. In addition, the making and checking of the ticket and stamping it as used must take place quickly. Tickets like this can be used, for example, to pay for journeys, as entrance tickets or to pay for products, such as for food or drink in large public events.

Patent specification WO 2004/015917 deals with the security of tickets sent as text messages. In the specification, an individual security code is generated on the basis of the transmission time of the text message, which prevents copying the message or transferring it to another platform. However, in that case it is not possible to take the ticket into use flexibly, i.e. to stamp it at the desired point of time.

In patent specification EP1439495, the electronic ticket is secured by identification codes. The identification codes are separately created by using the identification number of the product platform, an external encryption key and a random number generator. A lot of calculation is required in this method, and it may slow down the writing of the ticket and its inspection.

It is an objective of the invention to provide a solution by which the drawbacks and disadvantages related to the prior art can be significantly reduced. In addition, the invention facilitates contactless trading, makes it faster and enables many new trading methods used in it. The objectives of the invention are achieved by a method, apparatus and computer program, which are characterized in what is set forth in the independent claims.

Some preferred embodiments of the invention are presented in the dependent claims.

In the method according to the invention for protecting an electronic ticket, security is based on the protection of data structures by sealing. The file structure of the electronic ticket includes the basic data of the electronic ticket and the ticket application information. This file structure can be read, written and processed by ticket handling apparatus, and at least part of the information of the ticket application is protected by seals. In connection with the selling, the first seal is calculated by a ticket handling apparatus, using the basic data of the ticket and the ticket application information, and this first seal is written on the ticket. This seal protects the information by which it has been calculated. The second seal is calculated in con- nection with the stamping of the ticket by the ticket handling apparatus, using the basic data of the ticket, the updated information of the ticket application and the broken first seal. When the second seal and the updated information of the ticket application have been successfully written on the ticket, the broken first seal is written in place of the intact first seal. When the ticket is being checked in the ticket handling apparatus, the ticket handling apparatus calculates a reference seal from the values read from the ticket, and compares it with the seal read from the card. If the reference seal and the read seal correspond to each other, the ticket is accepted. If the reference seal and the read seal do not correspond to each other, the ticket is rejected. If the ticket has been checked and accepted, the information on the ticket, which is not protected by a seal, can be updated. The ticket can be saved on a remote-readable travel card, a contact card, a one-time card with a memory or a mobile communication device.

The ticket-handling apparatus according to the invention includes a central unit, a memory, a communication unit and means for remote reading the file structure of the ticket from the product platform and to write in the file structure of the ticket. The ticket handling apparatus can carry out ticket selling, stamping and checking measures. The selling measures and the stamping and checking measures are generally carried out in separate ticket handling apparatus units. For example, when a ticket is being bought for a mobile communication device, the sales unit can be very far physically. In connection with the selling, the ticket handling apparatus sets the selling information and calculates the first seal, for which it uses the basic data of the ticket and the information of the ticket application, including the sale information. The information of the ticket application and the first seal which protects the information by which it was calculated are written on the ticket. The basic data of the ticket has usually been set earlier, or it is ready as properties of the product platform, as the case usually is with mobile communication devices. In connection with the stamping, the ticket handling apparatus checks whether the ticket already has a second seal ready, i.e. whether the ticket has already been stamped. If a second seal does not exist yet, the ticket handling apparatus first checks the correctness of the ticket by calculating a reference seal and comparing it with the first seal of the ticket. Then it calculates the second seal by using the information of the ticket application updated in the stamping, the basic data of the card and the first seal, which has been broken. After this, the ticket handling apparatus writes the updated information of the ticket application on the ticket on the product platform, and then replaces the first seal by a seal used in the calculation of the second seal. The ticket handling apparatus can complement or edit the file structure of the ticket read from the product platform, if it is not in the form required by the ticket handling apparatus. This enables the use of many product platforms of different types in the same system.

The method according to the invention is implemented by a computer program product, which has means for calculating the first seal from the basic data of the ticket and the information of the ticket application in connection with the selling, and for calculating the second seal from the basic data of the ticket, the information of the ticket application and the broken first seal in connection with the stamping of the ticket. The computer program product operates in the ticket handling ap- paratus. The computer program product can be adapted to operate in ticket handling apparatus units intended both for ticket selling and ticket inspection.

The electronic ticket according to the invention is stored on a product platform, which is electronically readable and writable and which has a central unit, a memory and a RFID unit or a corresponding unit enabling remote reading and writing and which has an individual identifier or for which one can be generated. The memory of the product platform has been arranged, by means of its RFID unit, in connection with the sale transaction to receive an electronic ticket, which consists of the basic data of the ticket, the information of the ticket application and the first seal calculated therefrom, which is individual for each product platform and ticket. In connection with the checking or stamping of the ticket, it also offers the information of the ticket to be read by the card handling device. In addition, in connection with the checking or stamping of the ticket, it can also receive second seal, the updated information of the ticket application and the broken first seal. This product platform is a. remote-readable travel card, a contact card, a single card with a memory or a mobile communication device.

The invention has the advantage that the use of seals increases the data security of the cards. Compared to access right keys, the sealing method has the advantage that the keys need not be distributed to the card, which is slow and cumbersome and may cause problems with data security. For example, for casual users who use tickets loadable to NFC devices, the sealing method described by the in- vention is the only way of ensuring the correctness of the product in practice. Because the encryption keys used for calculating the seals are kept as protected in the card handling apparatus, unauthorized modification of the information protected by them is difficult.

In addition, the invention has the advantage that this method speeds up the han- dling of the cards during stamping and checking. More convenience of use is also provided by the fact that the invention enables buying the product in advance, because according to the invention, the product can be set to become valid in connection with the stamping. It is also adaptable to different devices and platforms, which enables the use of many different product platforms in the same system.

Furthermore, the invention enables new ways of contactless trading, which may be, for example, the implementation of auxiliary sales in large public events, such as food products, drinks and the like, in accordance with the invention, which would facilitate the arrangements and reduce the time needed for them.

The invention also has the advantage that it makes it possible to return or change the product purchased electronically. This possibility increases the customer's trust in the system.

In the following, the invention will be described in more detail. Reference will be made to the accompanying drawings, in which

Figure 1 shows the ticket handling apparatus by way of example,

Figure 2 shows an example of the product platform of the electronic ticket according to the invention,

Figure 3 is an exemplary flow chart of the method according to the invention, Figure 4 shows an example of the file structure of the electronic ticket in a simplified manner, and

Figure 5 shows an example of the use of seals on the level of the file structure of the electronic ticket.

The arrangement for assigning the right of use and checking of travel tickets and the checking method used in it is presented as an example of utilizing the method according to the invention. In the travel ticket system according to the invention, seals are used for increasing the security and convenience of use of the electronic ticket. An example of the handling of a single card application used for travelling with public transport means, and other examples, will be described in the following. Hereinafter, during the first example, when a single card application is meant, it will be referred to as a ticket. Hereinafter, when a single card application or other electronically purchased ticket providing the right of use to a service or product is meant, it will be referred to as a ticket. The means on which this ticket is, is called the product platform. The apparatus by which the tickets on the product platform are read and written, the information of the tickets is modified and their rights of use are checked, and selling and stamping measures are carried out, are called ticket handling apparatus.

Fig. 1 shows the ticket handling apparatus 10 according to the invention by way of example. It may be, for example, a travelling means checking and registering means located in a travelling means. It preferably comprises a central processing unit (CPU) 101 , in which the checking and granting measures for the right of use of the ticket required by the method according to the invention are performed. The central processing unit may utilize the memory 102 for executing the program ac- cording to the invention and for saving its results.

The ticket handling apparatus 10 also includes a RFID unit 103. It enables the ticket handling apparatus to exchange messages with the object being checked, which can be, for example, a remote-readable travel card 203, a contact card or a mobile communication means. The RFID unit 103 of the ticket handling apparatus comprises both a transmitter and a receiver. In the first step, a remote-readable travel card, for example, is activated by means of the transmitter. In the second step, the information transmitted by the travel card 203 is received by the receiver. In the third step, new information is written on the travel card 203. This information preferably comprises the writing instructions of the seals according to the inven- tion. Similarly, other information, such as validity information, can also be saved in the travel card.

The ticket handling apparatus according to the invention can advantageously include a GPS positioning device 106, which receives positioning information from the satellites 107. The location information can be used for checking the right to utilize the right of use.

The ticket handling apparatus according to the invention may also comprise a communication unit 104, through which it can exchange information with a data system belonging to the travel card system (not shown in Fig. 1). The data transfer connection 105 can be either a wireless or wired data transfer connection. Through the data transfer connection, it is possible to update user or location information or the software of the checking device, for example. The ticket handling apparatus may also have a display or a corresponding indicator, which tells the customer about the steps of the ticket handling and the properties of the ticket, such as the time of validity of the ticket, or the apparatus indicates by a sound or light signal whether the stamping or checking of the ticket was successful.

Fig. 2 shows the functional main parts of an exemplary, remote-readable travel card 20. The card has a central processing unit (CPU) 201 , which can read from the memory 202 and write into the memory 202. The electronic ticket is preferably in the memory of the travel card. The travel card 20 includes a RFID unit 203, by which the travel card can receive information from the ticket handling device 10 from the RFID unit 103, for example. By the RFID unit 203 of the travel card, the travel card can also transmit information of the ticket saved in the memory 202 of the travel card 20. This information may advantageously comprise information re- lated to the right of travel and the seal information according to the invention.

The file structure of the ticket read from the product platform is complemented and changed in the memory of the ticket handling apparatus to comply with the requirements of the ticket handling application in the ticket handling apparatus. This means that the file structures of the tickets need not necessarily be alike, but many different platforms can then be used in the same system.

Figure 3 illustrates the method according to the invention as an exemplary flow chart. The method is described in it step by step.

In step 301 of Fig. 3, the ticket is sold, whereupon the ticket handling apparatus carrying out the selling measures starts to prepare the ticket for transfer to the product platform. In step 302, the ticket is initialized, i.e. the basic data according to the product platform and the application is given to it. In step 303, the ticket selling information is set. After this, the first seal is calculated for the ticket in step 304, after which the ticket can be written on the product platform in step 305.

In step 306 of Fig. 3, the ticket is stamped. In step 307, the values of the ticket are read from the product platform to the ticket handling apparatus. In step 308, it is checked whether another seal is found from the values read. If the answer is "NO", it is checked in step 309 whether the first seal of the ticket is valid. If the first seal is found to be valid, i.e. the answer in step 309 is "YES", the process moves to step 310, in which a second seal is calculated for the ticket, after which in step 316, the second seal and the updated information is written on the ticket on the product platform, and the stamping transaction is stopped in step 317.

If in step 309 of Fig. 3, the first seal is found to be invalid, i.e. the answer is "NO", the process moves to step 314, in which the ticket is rejected. The stamping trans- action is stopped in step 315.

If in step 308 of Fig. 3, a second seal is found from the ticket, the answer is "YES", and the process moves to step 311 , in which the second seal is checked. If the second seal is found to be invalid, i.e. the answer is "NO", the process moves to step 314, in which the ticket is rejected. The stamping transaction is stopped in step 315.

If in step 311 of Fig. 3, the second seal is found to be valid, i.e. the answer is "YES", the process moves to step 312, in which the updated information of the ticket is written on the product platform. The stamping transaction is stopped in step 313.

According to Fig. 4: the file structure of the ticket is divided into two parts: the basic data of the ticket (Applicationlnformation) and the ticket application (eTicket). The ticket application consists of the sale information (Salelnformation), the first seal, the validity information (Validitylnformation), the second seal and the boarding information (Boardinglnformation). The basic data of the ticket are set in con- nection with the initialization of the ticket, which may take place at the time of the selling or before it. The basic data include a series of numbers, or an ID number, which identifies the ticket. This ID number is formed, for example, from the number of the travel card chip given by the manufacturer. The ID number is different on each product platform unit, or there is so much variation that it is almost impossible to utilize it in a dishonest manner.

The sale information includes the properties of the purchased commodity, i.e. in this case those of the travel ticket, which for example include the quality of the ticket, its date of sale, area of validity, time of validity, price and other possible properties. The sale information is protected by the first seal, by which the authenticity and intactness of the information is secured, and by which it is checked that the information is on the original product platform. The first seal is calculated in connection with the selling. In the sale transaction, the sale information and the first seal, which has been calculated in the sales system, are written on the initialized ticket. The rest of the area of the ticket application, where space is reserved for the validity information, the second seal and the boarding information, is written as zero. The selling is carried out by a ticket handling apparatus for selling. The selling may take place at a sales point or an automatic selling machine.

The seal can be calculated in many different ways. Preferably, the seal is calculated by the 3DES key according to the ISO 9797 standard. The ticket handling apparatus can calculate the seals programmably, or it may contain a security module, in which the encryption keys have been saved, and the calculation is carried out in a protected environment. The basic data and sale information of the ticket are required for calculating the first seal. Merely the ID number and the sale information can be used for this. Because the information content, from which the first seal is calculated, includes the individual ID number of the product platform, it is not possible to create a functional copy of the ticket information on another product platform.

The ticket handling apparatus for checking and stamping checks and stamps the ticket and calculates a new seal when required. The ticket handling apparatus may be in the means of transport for which the ticket has been acquired, or on the platform, station or corresponding space from which the means of transport is accessed. When the ticket is stamped for the first time, it is taken in the vicinity of the ticket handling apparatus, whereby the ticket handling apparatus reads from the product platform the ticket information, which in this case includes the application information, sale information and the first seal of the ticket. It examines whether there is a second seal on the ticket, which would mean that the ticket has already been stamped. If a second seal is not found, the first seal is searched for. When the first seal has been found, it is checked whether it corresponds to the application information and sale information of the ticket which have been read. This is done by calculating in the memory of the ticket-handling apparatus, by the values read into it, the first seal in the same way as it was done in the sales system in connection with the selling. This calculated first seal is called the reference seal. The reference seal is compared with the first seal read from the ticket. If they are alike, the file structure of the ticket is accepted. This is done to check the authenticity and intactness of the sale information and whether they are on the correct product platform. If the valid sale information according to the first seal is on the ticket, the validity information is formed. If the ticket has been sold so as to become valid from the first use, the validity information of the ticket is calculated in connection with the first stamping according to the time of the ticket handling apparatus and the length of the validity period in the sale information of the ticket.

The ticket handling apparatus calculates the second seal by means of the application information, sale information, first seal and validity information read from the ticket. For calculating the second seal, the first seal is broken in the memory of the ticket handling apparatus. This can be done by writing numerical values on either the whole first seal or a part thereof. The values that break the first seal are agreed on in advance, and they can be zeros or random numbers, for example. The second seal is calculated in the same way as the first one. In this case, the encryption key of the ticket handling apparatus, the application information and sale information read from the ticket and the first seal broken in the ticket handling device are used for calculation. The second seal of the ticket confirms the authenticity and intactness of the validity information. The boarding information of the ticket, which indicates where and when the ticket has been used, is also created in connection with the stamping. The content of the boarding information is not pro- tected by sealing.

When the validity information and the second seal and the boarding information have been written on the ticket on the product platform, and the success of the writing has been confirmed by backreading, the corresponding values, which were used when calculating the second seal in the ticket handling apparatus, are written on the first seal. This breaking of the seal annuls the sale information and at the same time validates the validity information. The annulment of the sale information ensures that the resetting of the validity information would not restore the sale information as valid. In addition to the validity information, the second seal also covers the sale information and the application information of the ticket, and thus it also confirms their authenticity and intactness. If the means of transport is changed during the validity of the ticket, it is stamped again by the ticket handling apparatus. The ticket handling apparatus reads the ticket information. It checks whether the ticket has a second seal, i.e. whether it has already been stamped. Having found it, the ticket handling apparatus checks whether this second seal corresponds to the application information and validity information of the ticket. The checking is carried out in the memory of the ticket handling apparatus by calculating a reference seal from the read ticket information and by comparing this reference seal with the second seal read from the card. If the second seal is accepted, i.e. the reference seal and the second seal have been found to be the same, the changing carried out is added to the boarding information of the ticket.

The validity information can also be set in connection with the purchase transaction. They can be made valid for a certain period of time beginning from the sale or for a certain period of time in the future. This selling made for a certain period of time can be used, for example, when selling travel tickets for the duration of a certain event. This event could be, for example, an athletic contest lasting for several days, partial events of which are on different sides of the usage range of the tickets. If the validity information is set in connection with the selling, the first seal is not calculated but it is set directly in the broken mode, which may be zeros, and the second seal is then calculated in the manner described above.

Because the encryption keys needed for the calculating and checking of the seals are merely in the sales systems and the card handling apparatus, it is difficult for a dishonest user to forge the seals.

Fig. 5 describes the use of seals more accurately on the level of the file structures. The functionality may vary in accordance with the requirements of the product platform or the different purposes of use of the product (ticket). The manner described follows, for the applicable parts, the file structure of a single card application adapted on the Mifare Ultralight product platform. The charts denote the content of the file structure in the calculation processes. The chart is not accurate, and it should not be used as a bit-level description of the file structure.

The Mifare Ultralight cards are remote readable and writable storage means, the memory of which is divided into segments and blocks. The remote use of the cards is based on the ISO 14443 technology. The cards have a memory of 512 bits (64 bytes). A part of the areas of the memory are required by the format, the rest are used by the user application. Although the Mifare Ultralight card is used in this example, the described file structure and its use can be easily adapted on other platforms as well.

Fig. 5 shows the three different states of the file structure of the ticket of a single card application. Point a) (SEAL1) is the situation when the ticket has been bought. Point b) (SEAL1 & 2) is the situation when the ticket is being stamped.

Point c) (SEAL2) is the situation when the ticket has been stamped and used for travelling. There are 63 blocks divided into eight segments in the described file structure. In Fig. 5, the segments are named consecutively as D1 , D2, D3, D4, D5 and D6. To improve the functionality of the picture, segments D7 and D8 have not been named in it. 8 blocks have been reserved for each segment, except the last segment D8, for which 7 blocks have been reserved in this case.

Point a) in Fig. 5 is the file structure of a bought and unused single ticket application. Segment D1 includes the card serial number set by the manufacturer (blocks 1 to 7, which have been named SN0-SN6). At the end of segment D1 and at the beginning of segment D2, in blocks 8, 9, 10 and 11 , there is the OTP (One Time Programmable) area of the card. It is possible to write in this area only once, because its bits cannot be restored from one to zero. This property is utilized when improving the security of the ticket.

Segment D2 and partly segment D3 contain the application information of the ticket, which include the ID information of the ticket, the version numbers of the application, the identifiers of the owner of the application and the like. This application information has been written in connection with the initializing of the ticket. This can be done in advance or in connection with buying the ticket. The individual ID number of the card (ApplicationSerialNumber) is saved in the blocks 18, 19 and 20 in the segment D3. The card chip serial number given by the manufacturer is used for calculating this ID number. The sale information is given to the product in the purchase transaction. This information is set in accordance with the product bought by the customer. If the application and sale information do not fill up the space reserved for them, the space remaining empty is filled with values of a pre- determined type. Depending on the application, they can be zeros or other suitable values. The seal calculation method used, ISO 9797, requires that the area to be calculated has been complemented as multiples of 8 bytes, i.e. the calculation takes place in eight-byte blocks. The standard also defines the complementation mechanism. In the case of point a) of Fig. 5, the points to be complemented have been the blocks 21 , 31 and 32. Before the sale information is written on the ticket, the first seal is calculated. This is calculated in the sales system from the information content of the card, which includes the serial number of the card, its application information and sale information. The seal is preferably calculated by the 3DES key according to the ISO 9797 standard. Because this encryption key is only in the sales system and the ticket handling apparatus, calculating the seals dishonestly is difficult and time- consuming even in the cases when it would be possible. Because the information content used for calculating the seal includes an individual identifier of the card, it is not possible to create a functional copy of the information content of the ticket on another product platform, which may be another card or some other device, but the sale information protected by the seal functions only on the product platform on which it has been set.

When the sale information and the first seal are ready in the sales system, they are written on the ticket on the card. The application information and sale informa- tion of the ticket are placed in the segments D2, D3 and D4. The first seal of the ticket is placed in the segment D5, which includes the blocks 33-40, which are named in Fig. 5 as Data18-Data25. The rest of the file structure, segments D6, D7 and D8, are written full of zeros. After writing, the file structure of the ticket is ready for use. In the sales system, the calculated file structure of the ticket is not neces- sarily written entirely as such, but the memory properties of the physical card may set restrictions. This does not cause problems, because when the file structure of the ticket on the card is read for stamping into the ticket handling apparatus, checking or some other measure, the file structure is complemented into the form required by the application. This for its part makes it more difficult to misuse the ticket.

The seal can also be made with some other method. In cases like that, it is not necessary to complement the incomplete segments.

The file structure of a single ticket application when the ticket is being stamped for the first time is shown at point b) of Fig. 5. The card contained by the ticket has been taken in the vicinity of the ticket handling apparatus for stamping. The ticket handling apparatus reads the file structure of the ticket, which in this case includes the serial number, application information, sale information and the first seal. At first, the ticket handling apparatus looks for a second seal in order to see whether it has been stamped earlier. When a second seal is not found in this case, the ticket handling apparatus checks whether the read file structure of the ticket corresponds to the first seal. This is done by calculating the first reference seal corre- sponding to the seal in the memory of the ticket handling apparatus and comparing it to the read value. If the ticket handling apparatus accepts the first seal, i.e. the sale information is found to be valid, intact and on the product platform for which the product has been sold, the validity information of the ticket is formed. The validity of the ticket according to the time by the clock of the ticket handling apparatus and the length of the validity period read from the sale information is included in the validity information. If the validity information does not fill up the space reserved for it, the space remaining empty is complemented with values of the agreed type in the same way as was described at point a). In the case de- scribed at point b), values for the amount of one block have been added to the validity information in block 48, in which case it fills up the segment D6.

Before the writing of the validity information, a second seal is calculated for the ticket in the ticket handling apparatus. Calculating the second seal takes place practically in the same way as calculating the first seal. During the calculation of the second seal in the memory of the ticket handling apparatus, the first seal is broken. In this case, it is done by setting the third, fourth, fifth and sixth block of the segment contained by the first seal preferably as zeros. Now the information content of the ticket, from which the seal is calculated, includes, in addition to the information required for calculating the first seal, also the validity information and the first seal as broken. The second seal is calculated by the 3DES key in the ticket handling apparatus according to the ISO 9797 standard. In addition to the application and sale information, the second seal thus covers the first seal as broken and the validity information.

When the ticket handling apparatus has calculated both the validity information and the second seal from the ticket information it has read, this can be written on the ticket on the card. The validity information is written in segment D6, and the second seal is written in segment D7. The file structure of the ticket in now like point b) in Fig. 5.

When the validity information and the second seal have been written on the ticket on the card, the ticket handling apparatus checks them by reading them and comparing them to the values in the memory. When the writing transaction has been secured, the first seal is broken so as to correspond to the broken seal used for calculating the second seal. In this case, blocks 35, 36, 37 and 38 of segment D5, which contains the first seal, are written with zeros on the ticket. Because the forms of the file structure on the ticket on the card may differ slightly from those in the ticket handling apparatus, the locations are not necessarily at the same points in the ticket. This writing command breaks the first seal, whereby the sale information ceases to be valid. At the same time, this writing command also sets the information content of the ticket to correspond to the information content used in the calculation of the second seal. Now the second seal corresponds to the informa- tion content of the card, and therefore the authenticity and intactness of trie ticket can by checked by means of the second seal. The annulment of the sale information ensures that the resetting of the validity information and the second seal would not restore the sale information as valid. The situation described here corresponds to point c) in Fig. 5. After this, the boarding information indicating where and when the ticket has been used is written on the ticket. The boarding information is formed by means of the location information and the time by the clock of the ticket handling apparatus. The boarding information is placed in segment D8. In this case, they fill blocks 57-59 of segment D8. The information is intended mainly for the use of ticket checking, and it has not been protected by sealing.

If the card of the kind described above is wanted to have a possibility for secure reloading and also in other ways to improve the data security of the ticket on the card, the OTP area (One Time Programmable) is taken into use. Its length is 32 bits. The state of the OTP area is checked in the ticket sale transaction. If all the bits of the area have been set, i.e. they are ones, the card is regarded as used up, and no more selling is allowed for this card. If the area is empty, i.e. all the bits are zeros, it is the first sale transaction for the card in question. Then, in the first sale transaction, the value of the OTP area is written as OxCOOOOOOO, i.e. the two topmost bits of the OTP area are set as ones. The first seal of the ticket is calculated, like in the previous example, from the serial number of the card, the application and sale information of the ticket, but the information of the OTP area is also included now. When the ticket is stamped for the first time, i.e. the second seal is calculated, the OTP area is either not calculated, or it is set as zero in the ticket handling device. When the validity information and the second seal have been written on the ticket, the information content of the OTP area, or the bit sequence, is circulated in the memory of the ticket handling apparatus one step to the left so that the first value becomes the last, and the new value thus obtained is written to the OTP area on the card. Because the bits of the OTP area cannot be restored back to zero, the two topmost bits of the OTP area remain as ones, and the lowermost bit moves to the one-state, being thus of the form OxC-0000001. When the ticket is restamped, its file structure is read into the memory of the ticket-handling apparatus, and there the OTP area can be set as zero or alternatively ignored when calculating the reference seal for checking. When the card is wanted to be reused for the sale transaction, i.e. a new product is purchased for it, it is found that all the bits in its OTP area are not zeros, and thus the basic value need not be set. When the first seal of the file structure of the new product is calculated, the value of the OTP area, which is OxC-0000001 in this case, is also used in addition to the other values. In the next setting of the validity information, the information content of the OTP area, or the bit sequence, is circulated again in the memory of the ticket handling device one step to the left. Now the two first and the two last values of the OTP area are ones. This value is written to the OTP area of the card. This process can be continued, until all the bits in the OTP area are ones. Then the card has been used up, and the customer must get a new card. A method like this allows reloading the card 30 times. Because in the setting of the validity information, the information content of the OTP area is changed after the setting of the validity information and the OTP area is included in the first seal, restoring the sales information to the card does not form new, valid sales information. In con- nection with the first selling of the card, other values can also be set as the basic value of the OTP area. If the value is set as 0x00000000, reuse of the card is in no way limited. If the value is set as OxFFFFFFFE, the card can be used only once. It is also possible to use other kinds of OTP areas and corresponding solutions. Their use is very similar to that of the case described.

The steps described by the method according to the invention can be carried out by a program in the memory of the ticket handling apparatus, and the program is executed in the central processing unit of the apparatus.

As another example, the ticket application is described by using a NFC device (Near Field Communication), which can be a telephone, a palm computer or the like, as the product platform. A data structure of the ticket application like the one described above can be placed in an NFC device, which functions through the NFC interface according to the ISO 14443 standard. In addition, the product platform must have a unique ID number, which must be electronically readable, and the application must have a sufficient memory capacity available in order to save the ticket application. Then it is possible to use the ticket application through the NFC interface in the same way as the application on the card.

The file structure of the ticket application has been designed such that it can be loaded to the NFC device. When a connection is established to the sales system by the device, the ID number of the device is transmitted in the ticket purchase re- quest. In connection with the purchase of the ticket, the sales system calculates the first seal from the ID number of the device and the sales information of the ticket. The first seal is calculated by the 3DES key in the ticket handling apparatus according to the ISO 9797 standard. This seal confirms the authenticity and intact- ness of the sales information, and by it it can be checked that the ticket is on the original product platform. The sales system forms a sealed ticket product accord- ing to the product being purchased, which is sent back to the NFC device as one file, for example. The transmission of information can also take place as text messages coded as SMS messages. The NFC device must then have an application program, which converts the character-coded text message files into the form required by the ticket product.

When the ticket is used, the NFC device, in which a ticket application ready for use has been saved, is taken close to the ticket handling apparatus for the stamping of the ticket. The ticket handling apparatus reads the ticket information through the NFC interface. At first, the ticket handling apparatus checks whether the ticket has a second seal, i.e. whether it has already been stamped. If there is no second seal, the first seal is searched for. When this has been found, the ticket handling apparatus checks the first seal on the basis of the information it has read. The first seal is checked in the memory of the ticket handling device by calculating from the read values, which are the ID number of the device and the sale information of the ticket, a reference seal corresponding to the first seal in the same way as in con- nection with the buying of the ticket in the sale system. This reference seal is compared to the read first seal. If they are the same, it means that the ticket is valid. If the checking of the first seal tells that the ticket is in force and valid, the validity information is formed in the ticket handling apparatus and the second seal is calculated. The ID information of the NFC device, its sale information, validity in- formation and its first seal as broken are required for calculating the second seal. The first seal can be broken in the memory of the ticket handling apparatus by writing predetermined values on the seal or on a part of it. These values can be zeros or random numbers, for example. It is essential that these same values are used later when breaking the first seal in the ticket application in the memory of the NFC device.

The second seal is calculated in the ticket handling apparatus by the 3DES key according to the ISO 9797 standard. In addition to the application and sale information, this seal covers the first seal and the validity information of the ticket. The validity information and the second seal are written in the ticket application in the NFC device. When it has been ensured by backreading that the writing has been performed successfully, the first seal is broken by writing in its memory area the same values as were written in the memory of the ticket handling apparatus when calculating the second seal. This writing annuls the sale information, i.e. breaks the seal, but at the same time validates the validity information by another seal. This second seal can be used for checking the correctness and validity of the ticket, for example when it is a travel ticket, which is used for changing to another means of transport. The boarding information, which is not protected by the seal, is written on the ticket at the same time.

When the ticket is stamped for a second time, e.g. when changing to another means of transport, the ticket handling device reads the information contained by the ticket. At first, it searches for the second seal from the information it has read. When it has found it, the ticket reading device checks the correctness of the second seal with regard to the file structure of the ticket. If the second seal confirms the information of the card, the ticket handling apparatus checks the validity information in the next step. If the validity information is in force and entitle to use the service, such as a means of transport, the boarding information of the ticket is updated.

A third example of using seals in an electronic ticket is, for example, buying a drink or a corresponding product during the interval of some event. The customer establishes a connection to the sales system with an NFC device, which may be a tele- phone provided with an NFC connection, by calling or sending some other message to a predetermined number. The sales system calculates from the identifier of the NFC device and the information content of the ticket wanted by the customer the first seal, which becomes a part of the ticket, and sends the ticket to the NFC device of the customer. At the product distribution point, the customer acti- vates the ticket and takes the NFC device to the range of operation of the ticket handling apparatus. The ticket handling apparatus recognizes the ticket and checks the correctness and validity of the ticket from the seal. The ticket handling apparatus calculates the second seal in its memory by means of the first seal it has broken and the sale information. The ticket handling apparatus marks the ticket as used by breaking the first seal in the NFC device in the same way as it was done for calculating the second seal and by writing the second seal on the ticket. After stamping the ticket as used, the customer gets his product. The sold tickets can be specified by the sale information to be valid only at a certain point of time, and therefore trying to copy them is of no use for the dishonest customer. This payment method would be useful in large public events in which there are no automatic teller machines available, and the use of payment cards would slow down sales. The case of this example can be further expanded by giving to the customer the right to return or exchange an unused ticket, i.e. one in which the first seal is intact. In addition, in such a purchase of a commodity it is possible to use only one seal, which is broken when the product is obtained, and the ticket becomes invalid.

Other applications of seals include inverse use of seals, i.e. the second seal is first calculated from the first one and the data, after which a new first seal can be calculated from the second seal and the data. Writing the new seal breaks the old seal at the same time. It is also possible to use a plurality of seals; in the case of four seals, for example, the first seal is used to calculate the second seal and to break the first one, the second seal is used to calculate the third seal and break the second one, and the third seal is used to calculate the fourth one and to break the third one. The seals can also be circulated, whereby three seals, for example, are used, i.e. the first seal is used to calculate the second one and to break the first one, the second seal is used to calculate the third one and to break the second one. The third seal is used to calculate a new first one and to break the second one. After this, the round starts from the beginning. These methods enable the implementation of a serial ticket, for example.

The seals also make it possible to return the unused ticket or change it for another product.

Some preferred embodiments of the invention have been described above. The invention is not limited to the above described solutions only, but the inventive idea can be applied in many ways within the limits defined by the claims.

Claims

1. A method for granting and checking the right of use of an electronic ticket, the right of use comprising a file structure on a product platform (20), the file structure further comprising the basic data of an electronic ticket and the information of the ticket application, and the file structure can be read, written and processed by the ticket handling apparatus (10), characterized in that at least part of the ticket information is protected

- in connection with the selling by a first seal, which is calculated by the ticket handling apparatus in connection with the selling (301) of the ticket from the basic data and the information of the ticket application (304) and written on the ticket (305),

in connection with the stamping of the ticket by the second seal, which second seal is calculated (310) by the ticket handling apparatus (10) in connection with the stamping of the ticket (306) from the basic data, the information of the ticket application and the broken first seal, and that

- In connection with the stamping, the ticket handling apparatus writes on the ticket on the product platform (20) the second seal, the broken first seal and the updated information of the ticket application (316).

2. A method according to Claim 1 , characterized in that at least the individual ID number of the ticket and of the information of the ticket application at least the sale information is used as the basic data.

3. A method according to Claim 1 , characterized in that the reading and writing measures are carried out by remote reading.

4. A method according to Claim 1 , characterized in that the seals are calcu- lated (304, 310) by the ticket handling apparatus (10) using some encryption method, the encryption keys of which are in the card handling apparatus.

5. A method according to Claim 1 , characterized in that for calculating the first seal (304), at least the individual ID number of the ticket and the sale information, which describe the properties of the ticket, are used for calculating the first seal, and that the first seal is used to protect the information of the ticket that has been used for calculating it.

6. A method according to Claim 1 , characterized in that for calculating the second seal (310), at least the individual ID number of the ticket, the information of the ticket application which has been updated in the stamping transaction, and the broken first seal are used for calculating the second seal (310), and that the sec- ond seal is used to protect the information of the ticket that has been used for calculating it.

7. A method according to Claim 1 , characterized in that when checking the correctness of the ticket (309, 311), the ticket handling apparatus (10) calculates the reference seal by means of the values it has read from the ticket and compares the calculated reference seal to the seal read from the ticket.

8. A method according to Claim 7, characterized in that the ticket handling apparatus accepts the ticket (309, 311), if the reference seal calculated in the ticket handling apparatus (10) corresponds to the seal read from the ticket, and rejects the ticket (314) if the calculated reference seal does not correspond to the seal read from the ticket.

9. A method according to Claim 6, characterized in that the first seal is broken in the ticket handling apparatus when calculating the second seal (310) by writing on top of the whole of the first seal or a part of it some predetermined values.

10. A method according to Claim 9, characterized in that the first seal on the ticket on the product platform is broken to correspond to the broken first seal used for calculating (310) the second seal.

11. A method according to any one of the claims 1 to 10, characterized in that in the ticket reading and stamping transactions it is first checked whether there is a second seal (308) on the ticket, and if a second seal is not found, it is checked whether there is a first seal (309) on the ticket, and when it has been found and accepted, a second seal (310) is calculated.

12. A method according to any one of the claims 1 to 11 , characterized in that in the ticket reading and stamping transactions, when a second seal is found, it is checked (311), and after it has been accepted, the information of the ticket appli- cation that had not been protected by a second seal is updated (312) when required.

13. A method according to any one of the claims 1 to 12, characterized in that the security of the ticket in connection with the reuse of the product platform, for example, is increased by taking into use a memory area of the product platform, which allows changing the values of the memory area only once, and that the values of this memory area are increased and also used for calculating (304) and checking (309) the first seal , and that this memory area is ignored when calculat- ing (310) and checking (311) the second seal, and if the product platform is reused, the values of this memory area are increased, and the increased values are used for calculating a new, first seal (304).

14. A method according to any one of the claims 1 to 12, characterized in that there may be more than two seals, and in the case of four seals, for example, the first seal is used for calculating the second seal and to break the first one, the second seal is used to calculate the third seal and to break the second one, and the third seal is used to calculate the fourth seal and to break the third one.

15. A method according to Claim 14, characterized in that when two or more seals are used, they can be circulated in such a way that, for example, the third seal is used to calculate a new first seal and to break the third seal.

16. A method according to Claim 1 , characterized in that the product platform (20) on which the ticket is, can be a remote-readable travel card, a contact card, a one-time card with a memory or a mobile communication device.

17. A ticket handling apparatus (10), which includes has a central unit (101), memory (102), communication unit (104) and means (103) for remote-reading from a product platform (20) the file structure of the ticket, for writing in the file structure of the ticket and for sending the ticket to the product platform, and which has been arranged to carry out ticket selling, stamping and checking measures, characterized in that the ticket handling apparatus has been arranged

- in connection with the selling

to calculate the first seal (304), which protects at least a part of the file structure of the ticket, which first seal has been arranged to be calculated from the basic data of the ticket and the information of the ticket application, and

- to write (305) the first seal to the ticket on the product platform, and

- in connection with the stamping to calculate the second seal (310), which protects at least a part of the file structure of the ticket, which second seal has been arranged to be calculated from the basic data of the ticket and the information of the ticket application and the broken first seal, and

- to write on the ticket on the product platform the second seal, the broken first seal and the updated information of the ticket application (316).

18. A ticket handling apparatus (10) according to Claim 17, characterized in that the selling, stamping and checking measures are arranged to operate in different card handling apparatus units.

19. A ticket handling apparatus(10) according to Claim 17, characterized in that it has been arranged, when required, to complement or in other ways to modify the file structure of the ticket it has read from the product platform (20) to comply with the requirements of the application in the ticket handling apparatus.

20. A ticket handling apparatus (10) according to Claim 17, characterized in that it has been arranged to calculate the seals (304, 310) programmably by using some encryption method.

21. A ticket handling apparatus (10) according to Claim 17, characterized in that it comprises a security module, into which the encryption keys required for calcu- lating the seals (304, 310) have been saved, so that the calculation could be carried out in a protected environment.

22. A ticket handling apparatus (10) according to Claim 17, characterized in that it has been arranged to check (309, 311) the correctness of the ticket on the product platform (20) by calculating a reference seal by means of values it has read from the ticket and by comparing the calculated reference seal to the seal read from the ticket.

23. A ticket handling apparatus (10) according to Claim 17, characterized in that it has been arranged to accept the ticket (309, 311) if the reference seal calculated by it corresponds to the seal read from the ticket, and to reject the ticket if the ref- erence seal calculated by it does not correspond to the seal read from the ticket.

24. A ticket handling apparatus (10) according to Claim 17, characterized in that it has been arranged to update (312) information of the ticket application that are not protected by seals, if it has found an accepted seal solution on the ticket.

25. A ticket handling apparatus (10) according to Claim 17, characterized in that it has a GPS positioning device (107) or a corresponding device providing location information.

26. A computer program product for checking and granting the right of use of the ticket, characterized in that it comprises

- computer program means for calculating (304) the first seal from the basic data of the ticket and the information of the ticket application in connection with the selling, and

- computer program means for calculating (310) a second seal from the basic data of the ticket, the information of the ticket application and the broken first seal in connection with the stamping of the ticket.

27. A computer program product according to Claim 26, characterized in that it comprises computer program means, which have been arranged to complement or in other ways to modify the file structure of the ticket read from the product platform.

28. A computer program product according to Claim 26, characterized in that it comprises computer program means, which have been arranged to calculate the seals (304, 311) by using a well-known encryption method.

29. A computer program product according to Claim 26, characterized in that it comprises computer program means, whiph have been arranged to check (309, 311) the seal of the ticket on the product platform (20) read by the ticket handling apparatus (10) by calculating a reference seal from the read file structure of the ticket and by comparing the reference seal to the read seal.

30. A computer program product according to Claim 26, characterized in that it comprises computer program means, which have been arranged to use more than two seals, and in the case of four seals, for example, the computer program has been arranged to use the first seal to calculate the second seal and to break the first seal, to use the second seal to calculate the third seal and to break the sec- ond seal and to use the third seal to calculate the fourth seal and to break the third seal.

31. A computer program product according to Claim 26, characterized in that it comprises computer program means, which have been arranged, when two or more seals are used, to circulate them in such a way that, for example, the third seal is used to calculate a new first seal and to break the third seal.

32. A product platform (20), which is electronically readable and writable and which has a central processing unit (201), a memory (202) and a RFID unit or a corresponding unit (203) enabling remote reading and writing, and for which a unique identifier can be generated and in the memory of which an electronic ticket can be saved, characterized in that the memory of the product platform has been arranged by means of its RFID unit (203):

- to receive in connection with the sale transaction (301) an electronic ticket, which consists of the basic data of the ticket, the information of the ticket ap- plication and the first seal (304) calculated therefrom, which is unique for each product platform and ticket, and

- to offer in connection with the checking or stamping of the ticket, the information of the ticket for reading (307) to the ticket handling apparatus (10), and

- to receive, in connection with the checking or stamping of the ticket, a second seal, the updated information of the ticket application and the broken first seal (316).

33. A product platform (20) according to Claim 32, characterized in that it is a remote-readable travel card, a contact card, a one-time card with a memory or a mobile communication device.