FI114425B - Method and arrangement to verify the authenticity of a utility of value distributed as a digital message - Google Patents

Abstract

A method and an arrangement are disclosed for authenticat-ing a commodity of value delivered from a closed network as a digital message (201) to a mobile terminal. The digital message (201) has a predefined format that comprises fields (204, 205) for network-generated values (206, 208). Authenticating involves generating (311, 406) a code value according to a time-dependent rule, so that the generated code value depends on the moment of time when the digital message will be transmitted. The generated code value is inserted (311, 406) into a certain first field (204) in the digital message, which first field has a predefined role that is other than conveying code values. Another value that represents message transmission time is inserted (407) into a second field (205) in the digital message.

Description

114425

Method and Arrangement for Authentication of a Monetary Asset Distributed as a Digital Message - The present invention relates generally to a technique for distributing relatively short and concise messages representing a monetary value commodity. In particular, the invention relates to the problem of ensuring that such a message is submitted for verification that it is an authentic copy and not an illegal copy.

The electronic distribution of various tickets, discount coupons and similar monetary items 10 in the form of SMS (Short Message Service), MMS (Multimedia Message Service) and similar concise messages is rapidly gaining popularity. As an example, we can look at the known way to order and distribute public transport tickets (such as tram or bus tickets) to individual users' mobile phones. In Figure 1, we assume 15 that a user of a mobile phone 101 wants to order an electronically distributed bus ticket. The mobile phone 101 has a wireless communication link to the base station 102, which is still connected to the core network 103, part of which is a Short Message Service Center 104. The flag application server 105 is provided with a communication link to the SMS center. The transmission of an order message from the mobile phone 20 via the base station 102 and the SMS center 104 to the ticket application server 105 is shown schematically in Figure 1 as a series of steps ©, © and ©. Upon receipt of the order message, the ticket application server 105 generates an electronic ticket and sends it back to the mobile phone that ordered it. Transferring the ticket back to the mobile phone 101 is shown in steps 0, © and ©.

· T I

. "25 The simplest way to bill for an electronically delivered ticket is to add a certain fixed price to the telephone bill of the user of the mobile phone 101. After receiving the ticket message on his mobile phone, it is generally possible for the user to send a copy of the ticket message to another mobile phone. The price of 30 just sending another text message is typically much lower than the price of the ticket that was charged to the original recipient of the ticket message. ”There is an email temptation to cheat the system by ordering a ticket from one group and distributing copies of the original ticket. as text messages to other members of the group.

2 114425

For the usefulness of the arrangement shown in Figure 1, it is imperative that it is possible to verify the authenticity of the ticket message at the time it is presented for verification on the user's mobile phone. One known method of authentication is to rely on the authenticity of the sender information included in the flag message. During the process of transferring 5 SMS messages to the user's mobile phone, the network adds the sender's phone number to the message. There is no way in the market for mobile phones to falsify the sender of a received SMS message, so that an illegally forwarded copy can be identified by noting that the sender is not a ticket application server.

10 The reliability of sender verification is impaired by the feature of certain mobile phone models originally introduced in good faith to improve user-friendliness. A freely selectable alphanumeric string can be used by the mobile phone user to identify information in the stored names and numbers directory. On the other hand, said particular cell phone models check the sender's number on the received SMS message, and if the number corresponds to the named information in the directory, they will only display the "name" or identifier of that information as the sender of the message. So, if we assume that the ticket application server's phone number is 123456 and Pekka asks for cell phone number to be stored in Tina's name as belonging to someone named "123456" then the following transaction is $ 20: Tiina orders and receives an electronic ticket and sends Peka an illegal copy . When Pekka's cell phone is checked, it contains a received text: '* message, which the cell phone only displays as being received from' 123456 '.

In other words, the illegal copy that Pekan received from Tiina appears to be a genuine ticket message, received directly from the ticket application server.

'· I

. There are various ways of verifying messages that are electronically shared.

!,. * When applied to the problem described above, the disadvantages are usually the complexity of either the hardware required or the resulting message content, or both.

