EP1529370A1 - Method and arrangement for authenticating a commodity of value delivered as a digital message - Google Patents

Method and arrangement for authenticating a commodity of value delivered as a digital message

Info

Publication number
EP1529370A1
EP1529370A1 EP03784222A EP03784222A EP1529370A1 EP 1529370 A1 EP1529370 A1 EP 1529370A1 EP 03784222 A EP03784222 A EP 03784222A EP 03784222 A EP03784222 A EP 03784222A EP 1529370 A1 EP1529370 A1 EP 1529370A1
Authority
EP
European Patent Office
Prior art keywords
message
field
value
digital message
identifier
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
EP03784222A
Other languages
German (de)
French (fr)
Other versions
EP1529370B1 (en
Inventor
Ari Pakarinen
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Plusdial Oy AB
Original Assignee
Plusdial Oy AB
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=8564428&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=EP1529370(A1) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Application filed by Plusdial Oy AB filed Critical Plusdial Oy AB
Publication of EP1529370A1 publication Critical patent/EP1529370A1/en
Application granted granted Critical
Publication of EP1529370B1 publication Critical patent/EP1529370B1/en
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

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)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Circuits Of Receivers In General (AREA)
  • Communication Control (AREA)

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

Method and arrangement for authenticating a commodity of value delivered as a digital message
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.
Electronically delivering various tickets, discount coupons and corresponding commodities of value in the form of SMS messages (Short Message Service), MMS messages (Multimedia Message Service) and similar compact, well-defined messaging formats is rapidly gaining popularity. As an example we may consider the known way of ordering and delivering public transport tickets (such as tram or bus tickets) to the mobile telephones of individual users. In fig. 1 we assume that the user of a mobile telephone 101 wants to order an electronically deliverable bus ticket. The mobile telephone 101 has a wireless communication connection with a base transceiver station 102, from which there is a further connection to a core network 103 of which an SMSC (Short Message Service Center) 104 constitutes a part. A ticket application server 105 is arranged to have a communication connection with the SMSC. Conveying an order message from the mobile telephone 101 through the base transceiver station 102 and the SMSC 104 to the ticket application server 105 is schematically represented in fig. 1 as a series of steps Φ, © 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. However, after the user has received the ticket message into his mobile telephone, it is usually possible for him to forward a copy of the ticket message to another mobile telephone, like that of a friend who took the same bus. The price for just sending another SMS message is typically considerably lower than the ticket price that was charged of the original recipient of the ticket message. A temp- tation quickly arises to cheat the system by ordering a single ticket for one of a group of persons and distributing copies of the original ticket as ordinary SMS messages to the other members of the group. It is of principal importance for the arrangement of fig. 1 to be plausible that it is possible to verify the authenticity of a ticket message at the moment when it is presented for inspection at the user's mobile telephone. A known way of providing authenticity is to rely on the correctness of the sender information that constitutes a part of the ticket message. During the process of conveying an SMS message towards the mobile telephone of a user the network adds the telephone number of the sender to the message. An off-the-shelf mobile telephone does not include any means for forging the sender information in a received SMS message, so an illegally forwarded copy can be recognized by noting that its sender is not the ticket application server.
The reliability of checking the sender is undermined by certain mobile telephone models having a feature that was originally introduced in good faith in order to 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. On the other hand said certain mobile telephone models check the sender's number from a received SMS message, and if the number matches that of a named entry in the directory, they only display the "name" or identifier of that entry as the sender of the message. So if we assume that the telephone number of the ticket application server is 123456 and Tom instructs his mobile telephone to store Eve's number as belonging to somebody named "123456", the following scheme becomes possible: Eve orders and receives an electronic ticket and forwards an illegal copy of it to Tom. When Tom's mobile telephone is inspected, it contains a received SMS message, which the mobile telephone only displays as having been re- ceived from "123456". In other words Tom's illegal copy that he received from Eve appears to be an authentic ticket message directly received from the ticket application server.
In general, various approaches are known for authenticating electronically distrib- uted messages. Their drawbacks regarding applicability to the above-described problem usually involve complexity either in required hardware or in resulting message content or both. If a relatively short message must represent a ticket, it should be easy both for ordinary users and for ticket inspectors to perceive it as one. Elaborate alphanumeric code strings in the message tend to raise a suspicion of the sys- tem being complicated and difficult to use. Additionally for an inspector to be able to quickly and unambiguously verify the meaning of a complicated code string requires that the inspector carries along an electronic reader and verifier device. The same is true if the message contains some kind of a bar code that the mobile tele- phone can show on its display, which is one of the suggested message authentication techniques.
A reference publication GB 2 361 570 is known to describe a general-purpose elec- tronic ticket delivery system, in which the ticket is delivered as an SMS message or in a browser-readable format. The SMS solution discussed in said publication is especially prone to the fraud scheme described earlier.
Another known prior art publication is WO 96/06508, which presents a general- purpose method for reliably identifying the originator of an SMS message. The drawback of this scheme is that it requires modifications to the standardised basic operation of conveying SMS messages, because it involves using at least two different addresses in calling a Short Message Services Centre.
It is an objective of the invention to provide a method and an arrangement that ensure easy and reliable authentication of commodities of value that were delivered electronically in the form of digital messages. It is especially an aim of the invention that authentication should require only little, if any, extra investment in system hardware.
The objectives of the invention are achieved by adding a time-dependent extension to the telephone number that the message transmission system includes into the message as the number of the sender.
A method according to the invention has the characteristic features that are recited in the independent patent claim directed to a method.
The invention applies also to an arrangement, the characteristic features of which are recited in the independent patent claim directed to an arrangement.
Various embodiments of the invention are described in the depending claims.
The invention is based on the insight that cheating in the way described above is only possible if the telephone number of the ticket application server is constant, so that the potential cheater can store it beforehand into his mobile telephone (or 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.
According to the invention, there exists a scheme for repeatedly changing an identifier value or identifier values that the network adds into an electronically delivered message. Preferably the scheme utilizes certain spare character locations that have been defined to constitute a part of a field in a transmitted message but are not necessarily needed for the transmission of information when the invention is not applied. Also it is preferable that the changing values are somehow related to another network-generated value in a well-defined field of the message, so that the message becomes self-sustaining regarding verification: for someone who knows the rules according to which the changing values behave, it suffices to compare the contents of the changing- value field to some other field in the message to see whether the message has been appropriately generated and delivered.
The most straightforward candidate for the changing-value field is the field for the sender's telephone number. Typically it comprises relatively many character 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.
The novel features which are considered as characteristic of the invention are set forth in particular in the appended claims. The invention itself, however, both as to its construction and its method of operation, together with additional objects and advantages thereof, will be best understood from the following description of specific embodiments when read in connection with the accompanying drawings.
Fig. 1 illustrates a prior art setup for electronically ordering and delivering bus ticket messages, fig. 2 illustrates a principle of using message parts according to the present 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 and fig. 6 illustrates certain structural aspects of a ticket application server accord- ing to an embodiment of the invention.
The exemplary embodiments of the invention presented in this patent application are not to be interpreted to pose limitations to the applicability of the appended claims. The verb "to comprise" is used in this patent application as an open limita- tion that does not exclude the existence of also unrecited features. The features recited in depending claims are mutually freely combinable unless otherwise explicitly stated.
Fig. 2 illustrates schematically a message 201, which we may designate as a multi- media message for the sake of generality. Features of the messages that are important to the invention are that it is electronically deliverable from a network to the terminals of individual users and that it has a well-defined and standardized structure that makes it acceptable and usable for an extremely wide population of mobile terminal users. A further feature of the message 201, which is also important to the present invention, is that its standardized composition defines a network-generated part 202 in addition to a user-defined part 203. Considering the widely used SMS message as an example, the network-defined part 202 consists of the parameter 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.
The network-generated part 202 typically comprises fields, of which fields 204 and 205 are shown in fig. 2, into which the network inserts certain values. We assume that at least one of these fields has a certain maximum length that has been selected to accommodate the longest possible values that can be inserted into that field, with some marginal so that typically the whole length of the field is not needed. As an example we may say that field 204 is a field for the sender's telephone number. Telephone numbers of various lengths appear in different telephone systems around the world, so the length of the sender's number field 204 must have been selected to accommodate also relatively long telephone numbers. Typically when the present invention is applied, a telephone number that identifies a ticket application server (or other instance that is to generate messages that represent a commodity of value) is shorter than the maximum length of the field 204, so after said telephone number has been inserted as a field value 206, spare space 207 remains in the field 204. Again as an exemplary assumption only we assume that the length of the spare space 207 corresponds to three alphanumeric characters.
Another field 205 also appears in the network-generated part 202 of the message 201. We assume that field 205 is the transmission time field, into which the SMSC should insert a value 208 that represents the moment of time at which the message was originally sent by its sender.
According to a preferable embodiment of the invention, the spare space 207 of the sender number field 204 is used to carry a code, the value of which has a certain relationship to the transmission time value 208 in the appropriate field 205. Taken our exemplary assumption of the spare space 207 being three characters long, an easy option would be to insert a certain fixed character into the spare space 207, followed (or preceded) by a two-digit number that matches the minute count, i.e. the two- digit number that represents minutes, in the transmission time value 208. Another option would be to select said two digits to match the second count in the 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.
* The 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.
* It is advantageous if the mapping algorithm changes, even relativaly slightly, every now and then so that a potential cheater would be confused. For example if the minute count approach is used, there could be a certain fixed offset value that is agreed upon e.g. once a week: this week the two digits in the code match the 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. At step 301 the terminal generates a ticket ordering message as a response of a user telling the terminal to do so. At step 302 the terminal transmits the message, and at step 303 the SMSC receives it. Forwarding the message further towards the ticket application may involve certain processing 304 at the SMSC, after which a further transmit/receive step 305 and 306 takes place between the SMSC and the messaging gateway. The latter inspects the incoming message at step 307 enough to find out that it is a ticket ordering message, and passes it further to the ticket application in steps 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.
At step 311 the ticket application generates an authentication code that is to be added to the ticket message generated at the previous step. Certain more detailed ways of generating the code will be described later. At step 312 the ticket 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. 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. At step 401 the application receives a ticket order message from an SMSC, typically through a messaging gateway. At step 402 the application extracts the sender's telephone number or corresponding sender identification from the order message and stores it for later use as an identifier of the in- tended recipient of a generated ticket message. At step 403 the application generates the actual ticket message according to some preprogrammed instructions that describe how a ticket message should look like and what should it contain. At step 404 the application inserts the sender identification extracted at step 402 into the message as an identifier of the intended recipient. At step 405 the application takes its own telephone number or corresponding identifier and inserts it into an appropriate sender identification field in the ticket message as a prefix of a complete identifier value. Up to this point the process has executed itself similarly as in prior art electronic ticketing applications.
According to the invention, at step 406 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. If we assume that 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. If run-time calculations are to be avoided and/or if the relationship be- tween a time reading and a corresponding code value is more intricate than a pure sum, the database may also include a look-up table prepared beforehand, from which the application finds directly a modified code value by using the local time reading as a key.
At step 407 the application reads once more (if necessary) the local time value and inserts it into an appropriate field in the ticket message as an indicator of original message transmission time. At step 408 the application transmits the completed 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. At step 501 the message gateway receives a ticket message from the application, and at step 502 it selects the appropriate SMSC according to certain rules. Typically there is a default SMSC for each subscriber to a mobile telecommunication system and the identity of the SMSC can 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.
At step 503 the message gateway checks, whether the selected SMSC runs CIMD or not. To be more general, we may say that at step 503 message gateway checks, whether the selected SMSC runs a messaging protocol that will only use a possibly transmitted sender's telephone number as a suffix to a preconfigured sender 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. It is easy to understand that 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.
A negative finding at step 503 results in a transition to step 505, into which the process also goes after having executed step 504 when needed. Step 505 is a straightforward transmitting step at which the ticket message is transmitted towards the appropriately selected SMSC.
The methods of figs. 4 and 5 do not take any position regarding at which step or device should charging for the ticket be accomplished. Charging is not a matter of interest regarding the present invention, and we may just assume that some known methods or methods that at the priority date of this patent application are still to be invented are used for charging.
Fig. 6 is a general block diagram of a system 601 according to an embodiment of the invention, in which the message gateway functionality 602 has been integrated into a single system with the ticket-generating application 603. At the disposal of the latter is a database 604, which can be used for various purposes. Closest of these to the present invention is the use of the database 604 as a storage of the currently valid code value. The system includes a web interface 605 through which it is pos- sible to examine and change certain configuration information stored in the database 604. There may also be direct connections for exchanging information between the web interface 605 on one hand and the message gateway functionality 602 and the ticket-generating application 603 on the other hand. As a way of adminstering the database 604 there is a collection of scripts 606, some of which may have been con- figured to execute automatically at the fulfilment of certain criteria while others must be manually triggered through the web interface 605.
Illustrating all functionalities of fig. 6 in an exemplary way as existing within a 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.
In the description above we have repeatedly referred to "tickets" and "ticket generation" as an application of the invention. However, the applicability of the invention is not limited to tickets in the sense of admission tickets or travel tickets. The con- cept of a "ticket" must be understood widely to cover all such instants where a user must or may have at his possession some commodity of value, which ultimately is just a piece of information that proves that the user has committed a certain transaction in a prescribed manner.
We have also mainly described an embodiment of the invention where the code value is derived from the transmission time of the ticket message and inserted into the sender identification (sender's telephone number) field, while the transmission time is inserted into the well-defined transmission time field of the same message. In principle it is possible to use only the transmission time field for the transmission of both the transmission time and the code value, if the system is allowed to slightly break the conventional rules of handling the transmission time field. An example of this kind is to make the ticket-generating application manipulate the transmission time value so that the minute count and second count would always be the same, or differ from each other by the currently valid offset value, in validly issued ticket messages. Even if a cheater found out that this week the proof of authentication is the fact that the second count is seven more than the minute count in the transmission time value, he would have hard times trying to time the transmission of an ille- gal copy to his accomplice exactly on the correct second.

Claims

Claims
1. A method for authenticating a commodity of value delivered from a closed network as a digital message (201) to a mobile terminal, which digital message (201) has a predefined format that comprises fields (204, 205) for networkgenerated values (206, 208), characterized in that the method comprises the steps of:
- 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, - inserting (311, 406) the generated code value into a certain first field (204) in the digital message, which first field has a predefined role that is other than conveying code values, and
- inserting (407) a value that represents message transmission time into a second field (205) in the digital message.
2. A method according to claim 1, characterized in that the step of inserting (311, 406) the generated code value into a certain first field (204) in the digital message comprises the substeps of:
- inserting (405) into said first field (204) an identifier (206) of a service for generating and delivering commodities of value, which identifier (206) is smaller in size than a total space available in said first field (204), and
- additionally inserting (311, 406) the generated code value into said first field (204) as a suffix to said identifier (206).
3. A method according to claim 2, characterized in that it additionally comprises the steps of: a) finding out (502, 503), whether the digital message is to be handled according to a first communications protocol that will involve using a preconfigured default identifier in an identifier field of the digital message and adding potentially existing message-contained identifiers after said preconfigured default identifier, and b) in the case of a positive finding at step a), stripping (504) from said digital message said identifier of a service for generating and delivering commodities of value, before handling said digital message according to said first protocol.
4. 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 substeps of: - obtaining a string of digits that represents a transmission time of the digital message and
- taking a subset of the digits in said string of digits as the code value.
5. A method according to claim 4, characterized in that the step of taking a subset of the digits in said string of digits as the code value involves taking a pair of digits that represent a minute count.
6. A method according to claim 4, characterized in that the step of taking a sub- set of the digits in said string of digits as the code value involves taking a pair of digits that represent a second count.
7. A method according to claim 1, characterized in that the step of generating (311, 406) a code value according to a time-dependent rale comprises the substeps of:
- obtaining a string of digits that represents a transmission time of the digital message,
- taking a subset of the digits in said string of digits and
- summing a predefined offset value to the number represented by said subset of digits to obtain the code value.
8. An arrangement (601) for generating and delivering authenticated commodities of value that are to be delivered from a closed network as digital messages to mobile terminals, which digital messages have a predefined format (201) that com- prises fields (204, 205) for network-generated values (206, 208), characterized in that the arrangement comprises:
- means (603, 604) for generating a code value according to a time-dependent rule, so that a generated code value is arranged to depend on the moment of time when a digital message will be transmitted, - means (603) for inserting a generated code value into a certain first field in a digital message that will be transmitted, which first field has a predefined role that is other than conveying code values, and
- means (603) for inserting a value that represents message transmission time into a second field in a digital message that will be transmitted.
9. An arrangement according to claim 8, characterized in that it comprises: - a commodity-generating application (603) for generating commodities of value and - coupled to said commodity-generating application (603) a message gateway functionality (602) for delivering generated commodities of value as digital messages to messaging centers for further delivery.
10. An arrangement according to claim 9, characterized in that said commodity- generating application (603) is arranged to insert into a first field in generated digital messages an identifier of a service for generating and delivering commodities of value, which identifier is smaller in size than a total space available in said first field, and to additionally insert a generated code value into said first field as a suffix to said identifier.
11. An arrangement according to claim 10, characterized in that said message gateway functionality (602) is arranged to:
- find out, whether a digital message that is to be delivered to a certain messaging center is to be handled there according to a first communications protocol that will involve using a preconfigured default identifier in an identifier field of the digital message and adding potentially existing message-contained identifiers after said preconfigured default identifier, and
- strip a part of the contents of an identifier field from digital messages that will be handled according to said first protocol, before delivering such digital messages to messaging centers.
EP03784222A 2002-08-12 2003-08-11 Method and arrangement for authenticating a commodity of value delivered as a digital message Expired - Lifetime EP1529370B1 (en)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
FI20021467A FI114425B (en) 2002-08-12 2002-08-12 Method and arrangement to verify the authenticity of a utility of value distributed as a digital message
FI20021467 2002-08-12
PCT/FI2003/000597 WO2004015917A1 (en) 2002-08-12 2003-08-11 Method and arrangement for authenticating a commodity of value delivered as a digital message

