EP1344163A1 - Method for accessing services and the inspection thereof, making use of a mobile terminal - Google Patents
Method for accessing services and the inspection thereof, making use of a mobile terminalInfo
- Publication number
- EP1344163A1 EP1344163A1 EP01270848A EP01270848A EP1344163A1 EP 1344163 A1 EP1344163 A1 EP 1344163A1 EP 01270848 A EP01270848 A EP 01270848A EP 01270848 A EP01270848 A EP 01270848A EP 1344163 A1 EP1344163 A1 EP 1344163A1
- Authority
- EP
- European Patent Office
- Prior art keywords
- transaction
- user
- inspector
- terminal
- transmits
- 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.)
- Withdrawn
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/02—Marketing; Price estimation or determination; Fundraising
-
- 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 relates to a method for accessing services.
- the invention relates to the facilitation, of the purchase and activation of a service by means of a form of "electronic ticket" and the inspection for legal use .
- a variety of methods and systems are generally known, that usually make use of access cards and bank cards, etc.
- the method according to the present invention comprises the following steps: a. a user registers, by means of a user terminal via a transaction network, with a transaction processor of a service provider in order to access a particular service; b. if certain conditions are met, the transaction processor registers transaction parameters for the specification of the user, of the service and of the transaction status. Normally, the service to be accessed will have to be paid for, upon which the transaction processor registers a payment code as transaction parameter.
- the payment can be made in co-operation with, for example, a banking processor.
- a code Prior to the actual accessing of the service, a code can be transmitted to the transaction processor, whereupon this processor registers an activation code as transaction parameter.
- This action is analogous to the "stamping" of a bus or train ticket at the beginning of the journey.
- the user Via the terminal, the user can always make contact with the transaction processor in order to verify the transaction parameters.
- the invention relates to the inspection of the passengers.
- a further elaboration of the invention provides for a (human or mechanical) inspector that checks a user for legal accessing of a service, for example travelling on bus or train - by direct or indirect inspection of the transaction parameters - via the transaction network - in the transaction processor. There are a number of variants for the inspection process .
- a first option is that the inspector requests the user's user terminal identifier and transmits it via the inspector terminal to the transaction processor, which reads out the transaction parameters relevant for inspection, that are registered for that identifier, and transmits them back to the inspector terminal. Subsequently, the inspector can, on the basis of the transaction parameters, check whether the user is making legal use of the service.
- the transaction parameters comprise all information required for inspection, such as - for a bus or train journey - the journey details, the sort of "ticket", etc.
- the transaction processor validates the relevant transaction parameters and, depending on the result of the validation process, transmits back a status code to the inspector terminal.
- a second variant is one in which not the inspector but the user transmits his user terminal identifier to the transaction processor, which reads out the transaction parameters relevant for inspection, that are registered for that identifier, and transmits them back to the inspector terminal.
- the inspection process proceeds via the terminal of the user (initiation) and of the inspector terminal (result) instead of only via the inspector, just as in the previous variant.
- use is preferably made of a status code that is transmitted back - in this case to the inspector terminal - as an extra check code, which is generated after evaluation in the transaction processor.
- the user transmits his user terminal identifier to the transaction processor, which reads out the transaction parameters relevant for inspection, " that are registered for that identifier, and transmits them back to the user terminal.
- the inspection process proceeds entirely via the user terminal.
- a status code generated by the transaction processor is additionally transmitted, as extra security.
- the inspection process comprises the step that the user requests the inspector terminal identifier of the inspector and transmits this identifier via the user terminal to the transaction processor, which calculates a status code that is dependent on this inspector terminal identifier and transmits back this status code to the user terminal. This step rules out possible confusion regarding the identity of the inspector, whereby improper use could be made of a status code transmitted for use by another inspector.
- a first variant provides for the status code to be generated in the transaction processor and transferred to the user terminal, while the verification code is generated locally, in the inspector terminal. This requires a local code generator operating synchronously and according to the same algorithms as the code generator that generates the status code in the transaction processor.
- a second variant provides for the status code to be generated in the transaction processor and transferred to the user terminal, while the verification code is also generated in the transaction processor and transferred to the inspector terminal.
- a status code is generated that is identical to the (autonomously generated) verification code.
- a different code will be generated, so that the inspector can see (different status code and verification code) that the user is not entitled to use the service.
- inspection of the accompanying transaction parameters will reveal the cause of the negative evaluation result.
- the inspector terminal will independently give an error indication (signal or text) if the status code and the verification code differ from each other.
- Figure 1 shows an example of a system for the implementation of the method according to the invention.
- a user (1) registers her user terminal (2) via a transaction network (3) with a transaction processor (4) of a transport company. This registration must take place prior to the actual use of the service (drawn in the figure) , in this case before boarding the transport means. If certain conditions are met, the transaction processor 4 registers transaction parameters for specification of the user terminal 2, of the service - the route, the time - and of the transaction status (OK/NOK) .
- the user 1 will pay for the journey (in advance) by means of a banking processor 5, upon which the transaction processor registers a payment code as transaction parameter.
- the user will "activate" her ticket prior to the journey, in the case of conventional tickets by means of "stamping".
- the "stamping" it is done by means of transmitting an activation code to the transaction processor, upon which this processor registers the activation code as transaction parameter.
- the user 1 can make contact with the transaction processor via her terminal 2 in order to verify the transaction parameters.
- a human (or possibly mechanical) inspector 6 can check whether the user 1 is travelling legally by direct or indirect inspection of the transaction parameters relating to that journey and passenger in the transaction processor 4.
- the inspector can request the passenger 1 for her user terminal identifier - for example the telephone number of her terminal 2 - and transmit it via his inspector terminal to the transaction processor.
- the transaction processor then reads out the transaction parameters relevant for inspection, that are registered with that terminal identifier and transmits them back to the inspector terminal.
- the inspector therefore keys in "0613367789", upon which the transaction processor 4 (provided that "the ticket” has been paid for and activated) answers "0613367789 Return Groningen The Hague first class". (In practice, abbreviations will be used that can be interpreted by the inspector, for example "0613367789 GNOGV 1".)
- the inspector terminal can receive the passenger's user terminal ID (e.g.
- the user terminal ID is represented as a barcode on the user terminal that can be read out electronically by the inspector by means of a barcode scanner integrated in the inspector terminal .
- a (supplementary) option is for the inspector to receive a status code (OK/NOK) from the transaction processor that is dependent on the findings of the transaction processor. If for example the inspector 6 has notified the processor 4 at the beginning of the journey that he is operating on the train from Groningen to The Hague, the processor 4 can return "OK" as status code.
- the transaction processor can also be fed with train-running information from a train running-information processor 8. In this way, the transaction processor "knows" between which stations the train is at any moment, so that "tickets" for sections of the route (for example Zwolle - Amersfoort) can be evaluated by the transaction processor for validity on that section of the route.
- Variants of the above are that the user transmits the identifier (e.g.
- the transaction processor 4 which reads out the transaction parameters relevant for inspection, that are registered for that identifier and transmits them back to the inspector terminal, possibly supplemented by a status code ("OK/NOK").
- the user terminal transmits and the inspector terminal receives the response. Assuming that the inspector has registered himself with the transaction processor at the beginning of the journey, the response will be returned to the correct inspector, providing that the user has a valid registration for the relevant route.
- the user terminal can additionally send the identifier of the inspector terminal - that will then have to be requested from the inspector or received via IR or Bluetooth, so that the response is always returned to the correct inspector.
- a second variant is that the user transmits his user terminal identifier to the transaction processor, that reads out the relevant transaction parameters and transmits them back to the user terminal.
- a supplementary status code can be transmitted as a function of the evaluation of the parameters by the processor 4.
- the passenger 1 sends her identifier and also receives the response, which - via the display of the terminal 2 - is shown to the inspector 6.
- the identifier of the inspector terminal can be requested - via IR, Bluetooth or verbally - and transmitted to the transaction processor 4.
- a status code is preferably taken with a value that varies with time. This is compared by the inspector with a verification code that changes in the same way and synchronously with the status code.
- the status code - which varies according to a specific algorithm - is generated in the transaction processor and transferred to the user terminal, while the verification code is generated locally in the inspector terminal.
- the inspector terminal comprises a processor that independently generates a verification code according to exactly the same algorithm as that by which the status code is generated in the transaction processor.
- the verification code can also be generated centrally in the transaction processor and transmitted to the inspector terminal. This simplifies synchronisation of the status code and the verification code.
- the verification code "jumps" (autonomously or controlled from the transaction processor) to a subsequent value, for example "766099".
- the transaction processor will generate "766099" as status code. If the passenger data are not in order, the transaction processor will generate, for example, status code "000000” as (“NOK”) or a code with an intrinsic meaning relating to the deficiency of the ticket, for example "000001” for “ticket not activated", "000002” for "ticket invalid on this route", etc.
- status code "000000” as (“NOK)
- NOK a code with an intrinsic meaning relating to the deficiency of the ticket, for example "000001” for "ticket not activated", "000002” for "ticket invalid on this route”, etc.
Abstract
Method for the use of mobile telephones as 'ticket' for bus or train journeys. A user registers transaction parameters relating to the user, service and transaction status via his user terminal to a transaction processor. There are various variants possible for the inspection process: the inspector can request and check the user parameters via his terminal, via the user terminal or via both. The transaction processor can additionally transmit a status code to the inspector and/or user that can optionally be compared with a verification code. The status code and verification code can also be regularly and synchronously 'refreshed', so that both codes change regularly, but are always identical to each other, provided that the transaction parameters of the user indicate legal use of the service.
Description
Method for accessing services and the inspection thereof, making use of a mobile terminal
BACKGROUND The invention relates to a method for accessing services. In particular, the invention relates to the facilitation, of the purchase and activation of a service by means of a form of "electronic ticket" and the inspection for legal use . A variety of methods and systems are generally known, that usually make use of access cards and bank cards, etc.
THE INVENTION It is an aim of the invention to make use of standard wireless terminals, such as mobile telephones etc., as "tickets" for services such as bus or train journeys etc., and in particular for enabling checking for legal use thereof. The method according to the present invention comprises the following steps: a. a user registers, by means of a user terminal via a transaction network, with a transaction processor of a service provider in order to access a particular service; b. if certain conditions are met, the transaction processor registers transaction parameters for the specification of the user, of the service and of the transaction status. Normally, the service to be accessed will have to be paid for, upon which the transaction processor registers a payment code as transaction parameter. The payment can be made in co-operation with, for example, a banking
processor. Prior to the actual accessing of the service, a code can be transmitted to the transaction processor, whereupon this processor registers an activation code as transaction parameter. This action is analogous to the "stamping" of a bus or train ticket at the beginning of the journey. Via the terminal, the user can always make contact with the transaction processor in order to verify the transaction parameters. In particular, the invention relates to the inspection of the passengers. A further elaboration of the invention provides for a (human or mechanical) inspector that checks a user for legal accessing of a service, for example travelling on bus or train - by direct or indirect inspection of the transaction parameters - via the transaction network - in the transaction processor. There are a number of variants for the inspection process .
A first option is that the inspector requests the user's user terminal identifier and transmits it via the inspector terminal to the transaction processor, which reads out the transaction parameters relevant for inspection, that are registered for that identifier, and transmits them back to the inspector terminal. Subsequently, the inspector can, on the basis of the transaction parameters, check whether the user is making legal use of the service. The transaction parameters comprise all information required for inspection, such as - for a bus or train journey - the journey details, the sort of "ticket", etc. In addition, but of crucial importance with a view to security, is the option that the transaction processor validates the relevant transaction parameters and, depending on the result of
the validation process, transmits back a status code to the inspector terminal.
A second variant is one in which not the inspector but the user transmits his user terminal identifier to the transaction processor, which reads out the transaction parameters relevant for inspection, that are registered for that identifier, and transmits them back to the inspector terminal. In this case, the inspection process proceeds via the terminal of the user (initiation) and of the inspector terminal (result) instead of only via the inspector, just as in the previous variant. In this variant as well, use is preferably made of a status code that is transmitted back - in this case to the inspector terminal - as an extra check code, which is generated after evaluation in the transaction processor.
In a third variant the user transmits his user terminal identifier to the transaction processor, which reads out the transaction parameters relevant for inspection, " that are registered for that identifier, and transmits them back to the user terminal. In this variant the inspection process proceeds entirely via the user terminal. In this case as well, preferably a status code generated by the transaction processor is additionally transmitted, as extra security. Preferably, the inspection process comprises the step that the user requests the inspector terminal identifier of the inspector and transmits this identifier via the user terminal to the transaction processor, which calculates a status code that is dependent on this inspector terminal identifier and transmits back this status code to the user terminal. This step rules out possible confusion regarding the identity of the
inspector, whereby improper use could be made of a status code transmitted for use by another inspector. As regards the status code, provision is preferably made, with a view to fraud prevention, to ensure that the status code generated by the transaction processor takes a value which varies with time and is compared by the inspector with a verification code that changes synchronously with the status code. Since the status code changes regularly, provisions must also be made to change the verification code in exactly the same manner. A first variant provides for the status code to be generated in the transaction processor and transferred to the user terminal, while the verification code is generated locally, in the inspector terminal. This requires a local code generator operating synchronously and according to the same algorithms as the code generator that generates the status code in the transaction processor. A second variant provides for the status code to be generated in the transaction processor and transferred to the user terminal, while the verification code is also generated in the transaction processor and transferred to the inspector terminal.
Provision is preferably made, with a view to fraud prevention, to ensure that the status code generated by the transaction processor has a value dependent on the transaction parameters.
If the evaluation by the transaction processor is positive, i.e. if the user is making legal use of the service, a status code is generated that is identical to the (autonomously generated) verification code. In the case of a negative result, a different code will be generated, so that the inspector can see (different
status code and verification code) that the user is not entitled to use the service. In such a case, inspection of the accompanying transaction parameters will reveal the cause of the negative evaluation result. Preferably, if the status code is transmitted to the inspector terminal, the inspector terminal will independently give an error indication (signal or text) if the status code and the verification code differ from each other. The invention will now be described in more detail by reference to a system for the implementation of the method according to the invention.
IMPLEMENTATION
Figure 1 shows an example of a system for the implementation of the method according to the invention. In the system in figure 1 a user (1) registers her user terminal (2) via a transaction network (3) with a transaction processor (4) of a transport company. This registration must take place prior to the actual use of the service (drawn in the figure) , in this case before boarding the transport means. If certain conditions are met, the transaction processor 4 registers transaction parameters for specification of the user terminal 2, of the service - the route, the time - and of the transaction status (OK/NOK) .
Normally, the user 1 will pay for the journey (in advance) by means of a banking processor 5, upon which the transaction processor registers a payment code as transaction parameter. As is customary for traditional tickets, the user will "activate" her ticket prior to the
journey, in the case of conventional tickets by means of "stamping". In this case, the "stamping" it is done by means of transmitting an activation code to the transaction processor, upon which this processor registers the activation code as transaction parameter. Naturally, the user 1 can make contact with the transaction processor via her terminal 2 in order to verify the transaction parameters. During or prior to the journey, a human (or possibly mechanical) inspector 6 can check whether the user 1 is travelling legally by direct or indirect inspection of the transaction parameters relating to that journey and passenger in the transaction processor 4. The inspector can request the passenger 1 for her user terminal identifier - for example the telephone number of her terminal 2 - and transmit it via his inspector terminal to the transaction processor. The transaction processor then reads out the transaction parameters relevant for inspection, that are registered with that terminal identifier and transmits them back to the inspector terminal. The inspector therefore keys in "0613367789", upon which the transaction processor 4 (provided that "the ticket" has been paid for and activated) answers "0613367789 Return Groningen The Hague first class". (In practice, abbreviations will be used that can be interpreted by the inspector, for example "0613367789 GNOGV 1".) If desired, the inspector terminal can receive the passenger's user terminal ID (e.g. telephone number) via an infrared or Bluetooth link, so that he does not need to key in the user terminal ID. An alternative is for the user terminal ID to be represented as a barcode on the user terminal that
can be read out electronically by the inspector by means of a barcode scanner integrated in the inspector terminal .
A (supplementary) option is for the inspector to receive a status code (OK/NOK) from the transaction processor that is dependent on the findings of the transaction processor. If for example the inspector 6 has notified the processor 4 at the beginning of the journey that he is operating on the train from Groningen to The Hague, the processor 4 can return "OK" as status code. The transaction processor can also be fed with train-running information from a train running-information processor 8. In this way, the transaction processor "knows" between which stations the train is at any moment, so that "tickets" for sections of the route (for example Zwolle - Amersfoort) can be evaluated by the transaction processor for validity on that section of the route. Variants of the above are that the user transmits the identifier (e.g. telephone number) of his user terminal to the transaction processor 4, which reads out the transaction parameters relevant for inspection, that are registered for that identifier and transmits them back to the inspector terminal, possibly supplemented by a status code ("OK/NOK"). In this case, the user terminal transmits and the inspector terminal receives the response. Assuming that the inspector has registered himself with the transaction processor at the beginning of the journey, the response will be returned to the correct inspector, providing that the user has a valid registration for the relevant route. Optionally, the user terminal can additionally send the identifier of the inspector terminal - that will then have to be requested
from the inspector or received via IR or Bluetooth, so that the response is always returned to the correct inspector.
A second variant is that the user transmits his user terminal identifier to the transaction processor, that reads out the relevant transaction parameters and transmits them back to the user terminal. Here as well, a supplementary status code can be transmitted as a function of the evaluation of the parameters by the processor 4. In this case, the passenger 1 sends her identifier and also receives the response, which - via the display of the terminal 2 - is shown to the inspector 6. Here as well, the identifier of the inspector terminal can be requested - via IR, Bluetooth or verbally - and transmitted to the transaction processor 4.
In particular, if (a part of) the inspection process proceeds via the user terminal, it is desirable to provide extra security. In order to prevent - clever - users from "implanting" in their terminal an "OK" status code that is generated locally in their terminal 2 instead of in the transaction processor 4, a status code is preferably taken with a value that varies with time. This is compared by the inspector with a verification code that changes in the same way and synchronously with the status code. The status code - which varies according to a specific algorithm - is generated in the transaction processor and transferred to the user terminal, while the verification code is generated locally in the inspector terminal. Accordingly, the inspector terminal comprises a processor that independently generates a verification code according to exactly the same algorithm as that by which the status code is generated in the transaction
processor. This means that local creation of a status code in a user terminal with the aim of committing fraud no longer serves any purpose. Instead of locally generating the verification code in the inspector terminal, the verification code can also be generated centrally in the transaction processor and transmitted to the inspector terminal. This simplifies synchronisation of the status code and the verification code. As an example of the above, assume that at a given time the inspector has the verification code "100988", which means that - if the passenger data are in order - the verification code will also have the value "100988". Some time later, however, the verification code "jumps" (autonomously or controlled from the transaction processor) to a subsequent value, for example "766099". If, on inspection, the passenger data are found to be in order, the transaction processor will generate "766099" as status code. If the passenger data are not in order, the transaction processor will generate, for example, status code "000000" as ("NOK") or a code with an intrinsic meaning relating to the deficiency of the ticket, for example "000001" for "ticket not activated", "000002" for "ticket invalid on this route", etc. Although the above example is of a train journey, this can also be a journey by bus or any other means of transport. Nor is the invention limited to travel services, but can be applied to all possible services.
Claims
1. Method for accessing services, characterised by the following steps: a. a user (1) registers, by means of a user terminal (2) via a transaction network (3), with a transaction processor (4) of a service provider in order to access a particular service; b. if certain conditions are met, the transaction processor registers transaction parameters for the specification of the user, of the service and of the transaction status.
2. Method according to claim 1, characterised in that the user pays for the service to be accessed, upon which the transaction processor registers a payment code as transaction parameter.
3. Method according to claim 1, characterised in that the user, prior to the actual accessing of the service, transmits a code to the transaction processor, upon which this processor registers an activation code as transaction parameter.
4. Method according to claim 1, characterised in that the user can make contact via a terminal with the transaction processor in order to verify the transaction parameters.
5. Method according to claim 1, characterised in that a human or mechanical inspector (6) checks a user for legal accessing of a service by direct or indirect inspection of the transaction parameters in the transaction processor.
6. Method according to claim 5, characterised in that the inspector requests the user's user terminal identifier and transmits it via an inspector terminal (7) to the transaction processor, which reads out the transaction parameters relevant for inspection, that are registered for that identifier, and transmits them back to the inspector terminal.
7. Method according to claim 5 or 6, characterised in that the inspector requests the user's user terminal identifier and transmits it via an inspector terminal (7) to the transaction processor, which reads out the transaction parameters relevant for inspection, that are registered for that identifier, and as a function thereof transmits a status code back to the inspector terminal.
8. Method according to claim 5, characterised in that the user transmits his user terminal identifier to the transaction processor, which reads out the transaction parameters relevant for inspection, that are registered for that identifier, and transmits them back to the inspector terminal.
9. Method according to claim 5 or 8, characterised in that the user transmits his user terminal identifier to the transaction processor, which reads out the transaction parameters relevant for inspection, that are registered for that identifier, and as a function thereof transmits a status code back to the inspector terminal.
10. Method according to claim 5, characterised in that the user transmits his user terminal identifier to the transaction processor, which reads out the transaction parameters relevant for inspection, that are registered for that identifier, and transmits them back to the user terminal .
11. Method according to claim 5 or 10, characterised in that the user transmits his user terminal identifier to the transaction processor, which reads out the transaction parameters relevant for inspection, that are registered for that identifier, and as a function thereof transmits a status code back to the user terminal.
12. Method according to claim 11, characterised in that the user requests the inspector terminal identifier of the inspector and transmits this identifier via the user terminal to the transaction processor, which transmits back to the user terminal a status code that is dependent on the inspector terminal identifier.
13. Method according to claim 7, 9, 11 or 12 characterised in that the status code generated by the transaction processor has a value which varies with time and is compared by the inspector with a verification code that changes synchronously with the status code.
14. Method according to claim 11 or 12, characterised in that the status code is generated in the transaction processor and transferred to the user terminal, while the verification code is generated in the inspector terminal.
15. Method according to claim 11 or 12, characterised in that the status code is generated in the transaction processor and transferred to the user terminal, while the verification code is also generated in the transaction processor and transferred to the inspector terminal.
16. Method according to claim 7, 9, 11 or 12, characterised in that the status code generated by the transaction processor is dependent on the transaction parameters and is compared by the inspector with a verification code generated in the inspector terminal that is also dependent on the transaction parameters.
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
NL1016853 | 2000-12-12 | ||
NL1016853A NL1016853C2 (en) | 2000-12-12 | 2000-12-12 | Method for the purchase of services and the control thereof, using a mobile terminal. |
PCT/EP2001/013729 WO2002048926A1 (en) | 2000-12-12 | 2001-11-21 | Method for accessing services and the inspection thereof, making use of a mobile terminal |
Publications (1)
Publication Number | Publication Date |
---|---|
EP1344163A1 true EP1344163A1 (en) | 2003-09-17 |
Family
ID=19772566
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP01270848A Withdrawn EP1344163A1 (en) | 2000-12-12 | 2001-11-21 | Method for accessing services and the inspection thereof, making use of a mobile terminal |
Country Status (4)
Country | Link |
---|---|
EP (1) | EP1344163A1 (en) |
AU (1) | AU2002221893A1 (en) |
NL (1) | NL1016853C2 (en) |
WO (1) | WO2002048926A1 (en) |
Families Citing this family (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
FI114425B (en) * | 2002-08-12 | 2004-10-15 | Plusdial Ab Oy | Method and arrangement to verify the authenticity of a utility of value distributed as a digital message |
US7275689B2 (en) * | 2003-09-05 | 2007-10-02 | Bcode Pty Ltd | Baggage check-in using short message device |
EP1524629A1 (en) | 2003-10-17 | 2005-04-20 | Swisscom Mobile AG | Authorisation control mechanism and device |
EP2989615A4 (en) * | 2013-04-23 | 2016-12-14 | Nokia Technologies Oy | Method and apparatus for digital ticket inspection |
Family Cites Families (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
FI944738A (en) * | 1994-10-07 | 1996-04-08 | Parkit Oy | System and method for paying the parking fee |
FI100137B (en) * | 1994-10-28 | 1997-09-30 | Vazvan Simin | Real-time wireless telecom payment system |
TW355899B (en) * | 1997-01-30 | 1999-04-11 | Qualcomm Inc | Method and apparatus for performing financial transactions using a mobile communication unit |
FI109505B (en) * | 1997-03-24 | 2002-08-15 | Fd Finanssidata Oy | Use of banking services in a digital cellular radio system |
SE9702925L (en) * | 1997-08-12 | 1998-05-25 | Rolf Rising | System for charging, collecting and distributing parking fees |
-
2000
- 2000-12-12 NL NL1016853A patent/NL1016853C2/en not_active IP Right Cessation
-
2001
- 2001-11-21 AU AU2002221893A patent/AU2002221893A1/en not_active Abandoned
- 2001-11-21 EP EP01270848A patent/EP1344163A1/en not_active Withdrawn
- 2001-11-21 WO PCT/EP2001/013729 patent/WO2002048926A1/en not_active Application Discontinuation
Non-Patent Citations (1)
Title |
---|
See references of WO0248926A1 * |
Also Published As
Publication number | Publication date |
---|---|
WO2002048926A1 (en) | 2002-06-20 |
NL1016853C2 (en) | 2002-06-13 |
AU2002221893A1 (en) | 2002-06-24 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7114651B2 (en) | Method for control of parked vehicles | |
EP0962071B1 (en) | Method for authorization check | |
EP0969426B1 (en) | Multi-venue ticketing using smart cards | |
KR100683093B1 (en) | Portable terminal and management apparatus thereof and management method of ic card | |
US20030140256A1 (en) | Wireless local communication network, access control method for a wireless local communication network and devices suitable therefor | |
US20040064415A1 (en) | Personal authentication software and systems for travel privilege assignation and verification | |
US20080204278A1 (en) | Electronic toll collection system, on-board unit, and terminal unit | |
JP2002541602A (en) | Methods and systems for ordering, loading, and using admission tickets | |
KR101136575B1 (en) | Value holding apparatus, value holding method, recording medium, and transaction system | |
PT1810112E (en) | Method and system for the user-specific initialization of identification devices in the field | |
CN111275601A (en) | Lottery ticket exchanging service system and method | |
RU2397543C2 (en) | Electronic ticket | |
US20210406845A1 (en) | Method for registering a ticket medium | |
CN113643489B (en) | Public transit pos machine based on face identification | |
WO2002048926A1 (en) | Method for accessing services and the inspection thereof, making use of a mobile terminal | |
CN111260530A (en) | Lottery entrusted service system and method | |
US20130066690A1 (en) | Car park control system using a third-party system | |
WO2007004865A1 (en) | Access check and ticket therefor | |
AU2013273615B9 (en) | Method for charging fees for location usages | |
RU2004120486A (en) | METHOD FOR USER REGISTRATION IN THE TRUSTING AUTHORITY FOR FURTHER WORK WITH ONE OF THE SERVING AUTHORITIES | |
JP6783532B2 (en) | Ticket gate management device and automatic ticket gate system | |
NL1016854C1 (en) | Service payment method, for paying for train tickets by mobile phone, uses service provider transaction processor to handle payment and check validity | |
US20220164715A1 (en) | Open loop transit system with a backend system | |
KR101467357B1 (en) | System and terminal for issuing ticket | |
JP2002092140A (en) | Car rental fare adjustment system |
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: 20030714 |
|
AK | Designated contracting states |
Kind code of ref document: A1 Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE TR |
|
AX | Request for extension of the european patent |
Extension state: AL LT LV MK RO SI |
|
17Q | First examination report despatched |
Effective date: 20090504 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN |
|
18D | Application deemed to be withdrawn |
Effective date: 20091117 |