Classifications

• • G—PHYSICS
  • G07—CHECKING-DEVICES
  • G07B—TICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
  • G07B15/00—Arrangements or apparatus for collecting fares, tolls or entrance fees at one or more control points
  • G07B15/02—Arrangements or apparatus for collecting fares, tolls or entrance fees at one or more control points taking into account a variable factor such as distance or time, e.g. for passenger transport, parking systems or car rental systems

Definitions

• the invention concerns generally the technology of electronically delivering relatively short and compact messages that represent a commodity of value. Especially the invention concerns the problem of how to ensure that such a message, when presented for inspection, is an authentic one and not an illegal copy.
• SMS messages Short Message Service
• MMS messages Multimedia Message Service
• similar compact, well-defined messaging formats is rapidly gaining popularity.
• SMSC Short Message Service Center
• a ticket application server 105 is arranged to have a communication connection with the SMSC.
• Conveying an order message from the mobile telephone 101 through the base transceiver station 102 and the SMSC 104 to the ticket application server 105 is schematically represented in fig. 1 as a series of steps ⁇ , ⁇ and (D. After having received the order message the ticket application server 105 generates an electronic ticket and sends it back to the mobile telephone that ordered it. Conveying a ticket back to the mobile telephone 101 is shown as steps ⁇ , ⁇ and ⁇ .
• Charging for the electronically delivered ticket is most straightforwardly accomplished by adding a certain fixed price to the telephone bill of the user of the mobile telephone 101.
• the price for just sending another SMS message is typically considerably lower than the ticket price that was charged of the original recipient of the ticket message.
• a temp- tation quickly arises to cheat the system by ordering a single ticket for one of a group of persons and distributing copies of the original ticket as ordinary SMS messages to the other members of the group. It is of principal importance for the arrangement of fig.
• the reliability of checking the sender is undermined by certain mobile telephone models having a feature that was originally introduced in good faith in order to enhance user-friendliness.
• the user of the mobile telephone can use a freely selectable alphanumeric string as the identifier of an entry in the directory of stored names and numbers.
• said certain mobile telephone models check the sender's number from a received SMS message, and if the number matches that of a named entry in the directory, they only display the "name" or identifier of that entry as the sender of the message.
• a reference publication GB 2 361 570 is known to describe a general-purpose elec- tronic ticket delivery system, in which the ticket is delivered as an SMS message or in a browser-readable format.
• the SMS solution discussed in said publication is especially prone to the fraud scheme described earlier.
• WO 96/06508 presents a general- purpose method for reliably identifying the originator of an SMS message.
• the drawback of this scheme is that it requires modifications to the standardised basic operation of conveying SMS messages, because it involves using at least two different addresses in calling a Short Message Services Centre.
• the objectives of the invention are achieved by adding a time-dependent extension to the telephone number that the message transmission system includes into the message as the number of the sender.
• a method according to the invention has the characteristic features that are recited in the independent patent claim directed to a method.
• the invention is based on the insight that cheating in the way described above is only possible if the telephone number of the ticket application server is constant, so that the potential cheater can store it beforehand into his mobile telephone (or corresponding mobile telecommunication device) as an identifier of his accomplice. Every time when the telephone number of the ticket application server changes, the cheater must reprogram his mobile telephone. By making the telephone number of the ticket application server to change very often it is possible to make it difficult or impossible for the cheater to follow. Depending on the number and nature of possible other network-generated field values in a message it may be possible to apply a similar authentication strategy also to other field values than just the sender's tele- phone number.
• the scheme utilizes certain spare character locations that have been defined to constitute a part of a field in a transmitted message but are not necessarily needed for the transmission of information when the invention is not applied.
• the changing values are somehow related to another network-generated value in a well-defined field of the message, so that the message becomes self-sustaining regarding verification: for someone who knows the rules according to which the changing values behave, it suffices to compare the contents of the changing- value field to some other field in the message to see whether the message has been appropriately generated and delivered.
• the most straightforward candidate for the changing-value field is the field for the sender's telephone number. Typically it comprises relatively many character locations, to reckon with exceptionally long telephone numbers used in certain systems. If the telephone number assigned to a ticket application server is not as long as the maximum length of the sender's number field, the spare character locations can be used to insert a repeatedly changing extension.
• a simple and workable rule for gen- erating repeatedly changing extensions, that also correlate with the value of another field in the same message, is to utilize as an extension a part of or a derivative from the time value that is inserted into the message as transmission time.
• Fig. 1 illustrates a prior art setup for electronically ordering and delivering bus ticket messages
• fig. 2 illustrates a principle of using message parts according to the present invention
• fig. 3 a illustrates a process of exchanging messages according to an embodiment of the present invention
• fig. 3b illustrates a process of exchanging messages according to another embodiment of the present invention
• fig. 4 illustrates the operation of a ticket application server according to an embodiment of the invention
• fig. 5 illustrates the operation of an intelligent messaging gateway according to an embodiment of the invention
• fig. 6 illustrates certain structural aspects of a ticket application server accord- ing to an embodiment of the invention.
• Fig. 2 illustrates schematically a message 201, which we may designate as a multi- media message for the sake of generality.
• a message 201 which we may designate as a multi- media message for the sake of generality.
• a further feature of the message 201, which is also important to the present invention, is that its standardized composition defines a network-generated part 202 in addition to a user-defined part 203.
• the network-defined part 202 consists of the parameter values that a network (typically an SMSC) adds to the message, while the user-defined part 203 consists of the (originally maximum of 160) payload characters that a user or a message-generating computer program at a content provider's server puts in.
• a network typically an SMSC
• the user-defined part 203 consists of the (originally maximum of 160) payload characters that a user or a message-generating computer program at a content provider's server puts in.
• the network-generated part 202 typically comprises fields, of which fields 204 and 205 are shown in fig. 2, into which the network inserts certain values.
• fields 204 and 205 are shown in fig. 2, into which the network inserts certain values.
• At least one of these fields has a certain maximum length that has been selected to accommodate the longest possible values that can be inserted into that field, with some marginal so that typically the whole length of the field is not needed.
• field 204 is a field for the sender's telephone number. Telephone numbers of various lengths appear in different telephone systems around the world, so the length of the sender's number field 204 must have been selected to accommodate also relatively long telephone numbers.
• a telephone number that identifies a ticket application server (or other instance that is to generate messages that represent a commodity of value) is shorter than the maximum length of the field 204, so after said telephone number has been inserted as a field value 206, spare space 207 remains in the field 204.
• spare space 207 corresponds to three alphanumeric characters.
• field 205 also appears in the network-generated part 202 of the message 201.
• field 205 is the transmission time field, into which the SMSC should insert a value 208 that represents the moment of time at which the message was originally sent by its sender.
• the spare space 207 of the sender number field 204 is used to carry a code, the value of which has a certain relationship to the transmission time value 208 in the appropriate field 205.
• a code the value of which has a certain relationship to the transmission time value 208 in the appropriate field 205.
• an easy option would be to insert a certain fixed character into the spare space 207, followed (or preceded) by a two-digit number that matches the minute count, i.e. the two- digit number that represents minutes, in the transmission time value 208.
• Another option would be to select said two digits to match the second count in the transmission time value 208.
• a third option would be to use two digits of the spare space 207 to match the minute count and a third digit to match the number that represents tens of seconds in the transmission time value 208. It is not important to the invention, what is the exact way of mapping the transmission time value into a code value in the spare space 207; the following considerations should anyway be taken into account:
• the mapping algorithm should make the code value to change often enough to make it difficult for a potential cheater to follow.
• the cheating mechanism explained earlier requires the cheater to store into his mobile telephone a whole new identifier string as the name of his accomplice before forwarding the honestly obtained ticket message. It is reasonable to assume that making the code value change once per minute is enough to curtail at least large-scale cheating.
• mapping algorithm should be robust against typically occurring time jitter and transitional phenomena in the operation of the network devices. If two different devices or processes are responsible for generating the transmission time value and the code value, it should be ensured that they synchronize to each other tightly enough so that no contradictory value pairs (that would suggest that cheating had been attempted) are generated at the first place.
• mapping algorithm changes, even relativaly slightly, every now and then so that a potential cheater would be confused.
• minute count approach there could be a certain fixed offset value that is agreed upon e.g. once a week: this week the two digits in the code match the transmission time minute count plus 11, next week it is the minute count minus 05, and so on. It is easy to understand that the way of changing the algorithm should be kept secret from everybody else than those who have the task of running the system and/or checking the validity of delivered ticket messages.
• the message may naturally include also other parts and other fields than just those shown in fig. 2. If there is not enough spare space in one previously determined field and/or if it is considered advantageous for increasing security, code values can also be distributed into more than one field. It is likewise possible to make a single code value depend on more than one other value in more than one other field. In the process of defining a completely new message format it would naturally be possible to define a dedicated code value field for the insertion of a code value; however it is a major advantage of the present invention that the code value is "smuggled" in a previously defined field, moreover so that every ordinary mobile terminal will handle and display the code value in an exactly similar way with absolutely no additional definitions for message handling. The mobile terminals are not even aware of there being any code values involved: they will just handle and display the code value of the present invention as a part of the value that belongs to the appropriate field, which is field 204 in fig. 2.
• Fig. 3a illustrates a process of exchanging messages in a system that comprises a mobile terminal, an SMSC that implements the so-called CIMD protocol (Computer Interface to Message Distribution), a messaging gateway and a ticket application.
• the terminal At step 301 the terminal generates a ticket ordering message as a response of a user telling the terminal to do so.
• the terminal transmits the message, and at step 303 the SMSC receives it. Forwarding the message further towards the ticket application may involve certain processing 304 at the SMSC, after which a further transmit/receive step 305 and 306 takes place between the SMSC and the messaging gateway.
• CIMD protocol Computer Interface to Message Distribution
• the latter inspects the incoming message at step 307 enough to find out that it is a ticket ordering message, and passes it further to the ticket application in steps 308 and 309.
• the ticket application generates the ordered ticket message at step 310. Up to this point the operation proceeds exactly like in known prior art electronic ticketing applications.
• the ticket application At step 311 the ticket application generates an authentication code that is to be added to the ticket message generated at the previous step. Certain more detailed ways of generating the code will be described later.
• the ticket application transmits the completed ticket message to the messaging gateway, which receives it at step 313 and selects, by using appropriate known methods, the SMSC through which the ticket message should be delivered to the terminal that ordered it.
• a feature of the CIMD protocol is that the SMSC does not need to receive a sender's telephone number from the application that generated a message or the gateway that forwarded it to the SMSC: the SMSC has been configured to otherwise know a sender's telephone number that it adds to the message as a part of the proc- ess of sending the message towards the terminal. It is possible to provide a sender's telephone number to the SMSC according to CIMD, but the SMSC will still use the configured number and only add the number that came from the application server into the sender's number field after the configured number.
• the messaging gateway - In order not to have the same sender's number repeated twice in the message, the messaging gateway - after having recognized the appropriate SMSC as one that implements CIMD - strips off the actual telephone number value from the message at step 315 before sending the message to the SMSC at step 316.
• the SMSC receives the message at step 317 and executes its conventional processing at step 318: as a part of the last-mentioned it takes the code value that remained in the sender's number field after step 315 and appends it to the end of the sender's number field of the final message.
• Steps 319 and 320 represent transmitting the ticket message from the SMSC to the mobile terminal in a known way.
• Fig. 3b is otherwise the same as fig. 3a, but now we assume that the SMSC imple- ments the so-called Content Gateway interface towards message-generating applications in the network.
• An important difference to CIMD arrangements is that according to the Content Gateway specifications, the SMSC will not use any configured numbers but will accept and use any sender's number that came with the messsage from an application server. Steps 301 to 314 take place exactly in the same way as in fig. 3a. However, after noticing now at step 314 that the SMSC implements Content Gateway rather than CIMD, the messaging gateway now preserves at step 315' the contents of the sender's number field as they were in the message that came from the ticket application.
• Step 318' proceeds in the SMSC according to the Con- tent Gateway specifications, so the SMSC reads the whole contents of the sender's number from the message it received from the messaging gateway at step 317 and reuses it as such in the message it transmits to the mobile terminal at step 319.
• Fig. 4 illustrates the operation of a ticket-generating application according to an embodiment of the invention.
• the application receives a ticket order message from an SMSC, typically through a messaging gateway.
• the application extracts the sender's telephone number or corresponding sender identification from the order message and stores it for later use as an identifier of the in- tended recipient of a generated ticket message.
• the application generates the actual ticket message according to some preprogrammed instructions that describe how a ticket message should look like and what should it contain.
• the application inserts the sender identification extracted at step 402 into the message as an identifier of the intended recipient.
• the application takes its own telephone number or corresponding identifier and inserts it into an appropriate sender identification field in the ticket message as a prefix of a complete identifier value.
• the process has executed itself similarly as in prior art electronic ticketing applications.
• the application reads a code value and inserts it into the sender identification field in the ticket message as a suffix that complements the prefix inserted at step 405 to constitute a complete identifier value.
• the code value is simply some part of the number string that indicates current time, possibly altered with a fixed offset
• an advantageous way of exe- cuting step 406 is to read current time from a local clock, extract the appropriate numbers from the time value read, refer to a database for finding the currently valid offset value, perform the summing (or other calculational) operation between the extracted numbers and the offset, and write the result into the ticket message under construction.
• the database may also include a look-up table prepared beforehand, from which the application finds directly a modified code value by using the local time reading as a key.
• step 407 the application reads once more (if necessary) the local time value and inserts it into an appropriate field in the ticket message as an indicator of original message transmission time.
• step 408 the application transmits the completed ticket message towards an SMSC, typically through a message gateway. Steps 407 and 408 are again similar to corresponding steps known from prior art.
• Fig. 5 illustrates the operation of a message gateway functionality according to an embodiment of the invention when it conveys a completed ticket message from a ticket-generating application towards an SMSC.
• the message gateway receives a ticket message from the application, and at step 502 it selects the appropriate SMSC according to certain rules.
• the identity of the SMSC can be derived from the subscribers IMSI (International Mobile Subscription Identifier), fo typically the message gateway reads the recipient identifier at step 502 and uses some simple logic to select the appropriate SMSC.
• Steps 501 and 502 take place according to practices known from prior art.
• the message gateway checks, whether the selected SMSC runs CIMD or not. To be more general, we may say that at step 503 message gateway checks, whether the selected SMSC runs a messaging protocol that will only use a possibly transmitted sender's telephone number as a suffix to a preconfigured sender identifier (as in CIMD) or whether the selected SMSC runs a messaging protocol under which it is possible to send a complete sender identifier to the SMSC together with the message.
• a positive finding at step 503, which means that CIMD or a corresponding protocol is in use, causes a transition to step 504 at which the message gateway deletes the prefix part from the sender identifier that the application has inserted.
• the message gateway need certain unambiguous preprogrammed instructions of how to decide the number of characters to be deleted; assuming our example of always having three characters in the suffix an unambiguous instruction may be as simple as to delete all but the three last characters in a sender identifier string.
• Step 505 is a straightforward transmitting step at which the ticket message is transmitted towards the appropriately selected SMSC.
• Fig. 6 is a general block diagram of a system 601 according to an embodiment of the invention, in which the message gateway functionality 602 has been integrated into a single system with the ticket-generating application 603.
• a database 604 which can be used for various purposes. Closest of these to the present invention is the use of the database 604 as a storage of the currently valid code value.
• the system includes a web interface 605 through which it is pos- sible to examine and change certain configuration information stored in the database 604. There may also be direct connections for exchanging information between the web interface 605 on one hand and the message gateway functionality 602 and the ticket-generating application 603 on the other hand.
• the database 604 there is a collection of scripts 606, some of which may have been con- figured to execute automatically at the fulfilment of certain criteria while others must be manually triggered through the web interface 605.
• Illustrating all functionalities of fig. 6 in an exemplary way as existing within a single system 601 does not exclude other possible implementations. Parts of the sys- tem may be implemented even very far from each other, physically in clearly separate systems, as long as the communication connections between the different functionalities are realised appropriately. For example, it is relatively common that a message gateway functionality exists as a standalone system that serves to selectively connect a number of SMSCs with a number of application servers that run a wide variation of different service applications that utilize messaging.
• tickets in the sense of admission tickets or travel tickets.
• the con- cept of a "ticket” must be understood widely to cover all such instants where a user must or may have at his possession some commodity of value, which ultimately is just a piece of information that proves that the user has committed a certain transaction in a prescribed manner.
• the code value is derived from the transmission time of the ticket message and inserted into the sender identification (sender's telephone number) field, while the transmission time is inserted into the well-defined transmission time field of the same message.
• the code value is derived from the transmission time of the ticket message and inserted into the sender identification (sender's telephone number) field, while the transmission time is inserted into the well-defined transmission time field of the same message.
• An example of this kind is to make the ticket-generating application manipulate the transmission time value so that the minute count and second count would always be the same, or differ from each other by the currently valid offset value, in validly issued ticket messages.

Landscapes

• Business, Economics & Management (AREA)
• Finance (AREA)
• Physics & Mathematics (AREA)
• General Physics & Mathematics (AREA)
• Mobile Radio Communication Systems (AREA)
• Telephonic Communication Services (AREA)
• Storage Device Security (AREA)
• Debugging And Monitoring (AREA)
• Communication Control (AREA)
• Circuits Of Receivers In General (AREA)
• Data Exchanges In Wide-Area Networks (AREA)

Priority Applications (6)

Applications Claiming Priority (2)

Publications (1)

Family

ID=8564428

Family Applications (1)

Country Status (12)

Cited By (12)

Citations (3)

• 2002
  • 2002-08-12 FI FI20021467A patent/FI114425B/sv not_active IP Right Cessation
• 2003
  • 2003-08-11 AT AT03784222T patent/ATE420503T1/de active
  • 2003-08-11 ES ES03784222T patent/ES2320877T3/es not_active Expired - Lifetime
  • 2003-08-11 CN CNB038241307A patent/CN100542087C/zh not_active Expired - Fee Related
  • 2003-08-11 EA EA200500975A patent/EA200500975A1/ru unknown
  • 2003-08-11 WO PCT/FI2003/000597 patent/WO2004015917A1/en not_active Application Discontinuation
  • 2003-08-11 CA CA2495515A patent/CA2495515C/en not_active Expired - Fee Related
  • 2003-08-11 DK DK03784222T patent/DK1529370T3/da active
  • 2003-08-11 DE DE60325735T patent/DE60325735D1/de not_active Expired - Lifetime
  • 2003-08-11 AU AU2003249134A patent/AU2003249134B2/en not_active Ceased
  • 2003-08-11 EP EP03784222A patent/EP1529370B1/en not_active Expired - Lifetime
  • 2003-08-11 PT PT03784222T patent/PT1529370E/pt unknown

Patent Citations (3)

Also Published As

Similar Documents

Legal Events