Publications (2)

Publication Number Publication Date
EP1529370A1 true EP1529370A1 (en) 2005-05-11
EP1529370B1 EP1529370B1 (en) 2009-01-07

Family

ID=8564428

Family Applications (1)

Application Number Title Priority Date Filing Date
EP03784222A Expired - Lifetime EP1529370B1 (en) 2002-08-12 2003-08-11 Method and arrangement for authenticating a commodity of value delivered as a digital message

Country Status (12)

Country Link
EP (1) EP1529370B1 (en)
CN (1) CN100542087C (en)
AT (1) ATE420503T1 (en)
AU (1) AU2003249134B2 (en)
CA (1) CA2495515C (en)
DE (1) DE60325735D1 (en)
DK (1) DK1529370T3 (en)
EA (1) EA200500975A1 (en)
ES (1) ES2320877T3 (en)
FI (1) FI114425B (en)
PT (1) PT1529370E (en)
WO (1) WO2004015917A1 (en)

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20040090620A (en) * 2003-04-18 2004-10-26 삼성전자주식회사 System and method for purchasing a race account vote using wireless mobile communication network
US8111694B2 (en) 2005-03-23 2012-02-07 Nokia Corporation Implicit signaling for split-toi for service guide
US8520703B2 (en) 2005-04-05 2013-08-27 Nokia Corporation Enhanced electronic service guide container
US8607271B2 (en) 2005-08-26 2013-12-10 Nokia Corporation Method to deliver messaging templates in digital broadcast service guide
US8316132B2 (en) 2005-09-08 2012-11-20 Nokia Corporation Method to determine the completeness of a service guide
US8320819B2 (en) 2005-11-01 2012-11-27 Nokia Corporation Mobile TV channel and service access filtering
US8763036B2 (en) 2005-11-04 2014-06-24 Nokia Corporation Method for indicating service types in the service guide
CN100411456C (en) * 2006-04-12 2008-08-13 华为技术有限公司 Method for implementation of predefined short message service
CN102164037B (en) * 2011-03-31 2014-04-30 飞天诚信科技股份有限公司 Digital signing system and method
WO2014055772A1 (en) 2012-10-03 2014-04-10 Globesherpa, Inc. Mobile ticketing
CN103994810B (en) * 2014-05-29 2016-05-25 广州市中兴电子衡器厂 A kind of anti-cheated electronic weighing scale and anti-cheating method
US9792604B2 (en) 2014-12-19 2017-10-17 moovel North Americ, LLC Method and system for dynamically interactive visually validated mobile ticketing

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FI96374C (en) * 1994-08-10 1996-06-10 Radiolinja Ab Procedure for determining the transmitter category for a short message in a digital mobile telephone network
GB0009599D0 (en) * 2000-04-18 2000-06-07 British Airways Plc A method of operating a ticketing system
NL1016853C2 (en) * 2000-12-12 2002-06-13 Koninkl Kpn Nv Method for the purchase of services and the control thereof, using a mobile terminal.

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2004015917A1 *