If the relatively short message has to represent the flag, it should be easy for both ordinary users and ticket inspectors to detect it. If the message has long lines of 30 alphanumeric codes, this easily gives rise to the suspicion that the system ....: is complicated and difficult to use. In addition, in order for the inspector to quickly and unanimously, ···, verify the meaning of the complex code sequence, the inspector must carry an electronic reading and checking device. This is also the case if the *. *. · Message contains some kind of bar code that can be displayed on the screen of the mobile phone 35, as in one of the proposed message authentication techniques.

3, 114425

GB 2 361 570 is known, which describes a general electronic ticket delivery system in which the ticket is delivered by SMS or in a browser-readable form. The text message solution described in said publication is particularly susceptible to the fraudulent procedure described above.

Another prior art publication is WO 96/06508 which discloses a general method for reliably identifying the sender of an SMS message. The disadvantage of this method is that it requires modifications to the standard basic operation of SMS forwarding because it uses at least two different addresses when contacting the SMS center.

It is an object of the present invention to provide a method and an arrangement that easily and reliably verify the authenticity of electronically distributed monetary items as a digital message. In particular, it is an object of the invention that authentication would require little, if any, additional investment in system hardware.

The objects of the invention are achieved by adding a time-dependent extension to the telephone number 15 included in the message as a sender number by the messaging system.

The method according to the invention has the features set forth in the independent claim to the method.

The invention also relates to an arrangement, the characteristic features of which are shown in the arrangement. the independent claim for sex.

»* • · '; Various embodiments of the invention are described in the dependent claims.

* • ·; ' .; The invention is based on the realization that a fraud such as the one described above is only possible if the ticket application server has a permanent telephone number, whereupon a potential fraudster can store it in advance on his mobile phone (or similar wireless communication device) as his criminal companion. Every time the ticket "!! application server phone number changes, the cheater has to reprogram his mobile phone. When changing the ticket application server phone number very often, it is difficult or impossible to track the cheater. Any other field: ['': Depending on the nature, it may be possible to use a corresponding authentication strategy for other field values I »»!, than just the sender's phone number.

• · 4 114425

According to the invention, the characteristic value or values added by the communication network to the message to be electronically shared are repeatedly changed according to a particular design. Preferably, the design utilizes certain extra character positions that are defined to form part of a field of the message being transmitted, but are not necessarily required for data transmission when the invention is not practiced. It is also advantageous for the variable values to be somehow related to some other value generated by the communication network in a defined field of the message, whereby the message becomes self-sustaining with respect to authentication: a person familiar with the rules of changing values behavior another field in the message to see if the message has been properly composed and sent.

The easiest alternative to a variable value field is the sender's phone number field. It typically has a relatively large number of characters since some systems use exceptionally long phone numbers. If the phone number provided to the flag application-15 server is not as long as the maximum length of the sender's number field, additional character positions may be used repeatedly to add a variable extension. A simple and workable rule for generating repetitively variable qualifiers that also correlate with another field value in the same message is to use a portion of, or due to, the value of the time 20 value added to the message transmission time.

The novel features considered to be characteristic of the invention are set forth in particular in the appended claims. The invention itself, its structure and method of operation, and its other objects and advantages will be best understood from the following embodiment of the invention.

IMI

.,.,: Description of Shapes and Related Drawings.

Fig. 1 shows a prior art arrangement for ordering bus ticket messages.

«· I

2, illustrates the principle of using parts of a message according to the invention, Fig. 3a illustrates a message exchange method according to an embodiment of the present invention,

* · I

*, 30 Figure 3b illustrates a message exchange procedure 1 according to another embodiment of the present invention, * · '· · ·' Figure 4 illustrates the operation of a flag application server according to an embodiment of the invention: Y; 2; Figure 5 illustrates the operation of an intelligent messaging relay according to an embodiment of the invention, and Figure 5114425 illustrates some structural aspects of a ticket application server according to an embodiment of the invention.

The exemplary embodiments disclosed in this application are not intended to be construed as limiting the applicability of the appended claims. The term "comprising" is used in this patent application as an open limitation which does not exclude features not mentioned. Unless expressly stated otherwise, the features set forth in the dependent claims are freely combinable with each other.

