FI121323B - Procedure, ticket processing device, computer software product and product platform for an electronic ticket security mechanism - Google Patents

Description

Method, Flag Processing Device, Computer Software Product, and Product Platform for Electronic Flag Security Mechanism

The present invention relates to an electronically readable ticket, which may be a travel or access 5 ticket or a similar coupon exchangeable for a product or service, a method of protecting authenticity and features, implementing a security mechanism, a ticket processing device, a computer program product and a product platform.

The problem with electronically readable tickets, which can be for example in the form of one-time tickets, smart cards or portable communication devices, is that they should be both secure, that is, dishonest users would not be able to change or copy tickets or information, only after stamping and could be purchased in advance. In addition, the flag must be made, checked and stamped quickly. Such tickets can be used, for example, to pay for travel, admission tickets or to pay for products such as food or beverages at major public events.

WO 2004/015917 discusses the security of tickets sent via SMS. It generates a unique security code based on the time the SMS was sent, thus preventing the message from being copied or transferred to another platform. However, this does not allow the flag to be deployed in a flexible manner, i.e. at the desired time.

EP1439495 secures an electronic ticket with identification codes. The identification codes are generated separately using the product platform identification number, an external encryption key, and a random number generator. This method requires pal-25 counting and can slow down the ticket writing as well as its verification.

It is an object of the invention to provide a solution that can significantly reduce the drawbacks and disadvantages of the prior art. In addition, the invention facilitates, accelerates, and enables many new forms of trading.

The objects of the invention are achieved by a method, a hardware and a computer program, which are characterized in the independent claims.

2

Certain preferred embodiments of the invention are set forth in the dependent claims.

In the electronic flag security method of the invention, security is based on the protection of data structures by sealing. The electronic flag file-5 structure contains basic electronic flag information and ticket application information. This file structure is readable, writable and accessible by ticket processing devices, and at least some of the ticket application information is protected by seals. At the time of sale, the first seal on the ticket handler is calculated using basic ticket information and ticket application information and this first seal is written on the ticket. This si-10 web site protects the data with which it is calculated. The second seal is calculated when the flag is stamped on the ticket handler using the basic ticket information, updated ticket application information, and the broken first seal. When the second seal and the ticket application's updated information have been successfully written on the flag, the first seal broken will be replaced with the first seal damaged. When the flag is checked in 15 ticket handlers, the ticket handler calculates a reference seal of the value it reads from the flag, which it compares with the seal read from the card. If the reference seal and the read seal are similar, the flag will be accepted. If the reference seal and the read seal do not match, the ticket will be rejected. If the flag has been validated, the unsecured information on the flag can be updated. The ticket can be stored on a remote-readable 20 travel card, a contact card, a disposable memory card or a portable communication device.

The ticket processing device according to the invention has a central processing unit, a memory, a communication unit and means for remotely reading the ticket file structure from the product platform and writing the ticket to the file structure. The ticket handler can perform ticket sales 25 as well as stamping and checking. Sales and stamping and inspection procedures are usually performed in separate ticket handling units. For example, the point of sale may be physically very far away when purchasing a ticket for a portable communication device. At the time of sale, the ticket handler sets the sales information and counts the first seal, which it uses the basic ticket information and the ticket-30 application information that includes the sales information. The flag is written with the details of the flag application and the first seal that protects the data on which it was calculated. The basic flag information is usually set earlier, or it is a ready-made product platform feature, as is often the case with portable communication devices. Upon stamping, the ticket handler checks whether the ticket is already ready for another seal, i.e., whether the flag has already been stamped. If the second seal does not yet exist, the ticket handler first checks the correctness of the flag by lowering the reference seal and comparing it with the first seal of the flag. It then calculates the second seal using the updated ticket application information on the stamp, the card's basic information and the first seal broken. The flag processor then writes the updated ticket application information and the second seal to the flag on the product tray and then replaces the first 5 seals with the seal used to calculate the second seal. The ticket processing hardware is able to supplement or modify the file structure of the ticket it reads from the product platform if it is not in the format required by the ticket processing hardware. This allows multiple types of product platforms to be used in the same system.

The method of the invention is implemented by a computer program product having means for calculating a first seal from ticket master data and ticket application information at the time of sale, and a second seal from a ticket master data, ticket application information and breaking first seal upon ticket stamping. The computer program product operates on ticket processing equipment. The computer software product is adaptable to operate in ticket processing units for both sales and ticket inspection.

The electronic flag of the invention is deposited on a product platform that is electronically readable and writable, having a central processing unit, a memory and an RFID unit, or a similar unit for remote reading and writing, and having or having a unique identifier. The product platform memory, via its RFID unit, is arranged to receive an electronic ticket at the time of the sale, consisting of the ticket master information, the ticket application information, and this calculated first seal, unique to each product platform and ticket. It also provides the ticket information to be read by 25 card processors when checking or stamping the flag. In addition, it can receive a second seal, updated ticket application information, and a broken first seal when checking or stamping a ticket. This product platform is a remotely readable travel card, contact card, disposable memory card or portable communication device.

An advantage of the invention is that the use of seals increases the security of the cards. The advantage of the sealing method compared to the access keys is that the keys do not have to be distributed to the card, which is cumbersome, slow and can cause security problems. For example, for occasional users using NFC downloadable tickets, the method of sealing described by the invention is practically the only way to ensure the correctness of the product. Since the encryption keys used to calculate the seals are encrypted in the 35 card processors, unauthorized alteration of the data protected by them is difficult.

4

A further advantage of the invention is that this method speeds up the processing of the cards in the stamping and checking step. The convenience of use also results from the fact that the invention enables the product to be purchased in advance, since according to the invention the product can be made effective only at the time of stamping. It is also applicable to different devices and platforms, allowing multiple product platforms to be used in the same system.

Furthermore, the invention enables new ways of contactless commerce, which may include, for example, carrying out large-scale public events by-sales, such as food products, beverages, or the like, in accordance with the invention, which would facilitate and expedite their arrangement.

Another advantage of the invention is that it enables the return or replacement of an electronically purchased product. This opportunity increases customer confidence in the system.