Also Published As

Publication number Publication date
DK1529370T3 (en) 2009-03-09
CN1689270A (en) 2005-10-26
AU2003249134B2 (en) 2008-04-17
PT1529370E (en) 2009-04-09
FI20021467A (en) 2004-02-13
ES2320877T3 (en) 2009-05-29
WO2004015917A1 (en) 2004-02-19
CN100542087C (en) 2009-09-16
EP1529370B1 (en) 2009-01-07
DE60325735D1 (en) 2009-02-26
FI20021467A0 (en) 2002-08-12
EA200500975A1 (en) 2005-12-29
FI114425B (en) 2004-10-15
ATE420503T1 (en) 2009-01-15
AU2003249134A1 (en) 2004-02-25
CA2495515A1 (en) 2004-02-19
CA2495515C (en) 2010-06-08

Similar Documents

Publication Publication Date Title
CN104134142B (en) A kind of subway booking recognized based on Quick Response Code, ticket checking method
US20070168432A1 (en) Use of service identifiers to authenticate the originator of an electronic message
US20090319797A1 (en) Method and computer system for ensuring authenticity of an electronic transaction
EP1529370B1 (en) Method and arrangement for authenticating a commodity of value delivered as a digital message
CN103258351A (en) Real-name system ticket purchasing method and real-name system ticketing system
CN100477579C (en) Method for registering and enabling PKI functionalities
FI108373B (en) Procedures and systems for realizing a digital signature
US20160300077A1 (en) Personal identification number distribution device and method
CN108460593A (en) A kind of offline Quick Response Code method of payment and device
MXPA99006872A (en) System for delivering certified facsimile messages.
US7917943B1 (en) E-mail Stamping with accredited entity name
US7058614B1 (en) Method and devices for printing a franking mark on a document
CN106331354B (en) A kind of short message information extracting and analysis method
FI118832B (en) Method and apparatus for providing service in a computer network
US7290143B2 (en) Method of certifying transmission, reception and authenticity of electronic documents and related network unit
GB2380897A (en) Sending email to mobile phone as text message
CN101436278A (en) Method, apparatus and system for processing data
US8069118B2 (en) Mediated electronic messaging with value-added services
FI115816B (en) A method and system for distributing bulletins and services over a computer network
CN202210325U (en) System for identifying bank self-service device
CN109670763B (en) Data processing method and system, terminal and server
US20110029459A1 (en) Personalized interactive mail publishing method
WO2001049054A1 (en) Digital signature
JP2005537572A (en) Providing verifiable shipping payment coding
JP2004259220A (en) Personal authentication system using user identification module

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20050225

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LI LU MC NL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL LT LV MK