Figure 2 schematically shows a message 201, which we may commonly call a multime-10 slide message. Important features of the message for the invention include the fact that it is electronically divisible from a communication network to individual users' mobile stations and has a well-defined standardized structure which makes it acceptable and accessible to a very large number of mobile station users. Another feature of message 201 that is also important to the present invention is that its standardized structure defines, in addition to the user-generated part 203, the network-based part 202. By way of example of commonly used text messages, the network-defined part 202 consists of parameter values, which the network (typically SMSC) adds to the message, while the user-defined portion 203 consists (initially up to 160) of a payload entered by the user or by a computer program generating messages on the content provider's server 20.

The network-formed portion 202 typically comprises the fields illustrated in Figure 2! ie fields 204 and 205 to which the network adds certain values. Let's assume that at least one of these fields has a certain maximum length selected to accommodate the longest possible values that can be entered in that field, within a given margin <»•" 25, such that typically, the entire length of the field is not needed. We can say, for example, that field 204 is a field for the sender's phone number. There are different length telephone numbers in different telephone systems in the world, so the sender field has to be: that can accommodate; '' also relatively long telephone numbers. Typically, for the purposes of this invention, the telephone number of the ticket application server (or other entity representing the value of the commodity] .. * is shorter than the maximum length of field 204; after adding said telephone number to a field value of 206, field: Ys again, 204 assumes, by way of example, that: '': the length of the extra space 207 corresponds to three alphanumeric characters.

6 114425

There is also a second field 205 in the network portion 202 of the message 201. We assume that the field 205 is a transmission time field to which the SMSC should add a value 208 representing the time the message was originally transmitted by the message sender.

According to a preferred embodiment of the invention, the extra space 207 of the field 204 reserved for the sender number 5 is used to carry a code having a value relative to the transmission time 208 of the appropriate field 205. If one assumes that the extra space 207 is three characters long an extra space 207, followed by (or before) the transmission time value 208 a two-digit number corresponding to a minute number, i.e. a two-digit number representing minute-10 paths. Another option would be to select the two numbers so that they correspond to the 208 second value of the transmission time value. A third option would be to use two numbers of free space 207 to represent a minute number and a third number to represent a number representing tens of seconds of transmission time value 208. It is irrelevant to the invention how the value of transmission time 15 corresponds to the code value in free space 207, but the following considerations should be taken into account: * The matching algorithm should cause the code value to change frequently enough to make it difficult for any cheater to stay on. The fraudulent method described above requires the fraudster to store an entire new tag-20 string on his cellphone as the name of his criminal partner before the honestly obtained ticket message: forwarded. It can be safely assumed that the code value change multiplied; '; ran minutes is enough to prevent at least large-scale scams.

"* The matching algorithm should be robust enough to work with network devices • * *» · typical time fluctuation and transition phenomena. If two different '. ': The 25 devices or processes responsible for generating the transmit time value and code value should ensure that they are synchronized sufficiently closely so that no conflicting pairs of values (indicating that an attempt has been made to spoof) are generated.

'!!! > * It is advantageous if the matching algorithm changes, albeit relatively little, sil- '; 'I created it in order to fool potential cheaters. For example, if a method based on minute counts is used, there should be a certain deviation value that is agreed upon, for example, once a week: this week the two digits of the code correspond to the transmitters. is the minute number minus • # · 05, etc. It is easy to understand that the way the algorithm is modified must be kept secret from anyone other than those who are responsible for using the system and / or verifying the authenticity of the sent ticket messages.

7, 114425

Of course, the message may also contain parts and fields other than those shown in Figure 2. If there is not enough free space in any of the previously defined fields and / or it is considered advantageous to increase security, code values can also be divided into more than one field. Similarly, it is possible to make one code value 5 dependent on more than one other value in more than one other field. Naturally, when defining a completely new message format, it would be possible to define a custom code value field for adding a code value; however, a significant advantage of the present invention is that the code value is "" smuggled "in a predefined field, in addition to the fact that each conventional mobile station handles 10 and displays the code value in exactly the same manner without the need to add any new definitions to message processing. The mobile stations are not even aware that some code values are included: they only process and display the code value according to the present invention as part of the value belonging to that field, which is field 204 in Figure 2.