The invention will now be described in detail. Referring to the drawings, reference is made to the accompanying drawings, in which Figure 1 illustrates an example flag ticketing device, Figure 2 illustrates an electronic ticket product platform according to the invention, Figure 3 illustrates a flowchart of the method according to the invention, Figure 4 illustrates a simplified file structure the use of seals at the electronic ticket file structure level.

An example of utilization of the method according to the invention is illustrated in the ticket licensing and verification scheme and the verification method utilized therein. The ticketing system of the invention uses seals to increase the safety and convenience of electronic ticketing. The following describes, by way of example, the handling of a disposable card application for public transport 30 and other examples. In the following, when referring to the disposable card application in the first example, it will be referred to as a flag. In the future, when used to refer to a one-time card application or other ticket purchased through an electronic service providing access to a service or product, it will be referred to as that ticket. The device that carries this flag is called the product platform. Devices for reading and writing tickets on a product platform, editing ticket information and checking access to it, as well as selling and stamping operations 5 are called ticket processing devices.

Figure 1 illustrates, by way of example, a ticket handling device 10 according to the invention. It may be, for example, a means for checking and recording a travel device in a travel device. Preferably, it comprises a central processing unit (CPU) 101 in which the ticket access control and grant procedures required by the method of the invention are performed. The central processing unit may utilize the memory 102 to execute the program according to the invention and to store the results thereof.

The ticket processing device 10 also includes an RFID unit 103. It allows the ticket processing device to exchange messages with an item to be checked, such as a remote readable travel card 203, a contact card or a portable communication device. The RFID unit 103 of the Li-15 bite handler comprises both a transmitter and a receiver. In the first step, the transmitter activates, for example, a remote-readable travel card. In a second step, the receiver receives the information transmitted by the travel card 203. In the third step, 203 new information is written on the travel card. This information preferably comprises the write commands of the seals according to the invention. 20 Similarly, the travel card can store, for example, validity information.

Advantageously, the ticket processing device of the invention may include a GPS positioner 106 which receives positioning information from satellites 107. Location information can be utilized to verify access rights.

The ticket processing device according to the invention may also comprise a communication unit 104 through which it can exchange information with an information system included in the travel card system (not shown in Figure 1). The data link 105 may be either a wireless or a wired data link. The data connection may be used to update, for example, user or location information or software for a checking device. The ticket processing device may also include a display or similar indicator that informs the customer of the processing steps of the li-30 and his ticket characteristics, such as how long the ticket is valid, or an audio or light signal indicating whether the ticket was successfully stamped or verified.

Figure 2 illustrates the functional main parts of an exemplary remote-readable travel card 20. The card has a central processing unit (CPU) 201 which is capable of reading from memory 6202 and writing to memory 202. Preferably, the electronic ticket is in the memory of the travel card. The travel card 20 consumes an RFID unit 203 which enables the travel card to receive information from, for example, the ticket processing device 10 from the RFID unit 103. The travel card RFID unit 203 also allows the travel card to send ticket information stored in the memory 202 of the travel card 20. This information may preferably comprise travel rights information as well as seal information according to the invention.

The flag file structure read from the product platform is supplemented and modified to meet the requirements of the flag handling application in the ticket processing device in the ticket processing device memory. This means that the file structures of the flags need not necessarily be the same, but several different platforms may be used in the same system.

Fig. 3 is an exemplary flow diagram of the method according to the invention. The method is described step by step.

In step 301 of Figure 3, the ticket is sold, whereupon the ticket-handling device carrying the sales actions begins to prepare the ticket for transfer to the product platform. In step 302, the flag is initialized, i.e., provided with basic information according to the product platform and application. In step 303, the ticket sales information is set. Then, in step 304, a first seal is calculated on the flag, after which the flag can be written on step 305 to the product platform.

In step 3 of Figure 3, the flag is stamped. In step 307, the flag values are read from the product platform to the ticket processing device. Step 308 checks to see if another seal is found in the values read. If the answer is ΈΙ, then step 309 checks whether the first seal of the flag is valid. If the first seal is found to be okay, i.e., the answer at step 309 is "YES", proceed to step 310 where a second seal is added to the flag, followed by a second seal and updated information at step 316 to the product board flag and terminating the stamping operation.

If, in step 309 of Figure 3, the first seal is found to be invalid, i.e., the answer is "NO", proceed to step 314 where the flag is rejected. The stamping event-30 m is terminated to step 315.

If, in step 308 of Figure 3, a second seal is found on the flag, the answer is "YES" and proceed to step 311 where the second seal is checked. If the second seal is found to be invalid, i.e., the answer is "NO", proceed to step 314, where the flag is rejected. The stamping event is terminated to step 315.

7

If, in step 311 of Figure 3, a second seal is found to be valid, i.e., the answer is "YES", proceed to step 312 where the updated flag information is written to the product platform. The stamping event is terminated to step 313.

According to Fig. 4, the file structure of the ticket is divided into two parts: the flag information (Applicationlnformation) and the ticket application (eTicket). The ticket application consists of sales information (Salelnformation), first seal, validity information (Validitylnformation), second seal and usage information (Boardinglnformation). Basic ticket information is set during the initialization of the ticket, which may take place at or before the sale. The basic information shall contain a series of digits that uniquely identify the flag, that is, 10 identification numbers. This identification number is formed, for example, from the travel card chip number provided by the manufacturer. The identification number is different for each product platform unit, or there is so much variation that its dishonest use is almost impossible.

The sales information includes the characteristics of the purchased item, in this case the ticket, such as the quality of the ticket, date of sale, period of validity, period of validity, price and other attributes. Sales information is protected with a first seal, which ensures that the information is authentic and unmodified and verifies that the information is on the original product platform. The first seal is counted upon sale. The sales transaction records the sales information on the initialized ticket 20 and the first seal calculated in the sales system. The remainder of the ticket application area where spaces for validity information, second seal, and usage information are reserved is written as zero. The sale is made with a ticket processing device for sale. For example, sales can take place either at the point of sale or at the vending machine.

25 There are many ways to calculate a seal. Preferably, the seal is calculated using a 3DES key in accordance with ISO 9797. The ticket processing device may calculate the seals programmatically or may include a security module in which the encryption keys are stored, and the calculation is performed in a secure environment. Basic ticket information and sales information are required to calculate the first seal. This can be done by using the pel-30 hand identification number and sales information. Because the information content from which the first seal is compiled includes a unique product tray identification number, it is not possible to create a functional copy of the ticket information on the second product platform.