DAX Request for extension of the european patent (deleted)
GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

AK Designated contracting states

Kind code of ref document: B1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LI LU MC NL PT RO SE SI SK TR

REG Reference to a national code

Ref country code: GB

Ref legal event code: FG4D

REG Reference to a national code

Ref country code: CH

Ref legal event code: EP

REG Reference to a national code

Ref country code: CH

Ref legal event code: NV

Representative=s name: HEPP WENGER RYFFEL AG

REG Reference to a national code

Ref country code: IE

Ref legal event code: FG4D

REF Corresponds to:

Ref document number: 60325735

Country of ref document: DE

Date of ref document: 20090226

Kind code of ref document: P

REG Reference to a national code

Ref country code: DK

Ref legal event code: T3

REG Reference to a national code

Ref country code: SE

Ref legal event code: TRGR

REG Reference to a national code

Ref country code: PT

Ref legal event code: SC4A

Free format text: AVAILABILITY OF NATIONAL TRANSLATION

Effective date: 20090331

REG Reference to a national code

Ref country code: GR

Ref legal event code: EP

Ref document number: 20090400701

Country of ref document: GR

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20090107

REG Reference to a national code

Ref country code: ES

Ref legal event code: FG2A

Ref document number: 2320877

Country of ref document: ES

Kind code of ref document: T3