Figure 3a illustrates a message exchange procedure in a system comprising a mobile station, the SMSC, which uses a so-called. Computer Interface to Message Distribution (CIMD) protocol, message relay and flag application. In step 301, the mobile station generates a ticket order message in response to the user requesting the mobile station to do so. In step 302, the mobile station transmits the message, and in step 303 the SMSC 20 receives it. Forwarding a message to the ticketing application may require some processing at the SMSC 304, followed by a second send / receive: step 305 and 306 between the SMSC and the message relay. The latter examines the incoming message in step 307 enough to discover that it is a ticket order message, and passes; 'Further to the ticketing application in steps 308 and 309. The ticketing application generates a ordered ticket message at step 310. Up to now, the operation proceeds in exactly the same way as the electronic ticketing applications according to the art.

In step 311, the ticket application generates an authentication code which is added to the ticket message generated in the previous step. Certain more detailed ways of generating the code are described below. In step 312, the ticket application transmits the completed ticket message to the message relay, which receives it in step 313 and selects: · · using the appropriate, known methods, an SMSC through which the ticket message y. should be delivered to the mobile station that ordered it.

': One feature of the CIMD protocol is that the SMSC does not need to receive the sender: "*: The phone number from the application that generated the message or from the carrier that forwarded it to the SMSC. The SMSC is configured to otherwise recognize the sender's phone number, which it adds to the message as part of the procedure for sending the message to 8114425 mobile stations. It is possible to provide the sender's phone number by SMSCdle according to the CIMD, but the SMSC will still use the predefined number and add the number from the application server to the sender's number field only after the predefined number. To prevent the same sender number from being repeated twice 5 times in a message, the message proxy, after identifying that SMSC as using CIMD, deletes the actual phone number from the message in step 315 before sending the message to SMSC in step 316. The SMSC receives the message in step 317 and performs its usual processing at step 318: as part of the latter, it takes a code value that remained in the sender's number field after step 315 and appends it to the end of the sender's number field in the final message. Steps 319 and 320 represent sending a ticket message from the SMSC to the mobile station in a known manner.

Figure 3b is otherwise the same as figure 3a, but now we assume that SMSC uses the so-called. Content Gateway for applications that compose messages online.

An important difference from CIMD arrangements is that according to the Content Gateway specifications, SMSC does not use any predefined numbers, but accepts and uses any sender number that came with the message from the application server. Steps 301 to 314 proceed exactly as in Figure 3a. However, after step 314 now notices that the SMSC uses the Con-20 tent Gateway and not the CIMD, the message proxy now retains, at step 315 ', the contents of the sender number field as it was in the message from the flag application.

The '* step 318' proceeds in the SMSC according to the Content Gateway specifications, so that the 'SMSC reads the full content of the sender number from the message it received from the messenger at step 317 and uses it as such in the message it sends to the mobile at step 319.

Fig. 4 illustrates the operation of a flag-forming application according to an embodiment of the invention. In step 401, the application receives a ticket order message from the SMSC, typically through a message relay. In step 402, the application extracts the sender's speech ♦ - * - ·· 'bird number or corresponding sender identification from the order message and stores it as an identifier of the intended recipient of the generated ticket message for later use;;. ···. In step 403, the application generates the actual ticket message according to certain predefined · ···, programmed instructions that describe the appearance and content of the ticket message.

'· * In step 404, the application adds the sender identification information *. * Retrieved in step 402. to identify the intended recipient of the message. In step 405, the application takes its own voice • 35 * bird number or equivalent and inserts its flag message into the appropriate sender identifier field as a prefix for the complete identifier. Until now, the procedure has been similar to prior art electronic ticketing applications.

According to the invention, in step 406, the application reads the code value and adds it to the identifier field of the sender of the flag message as a suffix that completes the 5 prefixes added in step 405 to form a complete identifier value. If we assume that the code value is simply a part of the current time series of digits that may have been modified by a given offset, the preferred way to perform step 406 is to read the current time from the local clock, extract the appropriate numbers from the read time value, retrieve performs the addition (or other calculation) between the extracted numbers and the deviation, and writes the result in the flag message to be generated. To avoid in-use calculations and / or if the relationship between the time count and the corresponding code value is more complex than a mere sum, the database may also include a pre-generated lookup table where the application directly finds the modified code value using the local time count as a search key.