The flag handling device for checking and stamping operations checks and stamps the flag and, if necessary, lowers a new seal. The ticket handling device may be located in the vehicle where the ticket was purchased for travel, or at the dock, station or 8 similar spaces that provide access to the vehicle. The first time the flag is stamped, it is brought close to the ticket handler, whereby the ticket handler reads from the product platform the ticket information, which in this case is basic ticket information, sales information and first seal. It examines whether the flag has another seal, which 5 would mean that the flag has already been stamped. If no other seal is found, the first seal is searched. After the first seal is found on the ticket, it is checked whether it corresponds to the basic ticket information and sales information. This is done by calculating the first seal in the ticket handler memory with the values listed there, in the same way as it was done in the sales system at the time of sale. This calculated first si-10 web is called a reference seal. The reference seal is compared to the first seal read from the flag. If they are the same, the file structure of the flag is accepted. This checks the authenticity and integrity of the sales information and whether it is on the right product platform. If the ticket has valid sales information according to the first seal, validity information is generated. If the ticket has been sold for the first time it enters into force, the validity of the ticket at the first stamping is calculated based on the time of the ticket handler and the length of validity of the ticket sales information.

The ticket handler calculates the second seal using the basic information read from the ticket, the sales data, the first seal and the validity information. For the counting of the second seal, the first seal is broken in the memory of the ticket handler. This can be done by writing numerical values either over all or part of the first seal. The breaking values of the first seal are predefined and can be, for example, zeros or random numbers. The second seal is calculated in the same way as the first seal. Now counting uses the encryption key 25 of the ticket handler and the ticket master data and sales data read from the ticket, as well as the first seal broken in the ticket handler. The second seal of the ticket ensures the authenticity and immutability of the validity information. The stamp is also marked with information about the use of the flag, which tells where and when the flag was used. The contents of the usage data are not protected by sealing.

30 When the validity information and the second seal, as well as the usage information, are written on the flag on the product tray and the success of the writing is confirmed by a countdown, the corresponding values used when calculating the second seal on the ticket handler are overwritten. This breach of the seal will invalidate the sales information and at the same time validate the validity information. 35 Sales Validation will ensure that resetting 35 does not restore sales. The other 9 seals cover not only the validity information but also the sales information and basic ticket information, thus ensuring their authenticity and integrity.

If the vehicle is changed during the period of validity of the flag, it is again stamped with a slipper. The ticket handler reads the ticket information. It checks whether the flag 5 has another seal, i.e., it has already been stamped. Upon finding it, the ticket handler checks to see if this second seal matches the ticket's basic and validity information. The check is made in the memory of the ticket handler by calculating a reference seal from the read flag information and comparing this reference seal with another seal read from the card. If one seal is accepted, that is, it is found that the reference seal and the other seal are the same, the change made to the flag usage information is added.

Validity information can also be set at the time of purchase. They may be effective for a specified period of time from the time of sale or for a specified period in the future. This time-limited sale can be used, for example, to sell travel tickets for an event. This event 15 may be, for example, a multi-day sporting event with sub-events taking place throughout the area of use of the tickets. If the validity information is set at the time of sale, the first seal is not counted but placed directly in the violated space, which may be zero, and then the second seal is counted as described above.

Because the encryption keys needed to count and verify seals are only found in sales systems and card processing equipment, it is difficult for a dishonest user to tamper with seals.

Figure 5 illustrates in more detail the use of seals at the file structure level. Functionality may vary according to the requirements of the product platform or the intended uses of the product (flag). The method described follows the file structure of 25 single-card applications adapted to the Mifare Ultralight platform. The graphs describe the contents of the file structure in the computational processes. The chart is inaccurate and should not be used to describe the bit structure of the file structure.

Mifare Ultralight cards are read and write media with segmented memory and blocks of memory. Remote access to cards is based on ISO 14443 30 technology. The cards have 512 bits (64 bytes) of memory. Some of the memory space is required by the format, the rest is in use by the user application. Although this example uses the Mifare Ultralight card, the described file structure and its use are easily adaptable to other platforms.

10

Figure 5 shows three different states of the file structure of the one-time card application flag. Paragraph (a) (SEAL1) describes the situation when the ticket is purchased. Point b) (SEAL1 & 2) describes the situation when the flag is being stamped. Paragraph (c) (SEAL2) describes the situation when the flag has been stamped and traveled. The file structure illustrated has 5 blocks of 63 in use, divided into eight segments. The segments are named D1, D2, D3, D4, D5 and D6 in Figure 5. Segments D7 and D8 have been left unnamed for image functionality. There are 8 blocks reserved for each segment, except for the last segment D8, which in this case is reserved 7 blocks.

10 Figure 5 (a) contains the file structure of the purchased and unused one-time ticket application. The segment D1 contains the card serial number assigned by the card manufacturer (blocks 1-7, designated SN0-SN6). At the end of segment D1 and at the beginning of segment D2, blocks 8, 9, 10 and 11 have a One Time Programmable (OTP) area of the card. You can only write to this area once because its bits cannot be reset from UN-15 to zero. This feature is used to improve ticket security.

Segment D2 and part of segment D3 include basic flag information, such as flag identification information, application version numbers, application owner identifiers, and the like. This basic information is provided when the flag is initialized. This can be done in advance or when purchasing a ticket. The card's unique identification number (ApplicationSerialNumber) is stored in blocks 18, 19 and 20 in segment D3. The card chip serial number provided by the manufacturer is used to calculate this identification number. Sales information for the product at the time of purchase. These are set to match the product the customer is buying. If the basic and sales data do not fill up the space reserved for the nil, then the empty space is supplemented with values of a predetermined type. These may be zeros or other suitable values depending on the application. The method used to calculate the seals, ISO 9797, requires that the area to be counted is completed by multiples of 8 bytes, that is, by eight blocks of bytes. The standard also defines a replenishment mechanism. In the case of Fig. 5 (a) ta-30, the positions to be completed have been blocks 21,31 and 32.