REG Reference to a national code

Ref country code: HU

Ref legal event code: AG4A

Ref document number: E005424

Country of ref document: HU

PLBI Opposition filed

Free format text: ORIGINAL CODE: 0009260

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: EE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20090107

PLAX Notice of opposition and request to file observation + time limit sent

Free format text: ORIGINAL CODE: EPIDOSNOBS2

26 Opposition filed

Opponent name: INA FINLAND OY

Effective date: 20091006

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20090107

Ref country code: RO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20090107

NLR1 Nl: opposition has been filed with the epo

Opponent name: INA FINLAND OY

PLBB Reply of patent proprietor to notice(s) of opposition received

Free format text: ORIGINAL CODE: EPIDOSNOBS3

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MC

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20090831

PLCK Communication despatched that opposition was rejected

Free format text: ORIGINAL CODE: EPIDOSNREJ1

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: LU

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20090811

APAH Appeal reference modified

Free format text: ORIGINAL CODE: EPIDOSCREFNO

APBM Appeal reference recorded

Free format text: ORIGINAL CODE: EPIDOSNREFNO

APBP Date of receipt of notice of appeal recorded

Free format text: ORIGINAL CODE: EPIDOSNNOA2O

APBQ Date of receipt of statement of grounds of appeal recorded

Free format text: ORIGINAL CODE: EPIDOSNNOA3O

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: CY

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20090107