At step 407, the application reads the local time value (if necessary) again and adds it to the appropriate field of the ticket message to indicate the time of transmission of the original message. At step 408, the application transmits a completed ticket message towards the SMSC, typically via a message relay. Steps 407 and 408 are again similar to prior art steps 20 and 208, respectively.

? f · '. Fig. 5 illustrates a messaging function according to an embodiment of the invention, ·! when the completed ticket message is transferred from the ticketing application to the SMSC. In step 501, the message relay receives the ticket message from the application, and in step 502 it! 1 · | selects the appropriate SMSC according to certain rules. Mobile communication systems. : Each subscriber typically has a default SMSC, and the SMSC identity may. It is possible to derive a subscriber's IMSI (International Mobile Subscription Identity Identifier) identifier because the message relay typically reads the recipient identifier in step 502 and uses some simple logic to select the appropriate SMSC.

'; Steps 501 and 502 are carried out according to prior art practices.

· "· '30 In step 503, the message proxy checks whether the selected SMSC uses the CIMD or not. More generally, in step 503 the message proxy checks whether the selected, v, SMSC message protocol uses only the sender phone number that may be sent. as a suffix to a predefined sender identifier (such as> · '' * in CIMD), or whether the selected SMSC uses a message protocol that allows the full sender identifier to be sent to the SMSC. which means that CIMD or a similar protocol is in use, proceeds to step 504 where the messenger deletes the prefix from the sender's tag added by the application, and it is easy to understand that the messenger needs some unique, pre-programmed instructions on how to decide suppose to be an ancestor our character is that there are always three characters in the suffix, a unique instruction can be so simple that all but the last three characters in the sender's tag string are removed.

If the answer is no in step 503, proceed to step 505, to which the procedure goes 10 after completing step 504 if necessary. Step 505 is a transmission step in which a flag message is sent to a properly selected SMSC.

The methods shown in Figures 4 and 5 do not comment on at what stage or device the ticket should be charged. Charging is not relevant to the present invention and we can only assume that it employs some known methods or methods not yet invented at the priority date of this patent application.

Fig. 6 is a general block diagram of a system 601 according to an embodiment of the invention, wherein the messaging function 602 is integrated in the same system with the flag forming application 603. The latter has a data base 204 604 which can be used for various purposes. Of these, the closest to the present invention is the use of database 604 to store a valid code value.

The system includes a web interface 605 through which it is possible to examine and modify certain configuration information stored in database 604. There may also be direct connections for exchanging information between the web interface 605 on the one hand and the messaging function 602 on the other hand and the ticket generating application 603. In order to manage database 604 ... ', there is a collection of scripts 606, some of which may be configured to execute automatically when certain conditions are met, while others; i · must be started manually via web interface 605.

► ·

