Memory card and a method for making more reliable a request for access to an application5798506Abstract For a memory card that includes memory blocks containing reliability parameters (P.sub.1, P.sub.2, and P.sub.3) and respective reliability weights (PF.sub.1, PF.sub.2, and PF.sub.3), for the parameters, the method comprises the following steps: determining the reliability weights corresponding to the access request; computing an interactive reliability weight (PFI) as a function of the respective reliability weights of the access request; comparing the interactive reliability weight with an access reliability index (FA); and authorizing or refusing access to the application as a function of the results of the comparison. Claims I claim: Description The present invention relates to a memory card serving to make more reliable a request for access to an application, and to a method of making more reliable a request for access to an application.
______________________________________
Requested purchased price
Reliability weight PF.sub.1
______________________________________
0 to 20 0.01
21 to 40 0.5
41 to 250 1
251 to 500 0. 5
501 to 3000 0.01
more than 3000 0
______________________________________
Block B.sub.2 contains the code of the requested purchase locations and the corresponding reliability weights PF.sub.2. For example:
______________________________________
Country code Reliability weight PF.sub.2
______________________________________
France 0.7
Germany 0.2
Other countries
0.1
______________________________________
Block B.sub.3 contains the times that have elapsed between successive purchases, computed from the most recent purchase, together with the corresponding reliability weights PF.sub.3. For example:
______________________________________
Elapsed time, depending on country
PF.sub.3
______________________________________
Less than one day or one day in France
1
More than one day in France
0.1
Less than one day or one day abroad
0.1
More than one day abroad
1
More than five days abroad
0
______________________________________
The above data is stored in the memory card as a function of the purchasing habits of the user, with higher reliability weights being given to situations that are more frequent. In the example given: average purchases (70% of cases) lie in the range 41 to 250; they take place in France in 70% of cases, and in Germany in 20% of cases; and purchases are frequent in France (three per day on average), but rare abroad (one every three days). The interaction block BI contains a table of interactions between the parameters. This interaction table serves to weight the importance of each parameter independently of its respective reliability weight. For example:
______________________________________
Parameter Reliability weight
Interaction value
______________________________________
P.sub.1 PF.sub.1 V.sub.1 = 0.30
P.sub.2 PF.sub.2 V.sub.2 = 0.50
P.sub.3 PF.sub.3 V.sub.3 = 0.20
______________________________________
The block BI also contains in its memory a reliability index FA, e.g. FA=0.2. The dedicated processor PA can thus compute the interactive reliability weight PFI, defined in this non-limiting example by the following equation : PFI=(PF.sub.1 .times.V.sub.1)+(PF.sub.2 .times.V.sub.2)+(PF.sub.3 .times.V.sub.3) When the user seeks to make a purchase, the reliability weights corresponding to the three parameters P.sub.1, P.sub.2, and P.sub.3 are determined by dialog with the terminal into which the card has been inserted, with the amount being input via the keypad of the terminal, while the location and the date are provided automatically by the terminal. The reliability weights obtained in this way are stored in MM.sub.1, MM.sub.2, and MM.sub.3, respectively. In this respect, it should be observed that in the present example, the situation of the parameter P.sub.3 is determined by comparison with the date of the preceding transaction. To this end, it is preferable for the block B.sub.3 to be provided with a location enabling the date of the previously-performed transaction to be stored, which date is updated at the end of each transaction. Thereafter, the processor PA computes the interactive reliability weight PFI using the interaction table BI. Finally, the processor PA compares the interactive reliability weight PFI with the index FA and informs the card if the reliability is sufficient to authorize access to the banking application program. In this example, if PFI is .gtoreq.0.20, purchase is authorized, whereas if PFA is <0.20, purchase is refused. For example: the user makes a first purchase in Paris: then, on the same day, a second purchase for 200 F in Paris, and while this second purchase is being made, the interactive reliability weight is given by the following equation: ##EQU1## (sufficient reliability, purchase authorized); then on the same day, the user makes a third purchase for 20 F, still in Paris: ##EQU2## (sufficient reliability, purchase authorized); that same day, the user goes to Germany and makes a purchase for 200 F: ##EQU3## (sufficient reliability, purchase authorized); and finally, on that same day, the user seeks to make a purchase for 2000 F in Germany: ##EQU4## (insufficient reliability, purchase refused). As a function of a user's habits, a system designed in this way can improve supervision of memory cards in numerous applications. FIG. 2 shows a more sophisticated method that can be implemented in the card of the invention. As before, this method includes a step of determining reliability weights for each of the parameters as a function of an access request, and then computes an interactive reliability weight which is compared with the access reliability index. If access is refused, it is verified whether the number of refusals has reached the maximum predetermined number of refusals. If the maximum predetermined number has been reached, then the card is totally inhibited. This procedure serves to prevent a fraudulent user who has obtained the card for any reason whatsoever and who also knows the personal identification number of the cardholder from being able to proceed with successive access requests in order to determine the habits of the cardholder. In this respect, it should be observed that even though a third party may be able to observe the personal identification number of a cardholder while the number is being keyed in, the access habits of the user relative to the application in question can never be observed at any one given time by a third party, so the invention significantly increases the reliability of access to the application under consideration. If access is refused without the number of refusals reaching the maximum predetermined number, then, in accordance with the invention, it is preferable to reduce the reliability weights associated with at least one of the parameters, or to increase the access reliability index. In either case, when the interactive reliability weight is compared with the reliability index, the comparison will be less favorable to the user of the card than it was before the change, and will therefore lead to access to the application being monitored more strictly, such that a fraudulent user unaware of the habits of the cardholder will quickly find access to the application being refused whatever the conditions under which a request for access is performed. Once the user has made a number of access requests reaching the predetermined maximum, then the card will be definitively inhibited. Conversely, when access is authorized, the user is offered a self-training step for the purpose of enabling a change of user habits to be stored in the card. If the user does not desire to change habits, then the self-training step is refused and the transaction is performed without changing the reliability weights initially recorded in the card. Otherwise, if the user does indeed wish to proceed with a self-training step, then it is preferable for an additional verification to be performed by asking the user to input a training code which is compared with a secret code stored in the card in a manner analogous to the personal identification number. If the training code is wrong, the user is given the option of trying again providing the number of errors does not reach some predetermined maximum. If the number of wrong training code inputs reaches the predetermined maximum, then the card is totally inhibited. Assuming that the training code as input is correct, then the self-training step is performed. This self-training step consists in increasing the reliability weight of at least one of the reliability parameters for a situation corresponding to that of the access that has been authorized. In accordance with the invention, it is preferable to provide for the reliability weight of the same reliability parameter to be simultaneously reduced for situations differing from the requested access. In a table comprising k rows associating different situations with corresponding reliability weights, provision may be made to increase the reliability weight relating to the situation for which access has just been authorized by an amount k .perp-left. 10%, while simultaneously reducing the reliability weights of the other rows by 10%. When an access request is authorized for a price of 2000 F in association with above-mentioned block B.sub.1, then the row corresponding to this purchase value is increased by 60% such that the reliability weight is raised to 0.016, while each of the other reliability weights is reduced by 10%. Naturally, it is possible to provide upper and lower limits for reliability weights, beyond which no further modification is performed. In the context of the self-training procedure, provision may also be made to return immediately to the initial reliability weights whenever they are reduced due to access being refused. Naturally, the invention is not limited to the embodiment described, and variant embodiments may be provided without going beyond the ambit of the invention as defined in the claims. In particular, although the card in the example described includes an interaction table enabling the relative importance of each of the parameters to be weighted, it is possible, in accordance with the invention, to provide for the interaction values to be incorporated directly in the reliability weights of each of the parameters. Also, although the invention is described above with reference to a reliability index which is stored in the card and which is therefore common to all of the applications to which the card can give access, it is possible to associate a different reliability index with each application, in which case the reliability index is contained in the terminal corresponding to the application and is communicated for the purpose of being compared with the interactive reliability weight. Although the invention is described above with reference to computing an interactive reliability weight in the form of a weighted sum of individual reliability weights, it is possible to perform the computation in the form of a product: PFI=PF.sub.1 .times.PF.sub.2 .times.PF.sub.3 or any other form and to adapt the access reliability index FA correspondingly. Although the invention is described above with reference to a location code that corresponds to different countries, it is also possible to provide for different reliability weights as a function of different cities in the same country. Although the invention is described above with reference to a single acess reliability index, it is also possible to provide various values of the access reliability index and to modulate the decision as a function of the value reached by the interactive reliability weight. In the example described above it is for example possible to take into account two values of the access reliability index, 0.1 and 0.2. When the interactive reliability weight exceeds the highest value 0.2 the access is naturally authorized. When the interactive reliability weight falls between the two values of the access reliability index, the access is authorized upon condition, for example when the price does not exceed Francs 100, and is refused in an opposite situation. When the interactive reliability weight is below the lowest value 0.1 the access is refused whatever be the price. In order to increase the safety in case the card has been stolen it is preferably provided to reduce the individual reliability weights or to increase the access reliability index not only when the access is refused but also when it is authorized upon condition. It is also possible to provide for various tables of reliability weights for some parameters as a function of the location of the access request, or to vary the self-training function according to the number of accesses already authorized.
|
Same subclass Same class Consider this |
||||||||||