Before the sales information is written on the ticket, the first seal is counted. This is calculated in the sales system from the data content of the card, which includes the card serial number, basic information, and sales information. The seal is preferably calculated using a 3DES key in accordance with ISO 9797. Because this encryption key is only present in sales systems and ticket processing equipment, even fraudulent counting of seals is, if possible, cumbersome and time consuming. Because the information content used to calculate the seal includes a unique identifier for the card, it is not possible to create a functional copy of the content of the ticket on another product platform, which may be another card or other device, but the sales information protected by the seal only works on the product platform on which it is placed.

5 When the sales information and the first seal are completed in the sales system, they are written on the ticket on the card. Basic ticket information and sales data are placed in segments D2, D3 and D4. The first seal of the flag is placed in a segment D5 having blocks 33-40 named Datal 8-Data25 in Figure 5. The rest of the file structure, segments D6, D7 and D8, is written in full zeros. After typing, the file structure of the ticket is ready for use. In a sales system, the calculated ticket file structure may not be completely written as such, but the physical card's memory capabilities may set limits. This does not cause any problems, since when reading the file structure of the flag on the card to the ticket handler for stamping, checking or any other operation, they are supplemented with the format required by the application. This contributes to the risk of misuse of the flag.

The seal may be made by any other method. In such cases, it may not be necessary to supplement the underperforming segments.

Figure 5 (b) shows the file structure of the one-time ticket application when the ticket is being stamped for the first time. The card contained in the flag is brought near the flag handling device for stamping. The ticket handler reads the file structure of the ticket, which in this case is the serial number, basic information, sales information and first seal. First, the ticket handler looks for a second seal, i.e., a previously sealed one. When a second seal is not found in this case, the li-25 puncture handler checks whether the read file structure of the flag matches the first seal. This is done by counting the first reference seal corresponding to the seal in the memory of the sheet processing device and comparing it with the read value. If the ticket handler accepts the first seal, that is, the sales information is found to be valid, intact, and the validity of the ticket 30 is formed on the product platform to which the product is sold. Validity information includes the validity of the ticket based on the time of the ticket handler and the length of time read from the sales information. If the validity information does not occupy the space reserved for it, the empty space is supplemented with values of a predetermined type as described in (a). In the case described in (b), one 35 blocks of values are added to the validity information in block 48 to fill in segment D6.

12

Before the validity information is written on the flag, a second seal is counted on the ticket handler. In practice, the second seal is lowered in much the same way as the first seal. In the second seal count event, the first seal is broken in the ticket handler memory. In this case, it is done by setting the third, fourth, fifth and sixth blocks of the segment contained in the first seal preferably to zero. Now, the data content of the ticket from which the seal is counted includes, in addition to the information needed to calculate the first seal, the validity information and the first seal broken. The second seal is calculated with the 3DES key on the ticket handler according to ISO 9797 standard. The second seal thus covers, in addition to the basic and sales information, the first seal broken and the validity information.

Once the ticket handler has calculated from the ticket information it reads both the validity information and the second seal, these can be written to the ticket on the card. The validity information is written to segment D6 and the second seal is written to segment D7. The file structure of the flag is now similar to Figure 5 (b).

Once the validity information and the second seal are written on the card on the card, the ticket handler checks them by reading them and comparing them with the values in the memory. Once the write transaction is confirmed, the first seal is broken to correspond to the broken seal used to calculate the second seal. In this case, the flag is written on the flag to blocks 35, 36, 37 and 38 of segment D5 containing the first seal. Because the flag on the card may have slightly different file structure shapes than the flag handler, locations may not be in the same position on the flag. This write command breaks the first seal so that the sales information is no longer valid. At the same time, this write command also aligns the information content of the li-25 pun with the information content used to compute the second seal. Now, one seal matches the information on the card, so the authenticity and integrity of the ticket can be checked with another seal. The cancellation of sales information ensures that resetting the validity information and the second seal does not restore the sales information to the validity. The situation described here corresponds to Figure 5 c). Thereafter, the usage information is written on the ticket, where and when it is used. Usage data is generated by the position and time of the ticket processing device. Usage data is in segment D8. In this case, they fill in blocks 57-59 of segment D8. The information is intended primarily for ticket verification purposes and is not protected by sealing.

35 If a card such as the one described above is to be reloaded safely and otherwise increases the security of the ticket on the card, OTP area 13 (One Time Programmable) will be enabled. This is 32 bits long. The ticket sales transaction will check the status of the OTP area. If all bits in the region are set, that is to say one, the card is considered to be exhausted and no sales for this card are allowed. If the area is empty, ie all bits are zero, this is the first sale for a ky-5 card. In this case, in the first transaction, the value of the OTP range is written on the card as OxCOOOOOOO, i.e. the top two bits of the OTP range are set to one. The first seal of the ticket is calculated as in the previous example from the card serial number, ticket basic and sales information, but now includes the OTP area information. When the flag is first stamped, that is, the second 10 seals are counted, the OTP area is either not counted or set to zero in the ticket handler. When the validity information and the second seal are written to the flag, the OTP area data content, i.e. the bit order, is rotated one step to the left in the ticket handler memory so that the first value becomes the last, and the resulting new value is written to the OTP area. Since the bits in the OTP range cannot be paired back to zero, the top two bits of the OTP range remain number one and the lowest bit goes to number one, that is, 0xC0000001. When a flag is re-stamped, its file structure is read into the memory of the flag handler and can set the OTP range to zero or, alternatively, ignore it when calculating the reference seal for verification. When you want to re-use a card for a sale, that is, when you buy a new product, it is discovered that not all bits in its OTP range are zero, so you do not need to set a default value. The OTP range value, in this case 0x00000001, is used to calculate the first seal of the new product file structure, among other values. In the next validity information setting, the OTP domain data content, i.e. the bit order, is rotated 25 again in the ticket handler memory one step to the left. Now the first two and the last two values of the OTP range are number one. This value is written in the OTP area of the card. This can be continued until all bits in the OTP range are one. The card is then used up and the customer must obtain a new card. This method allows the card to be reloaded 30 times. Because the validity information setting changes the content of the OTP area after the validity information has been set, and the OTP area is included in the first seal, returning the sales information to the card does not constitute new valid sales information. Other values may also be set as the default value for the OTP area when the card is first sold. If set to 0x00000000, there is no restriction on reusing the card. If set to OxFFFFFFFE, the card will only be available once. Other types of OTP domains and similar solutions can also be used. Their use is quite similar to the one described.