Exemplifying all the functions of Figure 6 so that they are in the same system 601 does not exclude other possible embodiments. Some parts of the system may also be implemented so that they are very far apart, physically. v. clearly entered on separate systems, when only data communication (!. * t connections between different functions are properly implemented. For example, it is quite common for the messaging function to be a separate system that selectively couples a plurality of SMSC-11 114425 units into a application servers that run a variety of service applications that utilize messaging features.

In the above description, "flags" and "" flags "are repeatedly mentioned as an embodiment of the invention. However, the applicability of the invention is not limited to, for example, admission tickets or travel tickets. The concept of a ticket must be broadly understood to include all cases where the user must or may have a monetary asset, which is ultimately just information that proves that the user has executed a particular event in a predetermined manner.

We have also mainly described an embodiment of the invention in which the code value is derived from the transmission time of the ticket message and added to the sender identifier field (sender telephone number) and the transmission time is added to the specified transmission time field of the same message. In principle, it is only possible to use the transmit time field to send both the transmit time and the code value if the system is allowed to violate some of the traditional rules for handling the transmit time field. For example, a flag-forming application may be arranged to process the transmission time value so that the minute and second counts are always the same or differ by the current offset value in the validly transmitted ticket messages. Even if the scammer finds out that this week the authentication will be verified to be twenty seven more than the minute of the transmission time value, it would be very difficult for him to schedule the sending of an illegal copy to his colleague in the exact right-; : municipalities.

* I · »- 'v« »* *» · ♦ · ♦ 1 I ·> * * »• · •» * * »• · t · •% • I» • · ·

• I

»»

Claims (11)

114425 A method for verifying the authenticity of a monetary item distributed from a closed network as a digital message (201), the digital message (201) having a predetermined format comprising fields (204, 205) for values (206, 208) generated by the network 5, characterized in that the method comprising the steps of: generating (311, 406) a code value according to a time-dependent rule such that the generated code value depends on the moment of transmission of the digital message, - adding (311, 406) the generated code value to a particular first field (204) a predetermined role other than transmitting code values, and - adding (407) a value representing the message transmission time to another field (205) in the digital message. The method of claim 1, characterized in that the step of adding (311, 406) the generated code value to a particular first field (204) in the digital message comprises the following sub-steps: - adding (405) to said first field (204) a and a sharing service identifier (206) smaller in size than the total space available in said first field (204), and inserting (311, 406) the generated code value into said first field: .. (204) as an suffix of said identifier (206) . The method of claim 2, further comprising the steps of: a) determining (502, 503) whether the digital message is to be processed according to the first data transmission protocol, using a predefined default identifier di- and (b) if the answer in step (a) is yes, deleting (504) from said digital: the message identifying the value generating and distributing service as mentioned in the message. 30 before processing said digital message according to said first protocol. I ·, v. A method according to claim 1, characterized in that the step of generating (311, 406) a code value according to a time-dependent rule comprises the following sub-steps: 114425 - retrieving a number sequence representing the transmission time of the digital message. , and - taking a subset of the numbers in said sequence as a code value. A method according to claim 4, characterized in that in the step of taking a subset of the numbers in said sequence as a code value, 5 pairs of numbers are represented to represent the minute number. A method according to claim 4, characterized in that in the step of taking a subset of the numbers in said sequence as a code value, the number pair is represented to represent a number of seconds. The method of claim 1, characterized in that the step of generating (311, 406) a code value according to a time-dependent rule comprises the following sub-steps: - retrieving a number sequence representing the transmission time of the digital message, - obtaining a subset of numbers in said number sequence; and - adding a predetermined deviation value to a number represented by said subset of numbers 15 to obtain a code value. An arrangement (601) for generating and distributing authenticated monetary items as a digital message from a closed network, which digital messages have a predetermined format (201) comprising fields (204, 205) for values generated by the network (206, 208), characterized by: that the arrangement '' 20 comprises: -: means (603, 604) for generating a code value according to a time-dependent rule, such that the generated code value is arranged to be dependent on the moment of transmission of the digital message, -: - means (603) in a digital message to be transmitted to the first field, the first field having a predetermined role other than the transmission of code values, and,:, means (603) for adding a value representative of the message transmission time to another field of the transmitted digital message. : · ·; An arrangement according to claim 8, characterized in that it comprises: - a commodity-generating application (603) for generating value-added commodities, and a · · · · - message broker function (603) coupled to said commodity-generating application (603). 602) for the delivery of generated high value commodities in the form of digital messages for distribution to message centers. 114425 An arrangement according to claim 9, characterized in that said commodity generating application (603) is arranged to insert in the first field of generated digital messages an identifier for a service generating and distributing a valuable commodity smaller than the total space available in said first field, and adding the generated code value to said first field as an suffix of said identifier. An arrangement according to claim 10, characterized in that said message proxy function (602) is arranged to: - determine whether the digital message delivered to a particular message center must be handled there according to the first communication protocol, using a predefined default identifier in the digital message identifier field any identifiers contained in the message after said predefined default identifier; and - deleting some of the content of the identifier field from the digital messages processed in accordance with the first 15 protocols before sending such digital messages to the message centers.