PLAB Opposition data, opponent's data or that of the opponent's representative modified

Free format text: ORIGINAL CODE: 0009299OPPO

R26 Opposition filed (corrected)

Opponent name: INA FINLAND OY

Effective date: 20091006

PLAB Opposition data, opponent's data or that of the opponent's representative modified

Free format text: ORIGINAL CODE: 0009299OPPO

R26 Opposition filed (corrected)

Opponent name: INA FINLAND OY

Effective date: 20091006

APBU Appeal procedure closed

Free format text: ORIGINAL CODE: EPIDOSNNOA9O

PLBN Opposition rejected

Free format text: ORIGINAL CODE: 0009273

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: OPPOSITION REJECTED

27O Opposition rejected

Effective date: 20140409

REG Reference to a national code

Ref country code: DE

Ref legal event code: R100

Ref document number: 60325735

Country of ref document: DE

Effective date: 20140409

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 14

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 15

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 16

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: TR

Payment date: 20190724

Year of fee payment: 17

Ref country code: DK

Payment date: 20190725

Year of fee payment: 17

Ref country code: CZ

Payment date: 20190718

Year of fee payment: 17

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: HU

Payment date: 20190717

Year of fee payment: 17

Ref country code: GR

Payment date: 20190716

Year of fee payment: 17