14

The steps described by the method of the invention may be implemented by a program stored in the memory of the ticket processing device and executed in the central unit of the device.

As another example, a flag application is described using a NFC (Near 5 Field Communication) device as a product platform, which may be a telephone, a handheld computer or the like. The flag application data structure as described above can be hosted on an NFC device that operates via the NFC interface according to ISO 14443. In addition, the product platform must have a unique identification number, which must be electronically readable, and the application must have sufficient memory-10 capacity to store the flag application. In this case, the flag application can be used in the same way as the application on the card via the NFC interface.

The flag application's file structure is designed to be downloadable to the NFC device. When the device is contacted with the sales system, the device identification number is transmitted in the ticket purchase request. When purchasing a ticket, the sales system calculates the first seal of the device identification number and ticket sales information. The first seal is calculated using a 3DES key in the ticketing system of the sales system, in accordance with ISO 9797. This seal confirms the accuracy and integrity of the sales information and can verify that the ticket is on the original product platform. The sales system generates a sealed ticket product according to the product you are purchasing, which is sent back to the NFC device, for example, as a single file. Data transmission can also take the form of SMS messages encoded as SMS messages. In this case, the NFC device must have an application program that converts the character-encoded SMS files to the format required by the ticket product.

25 When a flag is used, an NFC device with a ready-to-use flag application is stored near the flag handler for stamping the flag. The ticket handler reads the ticket information via the NFC interface. First, the ticket handler checks if the ticket has another seal, i.e., whether the flag has already been stamped. If there is no second seal, look for the first seal. When this is found, the ticket processing device checks the first seal based on the information it reads. The first seal is checked in the ticket handler memory by calculating from the read values, which are the device identification number and the ticket sales information, a reference seal corresponding to the first seal in the same way as when purchasing a ticket in the sales system. This reference seal is compared to the first seal read. If they coincide, it means that 35 seals are in effect. If checking the first seal indicates that the ticket is valid and valid, validation information is generated in the ticket handler and a second seal is calculated. NFC device identification, sales information, expiration information, and first seal broken are required to calculate the second seal. The first seal can be broken in the ticket handler memory by writing pre-agreed values on the seal or on the seal portion. These values may be, for example, zeros or random numbers. Crucially, these same values will be used later when breaking the first seal from the flag application in the NFC device memory.

Preferably, the second seal is counted in the ticket processing device with a 3DES key in accordance with ISO 9797. In addition to the basic and sales information, this seal covers the first 10 seals and ticket validity information. The validity information and the second seal are written to the ticket application on the NFC device. Once the write success is confirmed by a countdown, the first seal is broken by writing to its memory area the same values as were made in the ticket handler memory when calculating the second seal. This entry invalidates the sales information, thus breaking the seal, but at the same time validates the validity information with another seal. This second seal can be used to verify the validity and validity of the ticket, for example in the event of a change of vehicle in the case of a ticket. At the same time, the ticket will be written with usage information that is not protected by a seal.

When the flag is stamped a second time, for example when changing a vehicle, the flag-20 processing device reads the information contained in the flag. It first looks for another seal in the data it reads. Once found, the ticket reader device checks the authenticity of the second seal for the flag file structure. If the second seal confirms the card information, the ticket handler next checks the validity information. If the validity information is valid and entitles you to use a service such as a vehicle, the usage information for the 25 tickets will be updated.

A third example of using seals on an electronic ticket is, for example, buying a drink or similar product during the interval of an event. The customer contacts the NFC device, which may be a NFC-enabled telephone, by calling the sales system or sending another message to a predefined number. 30 The sales system calculates from the subscriber's NFC device identifier and the content of the customer's desired ticket the first seal to be included in the ticket and sends the ticket to the customer's NFC device. At the product distribution point, the customer activates the ticket and takes the NFC device to the ticket handler. The ticket handler recognizes the ticket and checks the correctness and validity of the ticket. The Las-35 ticket handler uses a first seal and sales information to break a second seal in its memory. The flag handler marks the flag as being used by breaking the first seal on the NFC device 16 in the same way as it did for lowering the second seal and writing a second seal on the flag. After stamping the ticket for use, the customer receives their product. The tickets sold can be configured with sales information to be valid only at a particular time, so trying to copy them is not helpful to 5 dishonest customers. This method of payment would be useful in large public events where ATMs are not available and the use of payment cards would slow down sales. The example case can be further expanded by giving the customer the right to return or exchange an unused ticket, i.e. one whose first seal is intact. In addition, in such a purchase of a commodity, it is possible to use only one seal, thereby breaking it upon receipt of the product and invalidating the ticket.

Other applications of seals include the inverse use of seals, i.e., first calculating a second seal from the first and data, and then calculating a new first seal from the second seal and data. Writing a new seal breaks 15 old seals at the same time. Multiple seals may also be used, for example, in the case of four seals, the first seal will lower the second seal and break the first, the second seal will lower the third seal and break the second, and the third seal will lower the fourth and break the third. The seals can also be rotated using, for example, three seals, i.e., the first seal is used to lower one and break the first, the second seal to lower the third and break the second. The third seal counts the new first and breaks the second. After that, the tour starts again. In these ways, for example, a serial ticket can be realized.

With the help of seals it is also possible to return or exchange an unused ticket 25 to another product.

Some of the preferred embodiments of the invention have been described above. The invention is not limited to the solutions just described, but the inventive idea can be applied in numerous ways within the scope of the claims.

Claims (33)