Ref country code: BG

Payment date: 20190716

Year of fee payment: 17

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: AT

Payment date: 20190722

Year of fee payment: 17

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: CH

Payment date: 20190821

Year of fee payment: 17

REG Reference to a national code

Ref country code: DK

Ref legal event code: EBP

Effective date: 20200831

REG Reference to a national code

Ref country code: CH

Ref legal event code: PL

REG Reference to a national code

Ref country code: AT

Ref legal event code: MM01

Ref document number: 420503

Country of ref document: AT

Kind code of ref document: T

Effective date: 20200811

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: CH

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20200831

Ref country code: CZ

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20200811

Ref country code: GR

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20210304

Ref country code: HU

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20200812

Ref country code: LI

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20200831

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: AT

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20200811

Ref country code: BG

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20210228

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: DK

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20200831

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: NL

Payment date: 20210715

Year of fee payment: 19

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: FI

Payment date: 20210721

Year of fee payment: 19

Ref country code: FR

Payment date: 20210831

Year of fee payment: 19

Ref country code: IE

Payment date: 20210719

Year of fee payment: 19

Ref country code: IT

Payment date: 20210816

Year of fee payment: 19

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: SE

Payment date: 20210817

Year of fee payment: 19

Ref country code: BE

Payment date: 20210824