17 A method for granting and verifying access to an electronic ticket, comprising the file structure on the product platform (20), the file structure further comprising basic electronic ticket information and ticket application information, and the file structure being readable, writable and manipulated by ticket processing devices (10) at least a portion of the ticket information is protected - upon sale with a first seal, the first seal being calculated by the ticket handler at the ticket sale (301) from basic information and ticket application information (304) and written on the ticket (305); 310) with the flag handling device (10) in the process of stamping the flag (306) with basic information, flag application information and a broken first seal, and that - in the case of stamping, the flag handling device writes on the product platform (20) e for a second seal, a broken first seal, and updated ticket application information (316). 2. Förfarande enligt patentkrav 1, kännetecknat därav, att som Grund-information giving information on individual information and identification of information. Method according to Claim 1, characterized in that at least the unique identifier number of the ticket is used as basic information and at least the sales information of the ticket application information is used. 3. Förfarande enligt patentkrav 1, kännetecknat därav, att avläsnings- och 5 skrivningsätgärderna görs med fjärravläsningsteknik. 3. A method according to claim 1, characterized in that the reading and writing operations are carried out by means of remote reading. 4. Förfarande enligt patentkrav 1, kännetecknat därav, att sigillen beräknas (304, 310) med biljettbehandlingsanordningen (10) genome annvändning av avgot krypteringsförfarande, stem förfarandes chiffernycklar finns i biljettbehandl. 10 5. Förfarande enligt patentkrav 1, kännetecknat därav, att account det första sigillets beräknande (304) anvätänät ätminstone biljettens individuella identifierings och försäljningsinformation, vista beskrevensen egenskaper, och att med det första anv. att beräkna det. 15 6. Förfarande enligt patentkrav 1, kännetecknat därav, att account det andra sigillets beräknande (310) används ätminstone biljettens individella identifierings, biljämpningensens som uppdaterats i stämplingshändelsen og det brutna första söret. , som har använts för att beräkna det. 20 7. Förfarande enligt patentkrav 1, kännetecknat därav, att biljettbehandlings anordningen (10) dä den controllerer rjjjulet riktighet (309, 311) beräknar et jämförelsesigill med hjälp av aven den från från från från från från från. biljett. Method according to claim 1, characterized in that the seals are counted (304, 310) by the ticket processing device (10) using some encryption method, the method of which encryption keys are in the ticket processing device. Method according to claim 1, characterized in that at least a unique ticket identification number and sales information describing the characteristics of the ticket are used to calculate (304) the first seal and that the first seal is used to protect the ticket information used to calculate it. Method according to claim 1, characterized in that the second seal 30 is counted (310) using at least the unique identifier number of the flag, the flag application information updated at the drawing event and the first seal broken, and the second seal protecting the flag information used to calculate it. . 18 A method according to claim 1, characterized in that the ticket processing device (10), when checking the correctness of the flag (309, 311), calculates the reference seal from the flag by reading its values and compares the calculated reference seal to the seal read from the flag. 8. Förfarande enligt patentkrav 7, kännetecknat därav, att en kortbehandlings-25 anordning godkänner biljetten (309, 311), om det i biljettbehandlingsanordningen (10) berämnar jämförelsesigillet motsvarar det frän biljetten avlästa jämförelsesigillet inte motsvarar det frän biljetten avlästa sigillet. A method according to claim 7, characterized in that the card processing device accepts the flag (309, 311) if the calculated seal in the ticket processing device (10) matches the seal read from the flag, and rejects the flag (314) if the calculated comparison seal does not match. seal read from the flag. 9. Förfarande enligt patentkrav 6, kännetecknat därav, att det första sigillet 30 bryts i biljettbehandlingsanordningen dä det andra sigillet beräknas (310) genome att scrivel helt eller delvis end första sigillet face förhand bestämden. 24 Method according to claim 6, characterized in that the first seal is broken in the ticket processing device by lowering (310) by writing all or part of the predetermined values over the first seal. Förfarande enligt patentkrav 9, kännetecknat därav, att det första sigillet header of the product platform bryts för att motvarvara det brutna första sigillet som använts för att beräkna (310) det andra sigillet. The method of claim 9, characterized in that the first seal on the flag on the product tray is broken to correspond to the broken first seal used in the lowering (310) of the second seal. 11. Förfarande enligt patentkrav 1-10, kännetecknat därav, att i biljettens av-5 läsnings- och stämplingshändelser Controller Först om biljetten har ett andra sigill (308), och ifall ett andra sigill inte finns, Controller om fjörgen 309), efter vars finnande and godkännande det andra sigillet beräknas (310). A method according to claims 1-10, characterized in that the flag reading and stamping operations first check whether the flag has a second seal (308) and, if no second seal is found, checking whether the flag has a first seal (309) which can be found and accepted. then calculating a second seal (310). 12. Förfarande enligt patentkrav 1-11, kännetecknat därav, att i biljettens av-läsnings- och stämplingshändelser, da det andra sigillet hit, controller 10 (311) og efter godkännande uppdateras (312) vid behov den del aving information , som inte hade skyddats med det andra sigillet. Method according to claims 1-11, characterized in that, in the event of reading and stamping the flag, when a second seal is found, it is checked (311) and, after approval, the information of the flag application which was not protected by the second seal is updated (312). 13. Förfarande enligt patentkrav 1-12, kännetecknat därav, att biljettens Säker-het account exempel vid äteranvändning av producplattformen eco genome attagnier för productplattformen; detta minnes-omrädes larvae och även används för beräknande (304) och controllereran-de (309) av det första sigillet och att vid beräknandet (310) och controllingerandet (311) av det andra sigillet tas detta minnesomräde inte i beakt even-tuell äteranvändning av produkterplattformen utökas detta minnesomrädes väder, 20 lively urticaria avvänds vid beräknandet av fösta första sigill (304). A method according to claims 1-12, characterized in that the security of the flag 25 is increased, for example, by reusing the product platform by providing a product platform memory area that allows only one change of memory space values, and increasing and also utilizing this memory area value (304) and checking (309), and calculating (310) and checking (311) the second seal, ignoring this memory area and, if any, reusing the product platform, incrementing the values of this memory area used to compute the new first seal (304). 19 14. Förfarande enligt patentkrav 1-12, kännetecknat därav, att det kan finnas fler änly sigill, colors man till exempel i et fall av fyra sigill med det första sigillet beräknar det andra sigillet och bryter det första, med det andra sigillet beräkn tredje sigillet och bryter det tredje 25 and och bryter det tredje. Method according to claims 1 to 12, characterized in that there may be more than two seals, for example in the case of four seals the second seal is lowered and the first seal is broken, the second seal is lowered the third seal and the second seal is broken third. 15. Förfarande enligt patentkrav 14, kännetecknat därav, att da tvä eller fler sigill använd, in the case of suffering from a fever, a sigillet beräknar et första sigill och bryter det tredje. Method according to claim 14, characterized in that, when two or more seals are used, they can be recycled such that, for example, a third seal is used to lower a new first seal and break the third. 16. Förfarande enligt patentkrav 1, kännetecknat därav, att produkplattformen 30 (20), finns billin finns, kan assets et fjärravläsbart resecort, that contact card, eng engskskort med where eller en bärbar datakommunikationsanordning. A method according to claim 1, characterized in that the product tray 10 (20) carrying the flag may be a remote readable travel card, a contact card, a disposable memory card or a portable communication device. 17. Biljettbehandlingsanordning (10), som har en centralenhet (101), where (102), en telecommunicationenhet (104) samt medel (103) för att fjärravläsa biljettens filstruktur frän productplattformen (20), för att skriva pä biljettens filstruktur samt för att sunda biljetten till productplattformen, ooh som är anordnad att utföra biljetternas försäljnings- samt stämplings- samt controller ringgate, snap-tecknad därav, att biljettbehandlingsanordören för sordnad att 5 ätminstonestone en av bilj enj deljj fil fil fil fil fil filig fil fil fil fil,,,,,,,,,,,,,,,,,,, vil,,,,,,,,, vil vil vil vil vil vil 10. vil vil vil vil vil vil vilmin vil skr o 30 30 vil o ,min 10.,,,,,,,, skr 30, ,min, 30 10. 30, 10., 10. skr skr 30 10. 10. skr skr skr skr skr 10., skr skr skr skr skr skr skr skr 10. skr skr skr skr skr skr skr skr skr skr 10. skr skr skr skr skr skr skr skrpl - sam sam - sam sam sam sam sam sam sam sam sam sam sam sam sam sam sam sam sam i i - - - sam sam sam sam - - i i i sam i i - i sigill (310) som skyddar ätminstone en del av biljettens filstruktur, whisker andra sigill är anordnat att 15 beräknas frän bilensens grundinformation ooh biljett-illämpningens information samt frän det brutna första sigillet, ooh - scriva head of productunderlaget stock biljetten det andra sigillets, det brutna första sigillets samt biljett- 20 tillämpningens uppdater. A ticket processing device (10) having a central processing unit (101), a memory (102), a communication unit (104) and means (103) for remotely reading a ticket file structure from a product platform (20), writing a ticket to a file structure and transmitting a ticket to the product platform. to perform ticket selling, stamping and checking operations, characterized in that the ticket processing device is configured - at the time of sale - to calculate a first seal (304) protecting at least a portion of the ticket file structure, the first seal arranged to be calculated from the ticket master data and ticket application data; write (305) a first seal on a product platform flag and - upon stamping 25. compute a second seal protecting (310) at least a portion of the file structure of the flag, the second seal arranged to be counted from the flag data and ticket application data and the breached first seal; a ticket on the product platform with a second seal, a broken first seal, and updated ticket application information (316). 20 18. Biljettbehandlingsanordning (10) enligt patentkrav 17, kännetecknad därav, att försäljnings- samt stämplings- ooh controlling the ringgate and funger of an oljbordlingsanordningsenheter. A ticket handling device (10) according to claim 17, characterized in that the sales, stamping and checking operations are arranged to operate in different ticket processing device units. (10) Enhancements (10) en patent code 17, transducer code 25, an embodiment of an embodiment of an embodiment of a modifying structure and a layout of the product platform (20) of an embodiment of an embodiment of a method. The ticket processing device (10) according to claim 17, characterized in that it is arranged, if necessary, to supplement or otherwise modify the file structure of the flag it read from the product platform (20) to the requirements of the application in the ticket processing device. 20. Biljettbehandlingsanordning (10) enligt patent krav 17, kangnetecknad därav, att den ar anordnad att beräkna sigillen (304, 310) programmassigt genome användand dande av nägot chiffreringsförfarande. A ticket processing device (10) according to claim 17, characterized in that it is arranged to lower the seals (304, 310) programmatically using any encryption method. 21. Biljettbehandlingsanordning (10) enligt patentkrav 17, kännetecknad därav, att den omfattar en sækerhetsmodul, color de för beräknande av sigillen (304, 310) 26 behövliga krypteringsnycklarna år skårfør, för att beräknadas skiv utf. The ticket processing device (10) according to claim 17, characterized in that it comprises a security module in which the encryption keys necessary for the counting of the seals (304, 310) are stored so that the counting can be performed in a protected environment. 22. Billet rendering (10) enligt patent krav 17, kangnetecknad därav, att den and anordnad att controller (309, 311) den end productplattformen (20) vande biljettens riktighet genom att beräkna et jämförelsesigill med hjälp av för biljetten och jämföra det beräknade jämförelsesigillet med sigil-let den Läst frän biljetten. The ticket processing device (10) according to claim 17, characterized in that it is arranged to check (309, 311) the correctness of the flag on the product platform (20) by calculating the reference seal from the flag by reading its values and comparing the calculated reference seal to the flag. 23. Biljettbingsandlingsanordning (10) enligt patentkrav 17, kennettecknad därav att den är anordnad att godkänna biljetten (309, 311), om dess beräknade jämfö- 10 relsesigill motsvarar sigillet som avlästs frän bilen, och att avslä. jämförelsesigill inte motsvarar sigillet som avlästs frän biljetten. A flag handling device (10) according to claim 17, characterized in that it is arranged to accept a flag (309, 311) if the reference seal it calculates corresponds to a seal read from the flag, and to reject (314) a flag if it does not match . 24. The billing system (10) enigt patent krav 17, the codename därav, att den and anordnad att uppdatera (312), the billing information is provided in the form of a panel of 15 pages, which is an observer of the bill. A ticket processing device (10) according to claim 17, characterized in that it is arranged to update (312) unprotected data of the ticket application with seals if it has detected a ticket-approved seal solution. 25. Ticketing (10) en patent application 17, telecommunication device, att den har en GPS positioner (107) eller en motsvarande anordning som ger platsinformation. A ticket processing device (10) according to claim 17, characterized in that it comprises a GPS positioning device (107) or a similar position reporting device. 26. Computer program products for control and communication 20 for billets, data packets for information, information about the ombattar - computer programs for information about the billing information (304) (25) computer programs for information systems, information systems and data systems (310) information systems for information systems, data systems for information systems and data systems for information systems, data systems for data processing and data protection uppdaterade information pä biljetten i 30 samband med stämplingen. 26. Computer program product for checking and granting ticket access, characterized in that it comprises at least part of the ticket data for protection 30. computer software means for calculating (304) the first seal and ticket application data and writing the ticket upon sale, 21 - computer program means for calculating the second seal , flag application information, and breach of first seal upon flag stamping; and - computer software means for writing a second seal, broken first seal, and 5 updated flag application information upon flag stamping. 27. The computer program product en patent patent 26, the codename därav, the att den omfattar computer program, and the modular format of the filtrukturen i biljetten som lasts frän productplattform. 27 27. A computer program product according to claim 26, characterized in that it comprises computer program means arranged to complement or otherwise modify the file structure of the flag read from the product platform. 28. A computer program product patent 26, a computer program, an app den om-fattar computer program, and an attorney att beräkna sigillen (304, 311) geom nomvändning av et känt krypteringsförfarande. The computer program product of claim 26, characterized in that it comprises computer program means arranged to count the seals (304, 311) using a known encryption method. 29. Computer program product patent application 26, companion machine, att den om-5 fattar computer program, somord anordnade att controller (309, 311) sigillet hos en biljettää productplattformen (20) som avläses av kortbehandlingsanordningen (10) genom attäränen biljettens avlästa filstruktur ooh jämföra det beräknade jämförelsesigillet med det From sigillet. A computer program product according to claim 26, characterized in that it comprises computer program means arranged to check (309, 311) the flag seal on the product platform (20) read by the card processor (10) by calculating the reference seal from the read flag file structure and comparing the calculated reference seal to the read seal. . 30. Computer program enligt patentkrav 26, kännetecknad därav, att den om-10 fattar on computer programs, som anordnade att anderna fligänsig sigill, colors account exempel i et fall av fyra sigill a computer program anordnat att med det första sigillet o sohill. bryta det första sigillet, med det andra sigillet beräkna det tredje sigillet ooh bryta det andra sigillet ooh med det tredje sigillet beräkna det fjärde sigillet ooh bryta det tredje. A computer program product according to claim 26, characterized in that it comprises computer program means arranged to use more than two seals, for example, in the case of four seals, the computer program is arranged to lower a second seal and break a first seal, second seal and third seal to lower the fourth seal and break the third. 31. Computer programs enligt patentkrav 26, kännetecknad därav, att den omfattar on computer programs, somord anordnade att dll eller fler sigill använder alvändessa ll freelance med det tredje sigillet beräknar et första sigill ooh. A computer program product according to claim 26, characterized in that it comprises computer program means arranged when two or more seals are used to circulate them so that, for example, a third seal lowers a new first seal and breaks the third. 32. The product platform (20), som e electronically avläsbart ooh skrivbart ooh som 20 har en centralenhet (201), to go (202) ooh en RFID-enhet eller motarvarande enhet (203) som möjliggör fjärravläsning ooh -skrivning, ooh för flash man. kan generera en individell identifiering ooh i can go to man can lagra en electronic billing, dänavecknad därav, att productplattformens where to anordnat att med hjälp av sin RFID-enhet (203) 25. taking en electronic billing i samband med en försäljingsingshändelse (301) , I am looking for the best information about the billing information, the information about the billing information (304), the information about the billing system, the billing system, the billing system, the billing system, the billing system, the billing system (304) 307) för biljettbehandlingsanordningen (10) ooh - given that andra sigill, biljettillämpningens uppdaterade information ooh det brutna första s igillet (316) i samband med controllingering ooh stämp-Lingen av biljetten. 28 A product tray (20), which is electronically readable and writable, having a central processing unit (201), a memory (202) and an RFID unit or equivalent unit (203) for remote reading and 30 writing, and for which a unique identifier can be generated and an electronic ticket, characterized in that the product platform memory is arranged, by means of its RFID unit (203) 22, to receive an electronic ticket in connection with the sale transaction (301) consisting of ticket information, ticket application information and said first seal (304); and 5. receive a second seal, updated ticket application information, and a broken first seal when the ticket is checked or stamped (316); . Product tray (20) according to claim 32, characterized in that it is a read-only travel card, a contact card, a disposable memory card or a portable communication device. 15 1. Förfarande för beviljande ooh controllererande av användningsrätt av electronic billet, flashing anfändningsrätt omfattar en filstruktur on en productplattform (20), flashingfilter vidare omfattar den electronic billing information ooh biletillohpning information (10), dänavecknat därav, att ät- 20 minstones en del av biljettinformationen paneldas - i samband med försäljningen med et första sigill, whisker sörsta sigill beräk-nas med biljettbehandlingsanordningen i samband med försälj-Ning (301) (304) skr skriviv skr bil bil bil bil bil bil (((((bil (30 30 30 30 30 30 30 (305), 25. sam ibandband sam bil 30 bil bil bil bil bil bil bil bil bil bil bil bil bil bil bil bil bil bil bil bil med med med med med med med med med med med med med med 30 30 30 30 30 30 30 30 30 30 30 30 310 30 30 310 310 310 310 skr (310 310 310 310 310 310 310 310 310 310 310 310 310 310 310 310 310 310 310 (310 310 310 310 310 310 310 310 310 310 310 310 310 (310 310 310 310 310 310 310 310 310 310 310 310 310 310 310 310 310 310 310 310 310 310 310 310 310 310 310 310 310 310 310 310 310 310 310 310 310 310 310 310 310 310 310 310 310 310 310 310 310 310 310 310 310 310 310 310 310 310 310 310 310 310 310 310 310 det brutna the first sigillet, and that - in connection with biljettbehandlingsanordningen stämplingen head 30 produktplattformen the head (20) writes VARANDA biljett of the second sigillets, det brutna first sigillets samt biljettillämpningens uppdaterad information (316). 23 33. Produktplattform (20) enligt patent krav 32, kännetecknad därav, att den er et fjärravläsbart resecort, that contact card, eng engskskort med where eller en bär-bar datakommunikationsanordning.