Year of fee payment: 19

Ref country code: DE

Payment date: 20210811

Year of fee payment: 19

Ref country code: ES

Payment date: 20210903

Year of fee payment: 19

Ref country code: GB

Payment date: 20210819

Year of fee payment: 19

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: PT

Payment date: 20210716

Year of fee payment: 19

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: TR

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20200811

REG Reference to a national code

Ref country code: DE

Ref legal event code: R119

Ref document number: 60325735

Country of ref document: DE

REG Reference to a national code

Ref country code: SE

Ref legal event code: EUG

REG Reference to a national code

Ref country code: NL

Ref legal event code: MM

Effective date: 20220901

GBPC Gb: european patent ceased through non-payment of renewal fee

Effective date: 20220811

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20220812

Ref country code: PT

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20230213

Ref country code: FI

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20220811

REG Reference to a national code

Ref country code: BE

Ref legal event code: MM

Effective date: 20220831

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: NL

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20220901

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IT

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20220811

Ref country code: IE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20220811

Ref country code: FR

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20220831

Ref country code: DE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20230301

REG Reference to a national code

Ref country code: ES

Ref legal event code: FD2A

Effective date: 20230928

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: BE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20220831

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: PT

Free format text: LAPSE BECAUSE OF EXPIRATION OF PROTECTION

Effective date: 20230823

Ref country code: GB

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20220811

Ref country code: ES

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20220812

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: PT

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20220811

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: PT

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20220811